> I want to avoid dealing with HTML
Using HTML is part of premise of the proposal, correct?
Am still not sure what the actual requirement is. If the requirement is to
prevent duplicate _values_ being input by the user you can utilize
```pattern``` attribute of ```<input>``` with a ```RegExp``` which matches
the current values of ```<input>``` elements, ```oninvalid``` and
```checkValidity()``` which will provide the functionality of the
```value``` attribute of ```<input>``` and ```<select>``` elements being
unique as to a ```<form>``` element.
If there is no user input there should not be any issue creating unique
key-value pairs using ```Map```, ```WeakMap``` or ```Set```.
> 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`.
A ```FormData``` object can be serialized, am not certain what a "Model"
is. What do you consider to be "general JS objects"?
On Thu, May 23, 2019 at 5:14 PM Randy Buchholz <w...@randybuchholz.com>
wrote:
> @Andrea Giammarchi <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 <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
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
