Indexing HTML Attributes and Unique Indexes

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu May 23 17:26:08 UTC 2019


> while it could be considered a sub-set, JS is full of HTML related
features - `HTMLElement` for one.

HTMLElement is defined by the living DOM standard (WHATWG)
https://html.spec.whatwg.org/multipage/dom.html#htmlelement

it has nothing to do with JS.

JS is a general purpose programming language that implements ECMAScript
standard, which on the Web gets enriched with some functionality, while on
NodeJS it gets enriched with some other (and indeed HTMLELement doesn't
exist there).

In GJS (Dekstop UI) it has other features too, so asking in a JS related
mailing list to bring in something strictly DOM related (whatwg) is not
appropriate.

Historically speaking, the only thing that went in strictly DOM related
where things like String.prototype.blink methods and others, but today JS
is *really* not Web based anymore, even if Web is one of its primary goals
(but then again, with WASM around, any programming language can target the
Web, so you want this proposal to land in WHATWG, not here).

Regards



On Thu, May 23, 2019 at 7:15 PM Randy Buchholz <work at randybuchholz.com>
wrote:

> @Andrea Giammarchi <andrea.giammarchi at gmail.com>, While the connection is
> secondary, HTML often serves as the specification for the creation of JS
> objects. And while it could be considered a sub-set, JS is full of HTML
> related features - `HTMLElement` for one. Thing is, if you are programming
> in JS for browser applications, you’re dealing with HTML-adjacent JS at
> some point. What I’m trying to do, though, somewhat supports your point.  I
> see a lot of higher-level code manipulating HTML tags, which feels really
> wrong. Even dealing with `HTMLElement` in higher-level code doesn’t seem to
> make a lot of sense.  I’m trying to encapsulate the elements and tags, and
> move that point as far into the background as I can.
>
>
>
> @guest271314 <guest271314 at gmail.com>
>
> If we think of Indexes as a type of key-value pairs, a “regular” Index
>  allows duplicate keys, and a Unique Index requires unique keys. Indexes
> are always sorted on their keys. So in this case, when the index is built,
> it creates k-v pairs of attributeName-elementId, ordered by attributeName.
> To get all elements with a specific attribute, we just find the first one
> with that key, and keep reading -`getElementbyId(elementId)` - until the
> key changes.
>
>
>
> You’re right about `id`. I’m converting generic, multi-instance template
> “tags” into  elements with id’s, so I can access them directly without
> searching. Just using `getElementById`. The template as been “localized”
> per instance, and encapsulated behind a controller. I want to avoid dealing
> with HTML, and even more HTTP verb related things like `Form` and
> `FormData` and just deal with general JS objects, so I use Models instead
> of things like `FormData`.
>
>
>
> So for example, the business perspective of a ”Person” has “Age” data. A
> page may display multiple people at once.
>
> ```
>
> <custom-person id=’person1’>
>
> <custom-person id=’person2’>
>
> ```
>
> The goal is to get from the source tag to non-html/element related JS as
> soon as possible.
>
>
>
> The template behind this might look something like
>
> ```
>
> <framework-container>
>
>    <input prop=’name’ />
>
>     <input prop=`age` />
>
> </framework-container>
>
> ```
>
>
>
> When `connectedCallback` runs, it creates  a `View` using the template
>
> ```
>
> <sometag>
>
>    <input id=’person1_name` />
>
>    <input id=`person1_age` />
>
> </sometag>
>
>
>
> <sometag>
>
>     <input id=’person2_name’ />
>
>     <input id=’person2_age’ />
>
> </sometag>
>
> ```
>
> A `Model`
>
> ```
>
> class person{
>
>     name;
>
>     age;
>
> }
>
>
>
> And a dynamically configured `Controller` and instance. A base Person
> class contains common functionality.
>
> ```
>
> class Person1 extends Person{
>
>     get name(){ return document.getElementById(‘person1_name’)
>
>>
>     get model(){ return this.populateModel();}
>
> }
>
> self.controllers.add(new Person1());
>
> ```
>
> Now I don’t need to deal with any HTML/element or “tag hierarchy” related
> JS. I pretty much abstract out the HTML and HTMLElement pieces when the
> Custom Element is initially loaded.
>
>
>
> ```
>
>     const personAge = self.controllers.person1.age;
>
> ```
>
> At a lower level, I can create attribute related properties using the
> dynamically assigned element id.
>
>
>
> ```
>
> <input prop=’name’ attrib=’style.color’ />
>
> ```
>
> This would end up creating a property or methods on the controller that
> allows me to not have to deal with styles and CSS classes directly, and
> even constrain values.
>
>
>
> ```
>
> self.controllers.person1.name.color = “red”;
>
> ```
>
>
>
> So the whole index thing started when I was loading/parsing dynamic
> html/JS code and searching for `prop` and `attrib` repeatedly. If I know
> I’m going to be searching on an attribute a lot, maybe I could give the
> parser/engine a hint it could use to optimize that search.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190523/e83d2ac2/attachment.html>


More information about the es-discuss mailing list