mount-observer 0.0.19 → 0.0.20

package/MountObserver.js

@@ -15,9 +15,10 @@ export class MountObserver extends EventTarget {
         super();
         const { on, whereElementIntersectsWith, whereMediaMatches } = init;
         let isComplex = false;
+        //TODO:  further this problem further.  Starting to think this is basically not polyfillable
         if (on !== undefined) {
             const reducedMatch = on.replaceAll(':not(', '');
-            isComplex = reducedMatch.includes(' ') || reducedMatch.includes(':');
+            isComplex = reducedMatch.includes(' ') || (reducedMatch.includes(':') && reducedMatch.includes('('));
         }
         this.#isComplex = isComplex;
         if (whereElementIntersectsWith || whereMediaMatches)

package/README.md

@@ -7,11 +7,11 @@ Note that much of what is described below has not yet been polyfilled.
 
 # The MountObserver api.
 
-Author:  Bruce B. Anderson (with valuable feedback from [doeixd](https://github.com/doeixd) )
+Author:  Bruce B. Anderson (with valuable feedback from @doeixd )
 
 Issues / pr's / polyfill:  [mount-observer](https://github.com/bahrus/mount-observer)
 
-Last Update: 2024-5-4
+Last Update: 2024-5-5
 
 ## Benefits of this API
 
@@ -72,6 +72,8 @@ observer.observe(document);
 
 Invoking "disconnect" as shown above causes the observer to emit event "disconnectedCallback".
 
+The argument can also be an array of objects that fit the pattern shown above.
+
 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.
@@ -235,7 +237,41 @@ If an element that is in "mounted" state according to a MountObserver instance i
 3)  If the mounted element is added outside the rootNode being observed, the mountObserver instance will dispatch event "exit", and the MountObserver instance will relinquish any further responsibility for this element.  
 4)  Ideally event "forget" would be dispatched just before the platform garbage collects an element the MountObserver instance is still monitoring, after all hard references are relinquished (or is that self-contradictory?).
 5)  If the new place it was added remains within the original rootNode and remains mounted, the MountObserver instance dispatches event "reconfirmed".
-6)  If the element no longer satisfies the criteria of the MountObserver instance, the MountObserver instance will dispatch event "dismount".  
+6)  If the element no longer satisfies the criteria of the MountObserver instance, the MountObserver instance will dispatch event "dismount". 
+
+## Dismounting
+
+In many cases, it will be critical to inform the developer **why** the element no longer satisfies all the criteria.  For example, we may be using an intersection observer, and when we've scrolled away from view, we can "shut down" until the element is (nearly) scrolled back into view.  We may also be displaying things differently depending on the network speed.  How we should respond when one of the original conditions, but not the other, no longer applies, is of paramount importance.
+
+So the dismount event should provide a "checklist" of all the conditions, and their current value:
+
+```JavaScript
+mediaMatches: true,
+containerMatches: true,
+satisifiesCustomCondition: true,
+whereLangIn: ['en-GB'],
+whereConnection:{
+   effectiveTypeMatches: true
+},
+isIntersecting: false,
+changedConditions: ['isIntersecting']
+```
+
+## Get play-by-play updates?
+
+An issue raised by @doeixd, I think, is what if we want to be informed of the status of all the conditions that are applicable to an element being mounted / dismounted?  I can see scenarios where this would be useful, for reasons similar to wanting to know why the element dismounted.
+
+Since this could have a negative impact on performance, I think it should be something we opt-in to:
+
+```JavaScript
+getPlayByPlay: true
+```
+
+Now the question is when should this progress reporting start?  It could either start the moment the element becomes mounted the first time.  Or it could happen the moment any of the conditions are satisfied.  But some of the conditions could be trivially satisfied for the vast majority of elements (e.g. network speed is 4g or greater).
+
+So I believe the prudent thing to do is wait for all the conditions to be satisfied,  before engaging in this kind of commentary, i.e. after the first mount.
+
+The alternative to providing this feature, which I'm leaning towards, is to just ask the developer to create "specialized" mountObserver construction arguments, that turn on and off precisely when the developer needs to know.
 
 ## A tribute to attributes
 
@@ -497,7 +533,7 @@ This proposal "sneaks in" one more feature, that perhaps should stand separately
 
 Also, this proposal is partly focused on better management of importing resources "from a distance", in particular via imports carried out via http.  Is it such a stretch to look closely at scenarios where that distance happens to be shorter, i.e. found somewhere [in the document tree structure](https://github.com/tc39/proposal-module-expressions)?
 
-The mount-observer is always on the lookout for template tags with an href attribute starting with #:
+The mount-observer is always on the lookout for template tags with a src attribute starting with #:
 
 ```html
 <template src=#id-of-source-template></template>
@@ -521,7 +557,7 @@ Let's say the source template looks as follows:
 
 ```html
 <template id=id-of-source-template>
-   I don't know why you say <slot name=slot2></slot> I say <slot name=slot1></slot>
+   <div>I don't know why you say <slot name=slot2></slot> I say <slot name=slot1></slot></div>
 </template>
 ```
 
@@ -583,3 +619,13 @@ This proposal (and polyfill) also supports the option to utilize ShadowDOM / slo
 </div>
 ```
 
+> [!NOTE]
+> An intriguing sounding alternative to using the template tag that disappears, as shown above, is to use a new tag for this purpose.  I think something along the lines of what is [proposed here](https://github.com/WICG/webcomponents/issues/1059) has a much better semantic ring to it:
+
+```html
+<compose src="#sharedHeader"></compose>
+<compose src="#productCard"></compose>
+```
+
+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.
+

package/package.json

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

package/types.d.ts

@@ -66,7 +66,7 @@ export interface MountContext{
 }
 
 type PipelineStage = 'Inspecting' | 'PreImport' | 'PostImport' | 'Import' 
-export type PipelineProcessor<ReturnType = void> = (matchingElement: Element, observer: IMountObserver, ctx: MountContext) => Promise<ReturnType>;
+export type PipelineProcessor<ReturnType = void> = (matchingElement: Element, observer: IMountObserver, ctx: MountContext) => Promise<ReturnType> | ReturnType;
 
 //#region mutation event
 export type mutationEventName = 'mutation-event';