work at randybuchholz.com (2019-05-23T17:17:54.092Z)
@Andrea Giammarchi<mailto: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<mailto: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.
@Andrea Giammarchi<mailto: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<mailto: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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190523/cdf103f9/attachment-0001.html>