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)
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 `el.id`, 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) however, I think this whole discussion in here makes no sense, as JS itself has nothing to do with HTML 🤷♂️ On Thu, May 23, 2019 at 4:23 PM guest271314 <[email protected]> wrote: > If the HTML elements have a unique ```id``` set there is not search to > perform (```document.getElementById("id")```), correct? > > Form fields can be created, set and changed using `FormData` objects > without using HTML elements at all. > > Still not gathering what is meant by unique indexes. > > On Thu, May 23, 2019 at 2:05 PM Randy Buchholz <[email protected]> > wrote: > >> 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 >> g in databases. It seemed worth seeing if the concept translated across >> technologies. >> >> 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. >> >> 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. >> >> 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. >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
