Indexing HTML Attributes and Unique Indexes
andrea.giammarchi at gmail.com
Thu May 23 14:33:41 UTC 2019
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 <guest271314 at gmail.com> 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 <work at randybuchholz.com>
>> 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
>> 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
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss