@Andrea Giammarchi<mailto:andrea.giammar...@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<mailto:guest271...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
