mount-observer 0.0.111 → 0.1.0

package/README.md

@@ -62,9 +62,7 @@ The amount of code necessary to accomplish these common tasks designed to improv
 3.  As discussed earlier, to do the job right, polyfills really need to reexamine **all** the elements within the observed node for matches **anytime any element within the Shadow Root so much as sneezes (has attribute modified, changes custom state, etc)**, due to modern selectors such as the :has selector.  Surely, the platform has found ways to do this more efficiently?  
 
 The extra flexibility this new primitive would provide could be quite useful to things other than lazy loading of custom elements, such as implementing [custom enhancements](https://github.com/WICG/webcomponents/issues/1000) as well as [binding from a distance](https://github.com/WICG/webcomponents/issues/1035#issuecomment-1806393525) in userland.
-
-> [!Note]
-> Reading through the historical links tied to the selector-observer proposal this proposal helped spawn, I may have painted an overly optimistic picture of [what the platform is capable of](https://github.com/whatwg/dom/issues/398).  It does leave me a little puzzled why this isn't an issue when it comes to styling, and also if some of the advances that were utilized to support :has could be applied to this problem space, so that maybe the arguments raised there have weakened.  Even if the concerns raised are as relevant today, I think considering the use cases this proposal envisions, that the objections could be overcome, for the following reasons: 1.  For scenarios where lazy loading is the primary objective, "bunching" multiple DOM mutations together and only reevaluating when things are quite idle is perfectly reasonable.  Also, for binding from a distance, most of the mutations that need responding to quickly will be when the *state of the host* changes, so DOM mutations play a somewhat muted role in that regard. Again, bunching multiple DOM mutations together, even if adds a bit of a delay, also seems reasonable.  I also think the platform could add an "analysis" step to look at the query and categorize it as "simple" queries vs complex.  Selector queries that are driven by the characteristics of the element itself (localName, attributes, etc) could be handled in a more expedited fashion.  Those that the platform does expect to require more babysitting could be monitored for less vigilantly.  Maybe in the latter case, a console.warning could be emitted during initialization.  The other use case, for lazy loading custom elements and custom enhancements based on attributes, I think most of the time this would fit the "simple" scenario, so again there wouldn't be much of an issue. 
+ 
 
 ## First use case -- lazy loading custom elements
 
@@ -72,26 +70,26 @@ To specify the equivalent of what the alternative proposal linked to above would
 
 ```JavaScript
 const observer = new MountObserver({
-   on:'my-element',
+   select:'my-element',
    import: './my-element.js',
-   do: {
-      mount: ({localName}, {modules, observer}) => {
-        if(!customElements.get(localName)) {
-            customElements.define(localName, modules[0].MyElement);
-        }
-        observer.disconnectedSignal.abort();
-      },
-   },
-   disconnectedSignal: new AbortController().signal
-});
+   do: ({localName}, {modules, observer, observeInfo}) => {
+      if(!customElements.get(localName)) {
+         customElements.define(localName, modules[0].MyElement);
+      }
+      observer.disconnectedSignal.abort();
+   }
+   
+}, {disconnectedSignal: new AbortController().signal});
 observer.observe(document);
 ```
 
+The do function will *only be called once per matching element* -- i.e. if the element stops matching the "select" criteria, then matches again, the do function won't be called again.  It will be called for all elements when they match within the scope passed in to the observe method.  However, the events discussed below, as well as more structured inline functions also as discussed below, will continue to be called repeatedly.
+
 The constructor 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 multiple "on" selectors are provided, and multiple ones match, I think it makes sense to indicate the one with the highest specifier that matches.  It would probably be helpful in this case to provide a special event that allows for knowing when the matching selector with the highest specificity changes for mounted elements.
+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 "select" 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 multiple "on" selectors are provided, and multiple ones match, I think it makes sense to indicate the one with the highest specifier that matches.  It would probably be helpful in this case to provide a special event that allows for knowing when the matching selector with the highest specificity changes for mounted elements.
 
-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.
+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.
 
@@ -99,24 +97,52 @@ But the observe method can accept a node within the document, or a shadowRoot, o
 
 The "observer" constant above is a class instance that inherits from EventTarget, which means it can be subscribed to by outside interests.
 
+> [!Note]
+> Reading through the historical links tied to the selector-observer proposal this proposal helped spawn, I may have painted an overly optimistic picture of [what the platform is capable of](https://github.com/whatwg/dom/issues/398).  It does leave me a little puzzled why this isn't an issue when it comes to styling, and also if some of the advances that were utilized to support :has could be applied to this problem space, so that maybe the arguments raised there have weakened.  Even if the concerns raised are as relevant today, I think considering the use cases this proposal envisions, that the objections could be overcome, for the following reasons: 1.  For scenarios where lazy loading is the primary objective, "bunching" multiple DOM mutations together and only reevaluating when things are quite idle is perfectly reasonable.  Also, for binding from a distance, most of the mutations that need responding to quickly will be when the *state of the host* changes, so DOM mutations play a somewhat muted role in that regard. Again, bunching multiple DOM mutations together, even if adds a bit of a delay, also seems reasonable.  I also think the platform could add an "analysis" step to look at the query and categorize it as "simple" queries vs complex.  Selector queries that are driven by the characteristics of the element itself (localName, attributes, etc) could be handled in a more expedited fashion.  Those that the platform does expect to require more babysitting could be monitored for less vigilantly.  Maybe in the latter case, a console.warning could be emitted during initialization.  The other use case, for lazy loading custom elements and custom enhancements based on attributes, I think most of the time this would fit the "simple" scenario, so again there wouldn't be much of an issue.
+
+In fact, I have encountered statements made by the browser vendors that some queries supported by css can't be evaluated simply by looking at the layout of the HTML, but has to be made after rendering and performing style calculations.  This necessitates having to delay the notification, which would be unacceptable.
+
+If the developer has a simple query in mind that needs no such nuance, I'm thinking it might be helpful to provide an alternative key to "on" that is used specifically for (a subset?) of queries supported by the existing "matches" method that elements support.
+
+So the developer could use:
+
+## Polyfill Supported Scenario I
+
+```JavaScript
+const observer = new MountObserver({
+   import: './my-element.js',
+   whereElementMatches:'my-element',
+   do: ({localName}, {modules, observer, observeInfo}) => {
+      if(!customElements.get(localName)) {
+         customElements.define(localName, modules[0].MyElement);
+      }
+      observer.disconnectedSignal.abort();
+   }
+   
+}, {disconnectedSignal: new AbortController().signal});
+observer.observe(document);
+```
+
+and could perhaps expect faster binding as a result of the more limited supported expressions.  Since "select" is not specified, it is assumed to be "*"
+
+This polyfill in fact only supports this latter option ("whreElementMatches"), and leaves "select" for such a time as when a selector observer is available in the platform.
+
 ##  The import key
 
 This proposal has been amended to support multiple imports, including of different types:
 
 ```JavaScript
 const observer = new MountObserver({
-   on:'my-element',
+   select:'my-element',
    import: [
       ['./my-element-small.css', {type: 'css'}],
       './my-element.js',
    ],
-   do: {
-      mount: ({localName}, {modules, observer}) => {
-        if(!customElements.get(localName)) {
-            customElements.define(localName, modules[1].MyElement);
-        }
-        observer.disconnectedSignal.abort();
+   do: ({localName}, {modules, observer}) => {
+      if(!customElements.get(localName)) {
+         customElements.define(localName, modules[1].MyElement);
       }
+      observer.disconnectedSignal.abort();
    }
 });
 observer.observe(document);
@@ -124,11 +150,11 @@ observer.observe(document);
 
 Once again, the key can accept either a single import, but alternatively 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.
+The do function 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, 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. 
+This proposal would also include support for JSON and HTML module imports (really, all types). 
 
 ## Preemptive downloading
 
@@ -137,21 +163,19 @@ There are two significant steps to imports, each of which imposes a cost:
 1.  Downloading the resource.
 2.  Loading the resource into memory.
 
-What if we want to download the resource ahead of time, but only load into memory when needed?
+What if we want to *download* the resource ahead of time, but only load into memory when needed?
 
 The link rel=modulepreload option provides an already existing platform support for this, but the browser complains when no use of the resource is used within a short time span of page load.  That doesn't really fit the bill for lazy loading custom elements and other resources.
 
-So for this we add option:
+So for this we add loadingEagerness:
 
 ```JavaScript
 const observer = new MountObserver({
-   on: 'my-element',
+   select: 'my-element',
    loadingEagerness: 'eager',
    import: './my-element.js',
-   do:{
-      mount: (matchingElement, {modules}) => customElements.define(modules[0].MyElement)
-   }
-})
+   do: ({localName}, {modules}) => customElements.define(localName, modules[0].MyElement),
+});
 ```
 
 So what this does is only check for the presence of an element with tag name "my-element", and it starts downloading the resource, even before the element has "mounted" based on other criteria.
@@ -175,7 +199,7 @@ Following an approach similar to the [speculation api](https://developer.chrome.
    observer.disconnectedSignal.abort();
 }">
 {
-   "on":"my-element",
+   "select":"my-element",
    "import": [
       ["./my-element-small.css", {type: "css"}],
       "./my-element.js",
@@ -206,7 +230,7 @@ The syntax below is just one, "spit-balling" way this could be done, as an examp
 ```html
 <script type="mountobserver">
 {
-   "on":"my-element",
+   "select":"my-element",
    "import": [
       ["./my-element-small.css", {type: "css"}],
       "./my-element.js",
@@ -233,7 +257,7 @@ Inside a shadow root, we can plop a script element, also with type "mountobserve
 #shadowRoot
 <script id=myMountObserver type=mountobserver>
 {
-   "on":"your-element"
+   "select":"your-element"
 }
 </script>
 ```
@@ -252,15 +276,18 @@ We will come back to some important [additional features](#creating-frameworks-t
 
 ## Binding from a distance
 
-It is important to note that "on" is a css query with no restrictions.  So something like:
+It is important to note that "select" is a css query with no restrictions.  So something like:
 
 ```JavaScript
 const observer = new MountObserver({
-   on:'div > p + p ~ span[class$="name"]',
+   select:'div > p + p ~ span[class$="name"]',
    do:{
       mount: (matchingElement) => {
          //attach some behavior or set some property value or add an event listener, etc.
          matchingElement.textContent = 'hello';
+      },
+      dismount: (matchingElement) => {
+         matchingElement.textContent = 'bye';
       }
    }
 })
@@ -268,8 +295,78 @@ const observer = new MountObserver({
 
 ... would work.
 
+Note that in this example, "do" no longer points to a function.  When it did (above), we mentioned this would only be called once per element.  **Now it will be called every the conditions flip from not all satisfied to satisfied"**.
+
 This would allow developers to create "stylesheet" like capabilities.
 
+## Applying properties with assignGingerly
+
+For the common use case of setting properties on matching elements, MountObserver provides built-in support for the [assignGingerly](https://github.com/bahrus/assign-gingerly) library. This allows you to declaratively specify properties to apply to elements without writing custom mount callbacks:
+
+```JavaScript
+const observer = new MountObserver({
+   whereElementMatches: 'input',
+   assignGingerly: {
+      disabled: true,
+      value: 'Default value',
+      title: 'This is a tooltip'
+   }
+});
+observer.observe(document);
+```
+
+This will automatically apply the specified properties to all matching input elements, both existing ones and those added dynamically.
+
+### Nested properties with dataset
+
+The `assignGingerly` library supports nested property assignment using the `?.` notation. This is particularly useful for setting data attributes:
+
+```JavaScript
+const observer = new MountObserver({
+   whereElementMatches: 'button',
+   assignGingerly: {
+      disabled: false,
+      '?.dataset.action': 'submit',
+      '?.dataset.trackingId': '12345'
+   }
+});
+observer.observe(document);
+```
+
+The `?.` prefix tells assignGingerly to create nested properties if they don't exist. In this example, `?.dataset.action` will set the `data-action` attribute on the button elements.
+
+### Combining with imports
+
+You can combine `assignGingerly` with lazy loading to both import resources and set properties:
+
+```JavaScript
+const observer = new MountObserver({
+   whereElementMatches: 'my-element',
+   import: './my-element.js',
+   assignGingerly: {
+      theme: 'dark',
+      '?.dataset.initialized': 'true'
+   },
+   do: ({localName}, {modules}) => {
+      if(!customElements.get(localName)) {
+         customElements.define(localName, modules[0].MyElement);
+      }
+   }
+});
+observer.observe(document);
+```
+
+The `assignGingerly` properties are applied after imports are loaded but before the `do` callback is invoked, ensuring that elements are properly configured before any custom initialization logic runs.
+
+### Performance benefits
+
+Using `assignGingerly` provides several benefits:
+
+1. **Lazy loading**: The assign-gingerly library is only loaded when needed (when the `assignGingerly` property is specified)
+2. **Bulk operations**: Properties are applied efficiently to all matching elements
+3. **Declarative**: No need to write custom mount callbacks for simple property assignments
+4. **Consistent**: The same property values are applied uniformly across all matching elements
+
 
 ##  Extra lazy loading
 
@@ -279,7 +376,7 @@ However, we could make the loading even more lazy by specifying intersection opt
 
 ```JavaScript
 const observer = new MountObserver({
-   on: 'my-element',
+   select: 'my-element',
    whereElementIntersectsWith:{
       rootMargin: "0px",
       threshold: 1.0,
@@ -294,13 +391,13 @@ Unlike traditional CSS @import, CSS Modules don't support specifying different i
 
 ```JavaScript
 const observer = new MountObserver({
-   on: 'div > p + p ~ span[class$="name"]',
+   select: 'div > p + p ~ span[class$="name"]',
    whereMediaMatches: '(max-width: 1250px)',
    whereSizeOfContainerMatches: '(min-width: 700px)',
    whereContainerHas: '[itemprop=isActive][value="true"]',
    whereInstanceOf: [HTMLMarqueeElement], //or ['HTMLMarqueeElement']
    whereLangIn: ['en-GB'],
-   whereConnection:{
+   whereConnectiselect:{
       effectiveTypeIn: ["slow-2g"],
    },
    import: ['./my-element-small.css', {type: 'css'}],
@@ -416,9 +513,9 @@ So the dismount event should provide a "checklist" of all the conditions, and th
 ```JavaScript
 mediaMatches: true,
 containerMatches: true,
-satisfiesCustomCondition: true,
+satisfiesCustomConditiselect: true,
 whereLangIn: ['en-GB'],
-whereConnection:{
+whereConnectiselect:{
    effectiveTypeMatches: true
 },
 isIntersecting: false,
@@ -459,7 +556,7 @@ For the polyfill, we need to support it as follows:
 ```JavaScript
 const oElement = document.getElementById('myTest');
 const observer = new MountObserver({
-   on:'[itemprop]',
+   select:'[itemprop]',
    outside: '[itemscope]'
    do: {
       mount: ({localName}, {modules, observer}) => {
@@ -531,7 +628,7 @@ Let's focus on the first scenario.  It doesn't make sense to use the word "where
 ```JavaScript
 import {MountObserver} from 'mount-observer/MountObserver.js';
 const mo = new MountObserver({
-   on: '*',
+   select: '*',
    observedAttrsWhenMounted: ['lang', 'contenteditable']
 });
 
@@ -613,7 +710,7 @@ Using the same expression structure as above, we would end up with this avalanch
 ```JavaScript
 import {MountObserver} from '../MountObserver.js';
 const mo = new MountObserver({
-   on: '*',
+   select: '*',
    whereAttr:{
       isIn: [
          'data-my-enhancement',
@@ -649,7 +746,6 @@ This seems like a much better approach, and is supported by this proposal:
 ```JavaScript
 import {MountObserver} from '../MountObserver.js';
 const mo = new MountObserver({
-   on: '*',
    whereAttr:{
       hasRootIn: ['data', 'enh', 'data-enh'],
       hasBase: 'my-enhancement',
@@ -670,7 +766,7 @@ MountObserver provides a breakdown of the matching attribute when encountered:
 <script type=module>
    import {MountObserver} from '../MountObserver.js';
    const mo = new MountObserver({
-      on: '*',
+      select: '*',
       whereAttr:{
          hasRootIn: ['data', 'enh', 'data-enh'],
          hasBase: 'my-enhancement',
@@ -727,7 +823,7 @@ An example of this in the real world can be found with [HTMX](https://htmx.org/d
 
 ```html
 <button hx-post="/example"
-        hx-on:htmx:config-request="event.detail.parameters.example = 'Hello Scripting!'">
+        hx-select:htmx:config-request="event.detail.parameters.example = 'Hello Scripting!'">
     Post Me!
 </button>
 ```
@@ -736,7 +832,7 @@ To support such syntax, specify the delimiters thusly:
 
 ```JavaScript
 const mo = new MountObserver({
-   on: '*',
+   select: '*',
    whereAttr:{
       hasRootIn: ['data', 'enh', 'data-enh'],
       hasBase: ['-', 'my-enhancement'],
@@ -758,7 +854,7 @@ Thus the mountObserver does provide that information to the consumer as well:
 
 ```JavaScript
 const mo = new MountObserver({
-   on: '*',
+   select: '*',
    whereAttr:{
       hasRootIn: ['data', 'enh', 'data-enh'],
       hasBase: ['-', 'my-enhancement'],
@@ -1015,7 +1111,7 @@ Just as it is useful to be able lazy load external imports when needed, it would
 <template id=source-template rel=conditional-stream>
 
    <template mount='{
-      "on": ":not([defer-loading])",
+      "select": ":not([defer-loading])",
       "loadingEagerness": "eager",
       "whereMediaMatches": "(min-width: 700px)",
       "whereLangIn": ["en-GB"],
@@ -1024,7 +1120,7 @@ Just as it is useful to be able lazy load external imports when needed, it would
    </template>
 
    <template mount='{
-      "on": ":not([defer-loading])",
+      "select": ":not([defer-loading])",
       "loadingEagerness": "lazy",
       "whereMediaMatches": "(max-width: 700px)",
       "whereLangIn": ["fr"],
@@ -1236,7 +1332,4 @@ To keep the api uniform, we hide this discrepancy by pretending the form element
    // includes both field1 and field2
    
 </script>
-```
-
-
-
+```

package/attrCoordinates.js

@@ -0,0 +1,93 @@
+/**
+ * Builds a map of attribute names to their coordinates based on whereAttr config
+ */
+export function buildAttrCoordinateMap(whereAttr, isCustomElement) {
+    const map = {};
+    const rootPrefixes = isCustomElement
+        ? (whereAttr.hasCERootIn || [])
+        : (whereAttr.hasBuiltInRootIn || []);
+    // Parse base attribute for custom delimiter
+    const { delimiter: baseDelimiter, name: baseName } = parseDelimiter(whereAttr.hasBase);
+    // Build attribute names for each prefix
+    for (const prefix of rootPrefixes) {
+        const baseAttrName = buildAttributeName(prefix, baseName, baseDelimiter);
+        // If no branches specified, just the base attribute
+        if (!whereAttr.hasBranchIn || whereAttr.hasBranchIn.length === 0) {
+            map[baseAttrName] = '0';
+            continue;
+        }
+        // Process each branch
+        for (let i = 0; i < whereAttr.hasBranchIn.length; i++) {
+            const branch = whereAttr.hasBranchIn[i];
+            if (branch === '') {
+                // Empty string means base attribute alone is valid
+                map[baseAttrName] = '0';
+                continue;
+            }
+            if (typeof branch === 'object') {
+                // Process branch object
+                processBranch(branch, baseAttrName, String(i), map);
+            }
+        }
+    }
+    return map;
+}
+/**
+ * Recursively processes a branch object to build attribute-coordinate mappings
+ */
+function processBranch(branch, parentAttrName, parentCoordinate, map) {
+    for (const [key, subBranches] of Object.entries(branch)) {
+        const { delimiter, name } = parseDelimiter(key);
+        const attrName = parentAttrName + delimiter + name;
+        // Process sub-branches
+        if (!subBranches || subBranches.length === 0) {
+            map[attrName] = parentCoordinate;
+            continue;
+        }
+        for (let i = 0; i < subBranches.length; i++) {
+            const subBranch = subBranches[i];
+            const coordinate = `${parentCoordinate}.${i}`;
+            if (subBranch === '') {
+                // Empty string means this level alone is valid
+                map[attrName] = parentCoordinate;
+                continue;
+            }
+            if (typeof subBranch === 'string') {
+                // Simple string sub-branch
+                const { delimiter: subDelimiter, name: subName } = parseDelimiter(subBranch);
+                const subAttrName = attrName + subDelimiter + subName;
+                map[subAttrName] = coordinate;
+                continue;
+            }
+            if (typeof subBranch === 'object') {
+                // Nested object - recursively process
+                processBranch(subBranch, attrName, coordinate, map);
+            }
+        }
+    }
+}
+/**
+ * Parses a key to extract custom delimiter and name
+ */
+function parseDelimiter(key) {
+    const match = key.match(/^\[(.+?)\](.+)$/);
+    if (match) {
+        return {
+            delimiter: match[1],
+            name: match[2]
+        };
+    }
+    return {
+        delimiter: '-',
+        name: key
+    };
+}
+/**
+ * Builds the full attribute name from prefix, base name, and delimiter
+ */
+function buildAttributeName(prefix, baseName, delimiter) {
+    if (prefix === '') {
+        return baseName;
+    }
+    return prefix + delimiter + baseName;
+}

package/attrCoordinates.ts

@@ -0,0 +1,122 @@
+import { WhereAttr, BranchValue } from './types.js';
+
+/**
+ * Represents a mapping from attribute name to coordinate
+ */
+export interface AttrCoordinateMap {
+    [attrName: string]: string;
+}
+
+/**
+ * Builds a map of attribute names to their coordinates based on whereAttr config
+ */
+export function buildAttrCoordinateMap(whereAttr: WhereAttr, isCustomElement: boolean): AttrCoordinateMap {
+    const map: AttrCoordinateMap = {};
+    const rootPrefixes = isCustomElement 
+        ? (whereAttr.hasCERootIn || [])
+        : (whereAttr.hasBuiltInRootIn || []);
+
+    // Parse base attribute for custom delimiter
+    const { delimiter: baseDelimiter, name: baseName } = parseDelimiter(whereAttr.hasBase);
+
+    // Build attribute names for each prefix
+    for (const prefix of rootPrefixes) {
+        const baseAttrName = buildAttributeName(prefix, baseName, baseDelimiter);
+
+        // If no branches specified, just the base attribute
+        if (!whereAttr.hasBranchIn || whereAttr.hasBranchIn.length === 0) {
+            map[baseAttrName] = '0';
+            continue;
+        }
+
+        // Process each branch
+        for (let i = 0; i < whereAttr.hasBranchIn.length; i++) {
+            const branch = whereAttr.hasBranchIn[i];
+            
+            if (branch === '') {
+                // Empty string means base attribute alone is valid
+                map[baseAttrName] = '0';
+                continue;
+            }
+
+            if (typeof branch === 'object') {
+                // Process branch object
+                processBranch(branch, baseAttrName, String(i), map);
+            }
+        }
+    }
+
+    return map;
+}
+
+/**
+ * Recursively processes a branch object to build attribute-coordinate mappings
+ */
+function processBranch(
+    branch: { [key: string]: BranchValue[] },
+    parentAttrName: string,
+    parentCoordinate: string,
+    map: AttrCoordinateMap
+): void {
+    for (const [key, subBranches] of Object.entries(branch)) {
+        const { delimiter, name } = parseDelimiter(key);
+        const attrName = parentAttrName + delimiter + name;
+
+        // Process sub-branches
+        if (!subBranches || subBranches.length === 0) {
+            map[attrName] = parentCoordinate;
+            continue;
+        }
+
+        for (let i = 0; i < subBranches.length; i++) {
+            const subBranch = subBranches[i];
+            const coordinate = `${parentCoordinate}.${i}`;
+
+            if (subBranch === '') {
+                // Empty string means this level alone is valid
+                map[attrName] = parentCoordinate;
+                continue;
+            }
+
+            if (typeof subBranch === 'string') {
+                // Simple string sub-branch
+                const { delimiter: subDelimiter, name: subName } = parseDelimiter(subBranch);
+                const subAttrName = attrName + subDelimiter + subName;
+                map[subAttrName] = coordinate;
+                continue;
+            }
+
+            if (typeof subBranch === 'object') {
+                // Nested object - recursively process
+                processBranch(subBranch, attrName, coordinate, map);
+            }
+        }
+    }
+}
+
+/**
+ * Parses a key to extract custom delimiter and name
+ */
+function parseDelimiter(key: string): { delimiter: string; name: string } {
+    const match = key.match(/^\[(.+?)\](.+)$/);
+    if (match) {
+        return {
+            delimiter: match[1],
+            name: match[2]
+        };
+    }
+    return {
+        delimiter: '-',
+        name: key
+    };
+}
+
+/**
+ * Builds the full attribute name from prefix, base name, and delimiter
+ */
+function buildAttributeName(prefix: string, baseName: string, delimiter: string): string {
+    if (prefix === '') {
+        return baseName;
+    }
+    return prefix + delimiter + baseName;
+}

package/constants.js

@@ -0,0 +1,6 @@
+// Constants for MountObserver
+export const loadEventName = 'load';
+export const mountEventName = 'mount';
+export const dismountEventName = 'dismount';
+export const disconnectEventName = 'disconnect';
+export const attrchangeEventName = 'attrchange';

package/constants.ts

@@ -0,0 +1,7 @@
+// Constants for MountObserver
+
+export const loadEventName = 'load';
+export const mountEventName = 'mount';
+export const dismountEventName = 'dismount';
+export const disconnectEventName = 'disconnect';
+export const attrchangeEventName = 'attrchange';

package/index.js

@@ -0,0 +1,3 @@
+// Main entry point for MountObserver v2
+export { MountObserver } from './MountObserver.js';
+export { mountEventName, dismountEventName, disconnectEventName, loadEventName } from './constants.js';

package/index.ts

@@ -0,0 +1,19 @@
+// Main entry point for MountObserver v2
+export { MountObserver } from './MountObserver.js';
+export type {
+    MountInit,
+    MountObserverOptions,
+    IMountObserver,
+    MountContext,
+    DoCallback,
+    DoCallbacks,
+    ImportSpec,
+    IMountEvent,
+    IDismountEvent
+} from './types.js';
+export {
+    mountEventName,
+    dismountEventName,
+    disconnectEventName,
+    loadEventName
+} from './constants.js';