Indexing HTML Attributes and Unique Indexes

Randy Buchholz work at randybuchholz.com
Thu May 23 17:14:47 UTC 2019


@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>


More information about the es-discuss mailing list