<div dir="ltr"><div>it's meant there couldn't be two indexes with the same value, but even IDs can be duplicated on a page (it's not suggested or anything, but nothing prevents you to do that)</div><div><br></div><div>to be honest, since IDs already cover the whole story (IDs are accessible even via globalThis/window, no need to query the document) I guess this whole story is about having `el.uid`, as opposite of `<a href="http://el.id">el.id</a>`, so that a `uid` cannot be duplicated (it throws if it is), and `document.uid[unique-uid-value]` would return, without querying, the live node (if any)</div><div><br></div><div>however, I think this whole discussion in here makes no sense, as JS itself has nothing to do with HTML 🤷‍♂️</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2019 at 4:23 PM guest271314 <<a href="mailto:guest271314@gmail.com">guest271314@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If the HTML elements have a unique ```id``` set there is not search to perform (```document.getElementById("id")```), correct? <br><br>Form fields can be created, set and changed using `FormData` objects without using HTML elements at all. <div><br></div><div>Still not gathering what is meant by unique indexes.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2019 at 2:05 PM Randy Buchholz <<a href="mailto:work@randybuchholz.com" target="_blank">work@randybuchholz.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Full Table Scans and Unique indexes are database concepts (that's the DBA reference). When a database searches for a record based on a column value, it might look at every record in the table to find the matches - scan the entire (full) table, in the order the records were inserted or stored. To speed this up, we can create indexes on table columns or column groups. These are like ordered maps or hash tables. To find a record, more efficient searches can be done against the indexes to find the records. Indexes can also act as constraints. A "Unique Index" is a constraint that checks a table to see if a value exists before inserting it in the table and adding it to the index. Indexing has a trade-off. It slows inserting, but improves searching. While understanding that databases and browsers are worlds apart, a foundational part of database engines is searching, just like it is in DOM manipulation. Indexing can provide orders of magnitude performance improvements when reading/searchin<br>
 g in databases. It seemed worth seeing if the concept translated across technologies.<br>
<br>
Without any optimizations, an attribute search on a document would look at each node, and then at each attribute of the node to find a match - Full Table Scan. This makes searches very slow. At an absurd extreme, we could index everything, making startup very slow and eating memory, but making some searches very fast.  The balanced approach is to implement "indexing" ourselves (using any of the mentioned approaches) to get the best level.<br>
<br>
About the code/HTML, it is dynamic and real-time. It is loaded over WebSockets, and the elements are talking to the backend in real-time over the sockets. I'm using an original (Trygve Reenskaug) MVC approach. Essentially, each Web Component is an MVC component, with the HTML/elements and code accessed only through the controller. I am looking at the incoming code for cases where several searches ae being performed on the same attribute (or element). I give these a generated `id`,  create indexes on them, and expose them as properties on the controller. The underlying framework uses a set of common attributes that are searched on a lot, but only for a small set of elements. These are also indexed. So at the cost of slower startup (offset to some degree by doing some of this in a Web Worker and/or server-side), I can read and write "Form Fields" quickly.<br>
<br>
Many language features are implemented to wrap or optimize common or repetitive use cases, or to move code to a more efficient part of the architecture. Indexing can do both. Without doing things server-side or in Workers, the indexing consumes UI cycles. Adding an indexing "hint" could allow all or part of this code to be moved back into the "system" or C++ layer. (e.g., into `querySelect` internals supported by low-level map stores) Or to parsing (like I'm doing), taking some of the repetitive work off the UI and developers hands. <br>
<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>