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 <w...@randybuchholz.com> 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
