mount-observer 0.0.22 → 0.0.24

package/MountObserver.js

@@ -181,7 +181,8 @@ export class MountObserver extends EventTarget {
         }, { signal: this.#abortController.signal });
         await this.#inspectWithin(within, true);
     }
-    synthesize(within, customElement, mose) {
+    static synthesize(within, customElement, mose) {
+        mose.type = 'mountobserver';
         const name = customElements.getName(customElement);
         if (name === null)
             throw 400;

package/README.md

@@ -72,6 +72,8 @@ Invoking "disconnect" as shown above causes the observer to emit event "disconne
 
 The argument can also be an array of objects that fit the pattern shown above.
 
+In fact, as we will see, where it makes sense, where we see examples that are strings, we will also allow for arrays of such strings.  For example, the "on" key can point to an array of CSS selectors (and in this case the mount/dismount callbacks would need to provide an index of which one matched).  I only recommend adding this complexity if what I suspect is true -- providing this support can reduce "context switching" between threads / memory spaces (c++ vs JavaScript), and thus improve performance.
+
 If no imports are specified, it would go straight to do.* (if any such callbacks are specified), and it will also dispatch events as discussed below.
 
 This only searches for elements matching 'my-element' outside any shadow DOM.
@@ -103,15 +105,15 @@ const observer = new MountObserver({
 observer.observe(document);
 ```
 
-Th key can accept either a single import or multiple (via an array).
+Once again, the key can accept either a single import or it can also support multiple imports (via an array).
 
 The do event won't be invoked until all the imports have been successfully completed and inserted into the modules array.
 
-Previously, this proposal called for allowing arrow functions as well, thinking that could be a good interim way to support bundlers.  But the valuable input provided by [doeixd](https://github.com/doeixd) makes me think that that interim support could just as effectively be done by the developer in the do methods.
+Previously, this proposal called for allowing arrow functions as well, thinking that could be a good interim way to support bundlers, as well as multiple imports.  But the valuable input provided by [doeixd](https://github.com/doeixd) makes me think that that interim support could more effectively be done by the developer in the do methods.
 
 This proposal would also include support for JSON and HTML module imports. 
 
-## MountObserver script element
+## MountObserver script elements (MOSEs)
 
 Following an approach similar to the [speculation api](https://developer.chrome.com/blog/speculation-rules-improvements), we can add a script element anywhere in the DOM:
 
@@ -161,7 +163,7 @@ If no id is found in the parent ShadowRoot (or in the parent window if the shado
 
 But if a matching id is found, then the values from the parent script element get merged in with the one in the child, with the child settings, including the event handling attributes. 
 
-We will come back to some [additional features](#mountobserver-script-element-minutiae) of using these script elements later, but wanted to cover the highlights of this proposal before getting bogged down in some tedious logistics.
+We will come back to some [additional features](#creating-frameworks-that-revolve-around-moses) of using these script elements later, but wanted to cover the highlights of this proposal before getting bogged down in some tedious logistics.
 
 ## Binding from a distance
 
@@ -323,7 +325,7 @@ The alternative to providing this feature, which I'm leaning towards, is to just
 
 ## A tribute to attributes
 
-Attributes of DOM elements are tricky.  They've been around since the get-go, and they've survived multiple generations of the Web where different philosophies have prevailed, so prepare yourself for some subtle discussion in what follows.
+Attributes of DOM elements are tricky.  They've been around since the get-go of the Web, and they've survived multiple generations, where different philosophies have prevailed, so prepare yourself for some subtle discussion in what follows.
 
 Extra support is provided for monitoring attributes.  There are two primary reasons for needing to provide special support for attributes with this API:
 
@@ -583,7 +585,6 @@ Tentative rules:
 The thinking here is that longer roots indicate higher "specificity", so it is safer to use that one.
 
 
-
 ## Preemptive downloading
 
 There are two significant steps to imports, each of which imposes a cost:  
@@ -715,19 +716,29 @@ This proposal (and polyfill) also supports the option to utilize ShadowDOM / slo
 
 The discussion there leads to an open question whether a processing instruction would be better.  I think the compose tag would make much more sense, vs a processing instruction, as it could then support slotted children (behaving similar to the Beatles' example above).  Or maybe another tag should be introduced that is the equivalent of the slot, to avoid confusion. or some equivalent.  But I strongly suspect that could significantly reduce the payload size of some documents, if we can reuse blocks of HTML, inserting sections of customized content for each instance.
 
-## MountObserver script element minutiae
+## Creating "frameworks" that revolve around MOSEs.
+
+Often, we will want to define a large number of "mount observer script elements (MOSEs)" programmatically, and we need it to be done in a generic way, that can be published and easily referenced.  
 
-Often, we will want to define a large number of "mount observers" programmatically, and we need it to be done in a generic way.  This is a problem space that [be-hive](https://github.com/bahrus/be-hive) is grappling with.  In particular, we want to publish enhancements that take advantage of this inheritable infrastructure of declarative configuration, but we don't want to burden the developer with having to manually list all these configurations, we want it to happen automatically.
+This is a problem space that [be-hive](https://github.com/bahrus/be-hive) is grappling with, and is used as an example for this section, to simply make things more concrete.  But we can certainly envision other "frameworks" that could leverage this feature for a variety of purposes, including other families of behaviors/enhancements, or "binding from a distance" syntaxes.  
+
+In particular, *be-hive* supports publishing [enhancements](https://github.com/bahrus/be-enhanced) that take advantage of the DOM filtering ability that the MountObserver provides, that "ties the knot" based on CSS matches in the DOM to behaviors/enhancements that we want to attach directly onto the matching elements.  *be-hive" seeks to take advantage of the inheritable infrastructure that MountObserver script elements provide, but we don't want to burden the developer with having to manually list all these configurations, we want it to happen automatically, only expecting manual intervention when we need some special customizations within a specific ShadowDOM scope.
 
 To support this, we propose these highlights:
 
-1.  Adding a "synthesize" method to the MountObserver api, only if observing a shadowRoot (or the top level document).  This would provide a kind of passage way from the imperative api to the declarative one.  
-2.  Synthesize method appends a script element of type MountObserver, that dispatches event from the synthesizing custom element it gets appended to, so subscribers don't need to add a general mutation observer in order to know when parent shadow roots had a MountObserver script tag inserted.
+1.  Adding a static "synthesize" method to the MountObserver api.  This would provide a kind of passage-way from the imperative api to the declarative one.  
+2.  As the Synthesize method is called repeatedly from different packages that work with that framework, it creates a cluster of MOSEs wrapped inside a custom element ("be-hive") that the framework developer authors.  It appends script elements with type="mountobserver" to the custom element instance sitting in the DOM, that dispatches events from the synthesizing custom element it gets appended to, so subscribers in child Shadow DOM's don't need to add a general mutation observer in order to know when parent shadow roots had a MOSE inserted that it needs to act on.  This allows the child Shadow DOM's to inherit (in this case) behaviors/enhancements from the parent Shadow DOM.
+
+So framework developers can develop a bespoke custom element that inherits from the class "*Synthesizer*" that is part of this package / proposal, that is used to group families of MountObservers together.  
 
+What functionality do these "synthesizing" custom elements provide, what value-add proposition do they fulfill over what is built into the MountObserver polyfill / package?
 
-So developers can develop a custom element, used to group families of MountObservers together.  
+The sky is the limit, but focusing on the first example, be-hive, they are:
 
-If one inspects the DOM, one would see grouped (already "parsed") MountObservers, like so:
+1.  Managing, interpreting and parsing the attributes that add semantic enhancement vocabularies onto exiting elements.
+2.  Establishing the "handshake" that imports the enhancement package, instantiates the enhancement, and passes properties that wee previously assigned to the pre-enhanced element to the attached enhancement/behavior.
+
+If one inspects the DOM, one will see grouped (already "parsed") MOSEs, like so:
 
 ```html
 <be-hive>
@@ -736,29 +747,19 @@ If one inspects the DOM, one would see grouped (already "parsed") MountObservers
 </be-hive>
 ```
 
-But the developer would not need to set these up automatically.
-
-Instead, the framework developer would define a custom element that inherits from base class that this proposal/polyfill provides.
+Without the help of the synthesize method / Synthesizer base class, the developer would need to set these up manually, so this lifts a significant burden from the shoulders of people who want to leverage these behaviors/enhancements in a seamless way.  
 
-Let's say the framework developer creates an extending Web Component with constructor:  BeHive.
-
-Then rather than invoking:
+The developer of each package defines their MOSE "template", and then syndicates it via the synthesize method:
 
 ```JavaScript
-mountObserver.observe(rootNode);
+mountObserver.synthesize(rootNode, BeHive, mose)
 ```
 
-we would invoke:
+What this method does is it:
 
-```JavaScript
-mountObserver.synthesize(rootNode, BeHive, mountObserverScriptElement)
-```
-
-The MountObserver api would:
-
-1.  Use [customElements.getName](https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/getName) to get the name of the custom element (say it is 'be-hive').
-2.  Search for a be-hive tag inside the root node (with special logic for the "head" element).  If not found, create it.
-3.  Place the script element inside.
+1.  Uses [customElements.getName](https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/getName) to get the name of the custom element (say it is 'be-hive') from the provided constructor.
+2.  Searches for a be-hive tag inside the root node (with special logic for the "head" element).  If not found, creates it.
+3.  Places the MOSE inside.
 
 
 Then in our shadowroot, rather than adding a script type=mountobserver for every single mount observer we want to inherit, we could reference the group via simply:
@@ -767,5 +768,15 @@ Then in our shadowroot, rather than adding a script type=mountobserver for every
 <be-hive></be-hive>
 ```
 
+And we can give each inheriting ShadowRoot a personality of its own by customizing the settings within that shadow scope, by (manually?) adding a MOSE with matching id that overrides the inheriting settings with custom settings:
 
+```html
+<be-hive>
+   <script type=mountobserver id=be-searching>
+      {
+         ...my custom settings
+      }
+   </script>
+</be-hive>
+```
 

package/Synthesizer.js

@@ -6,12 +6,12 @@ export class Synthesizer extends HTMLElement {
         for (const mutation of mutationList) {
             const { addedNodes } = mutation;
             for (const node of addedNodes) {
-                if (!(node instanceof HTMLScriptElement))
+                if (!(node instanceof HTMLScriptElement) || node.type !== 'mountobserver')
                     continue;
                 const mose = node;
                 this.mountObserverElements.push(mose);
-                this.#import(mose);
-                const e = new SyntheticEvent(mose);
+                this.activate(mose);
+                const e = new SynthesizeEvent(mose);
                 this.dispatchEvent(e);
             }
         }
@@ -21,25 +21,35 @@ export class Synthesizer extends HTMLElement {
         const init = {
             childList: true
         };
-        this.#mutationObserver = new MutationObserver(this.mutationCallback);
-        this.#mutationObserver.observe(this.getRootNode());
-        this.#inherit();
+        this.querySelectorAll('script[type="mountobserver"]').forEach(s => {
+            const mose = s;
+            this.mountObserverElements.push(mose);
+            this.activate(mose);
+        });
+        this.#mutationObserver = new MutationObserver(this.mutationCallback.bind(this));
+        this.#mutationObserver.observe(this, init);
+        this.inherit();
     }
-    #import(mose) {
+    activate(mose) {
         const { init, do: d, id } = mose;
-        const se = document.createElement('script');
-        se.init = init;
-        se.id = id;
-        se.do = d;
         const mi = {
             do: d,
             ...init
         };
         const mo = new MountObserver(mi);
-        se.observer = mo;
+        mose.observer = mo;
+        mo.observe(this.getRootNode());
+    }
+    import(mose) {
+        const { init, do: d, id, synConfig } = mose;
+        const se = document.createElement('script');
+        se.init = { ...init };
+        se.id = id;
+        se.do = { ...d };
+        se.synConfig = { ...synConfig };
         this.appendChild(se);
     }
-    #inherit() {
+    inherit() {
         const rn = this.getRootNode();
         const host = rn.host;
         if (!host)
@@ -49,11 +59,11 @@ export class Synthesizer extends HTMLElement {
         const parentScopeSynthesizer = parentShadowRealm.querySelector(localName);
         const { mountObserverElements } = parentScopeSynthesizer;
         for (const moe of mountObserverElements) {
-            this.#import(moe);
+            this.import(moe);
         }
         if (parentScopeSynthesizer !== null) {
-            parentScopeSynthesizer.addEventListener(SyntheticEvent.eventName, e => {
-                this.#import(e.mountObserverElement);
+            parentScopeSynthesizer.addEventListener(SynthesizeEvent.eventName, e => {
+                this.import(e.mountObserverElement);
             });
         }
     }
@@ -61,6 +71,9 @@ export class Synthesizer extends HTMLElement {
         if (this.#mutationObserver !== undefined) {
             this.#mutationObserver.disconnect();
         }
+        for (const mose of this.mountObserverElements) {
+            mose.observer.disconnect(this.getRootNode());
+        }
     }
 }
 // https://github.com/webcomponents-cg/community-protocols/issues/12#issuecomment-872415080
@@ -68,11 +81,11 @@ export class Synthesizer extends HTMLElement {
  * The `mutation-event` event represents something that happened.
  * We can document it here.
  */
-export class SyntheticEvent extends Event {
+export class SynthesizeEvent extends Event {
     mountObserverElement;
     static eventName = 'synthesize';
     constructor(mountObserverElement) {
-        super(SyntheticEvent.eventName);
+        super(SynthesizeEvent.eventName);
         this.mountObserverElement = mountObserverElement;
     }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mount-observer",
-  "version": "0.0.22",
+  "version": "0.0.24",
   "description": "Observe and act on css matches.",
   "main": "MountObserver.js",
   "module": "MountObserver.js",

package/types.d.ts

@@ -2,6 +2,7 @@
 
 export interface JSONSerializableMountInit{
     readonly on?: CSSMatch,
+    observedAttrsWhenMounted?: string[],
     readonly whereAttr?: WhereAttr,  
     readonly whereElementIntersectsWith?: IntersectionObserverInit,
     readonly whereMediaMatches?: MediaQuery,
@@ -37,7 +38,7 @@ export interface RootCnfg{
 //export type RootAttrOptions = Array<string | RootCnfg>;
 export type delimiter = string;
 export interface WhereAttr{
-    isIn?: Array<string>,
+    
     hasBase?: string | [delimiter, string],
     hasBranchIn?: Array<string> | [delimiter, Array<string>],
     hasRootIn?: Array<RootCnfg>,
@@ -67,6 +68,7 @@ export interface IMountObserver {
     disconnect(within: Node): void;
     module?: any;
     mountedElements: WeakSet<Element>;
+    readAttrs(match: Element, branchIndexes?: Set<number>) : AttrChangeInfo[]
 } 
 
 export interface MountContext{
@@ -170,11 +172,15 @@ export interface AddLoadEventListener{
 //#endregion
 
 //#region MountObserver Script Element
-export interface MountObserverScriptElement extends HTMLScriptElement{
+export interface MOSEAddedProps<TSynConfig=any>{
     init: JSONSerializableMountInit;
-    //mountedElements: Array<WeakRef<Element>>;
     observer: IMountObserver;
     do: MountObserverCallbacks;
+    synConfig: TSynConfig;
+}
+export interface MOSE<TSynConfig=any> 
+    extends HTMLScriptElement, MOSEAddedProps<TSynConfig>{
+
 }
 //#endregion