mount-observer 0.0.39 → 0.0.40

package/MountObserver.js

@@ -25,7 +25,10 @@ export class MountObserver extends EventTarget {
             throw 'NI'; //not implemented
         this.#mountInit = init;
         this.#abortController = new AbortController();
-        this.mountedElements = new WeakSet();
+        this.mountedElements = {
+            weakSet: new WeakSet(),
+            setWeak: new Set(),
+        };
         this.#disconnected = new WeakSet();
         //this.#unmounted = new WeakSet();
     }
@@ -218,10 +221,14 @@ export class MountObserver extends EventTarget {
         const alreadyMounted = await this.#filterAndDismount();
         const mount = this.#mountInit.do?.mount;
         const { import: imp } = this.#mountInit;
+        const me = this.mountedElements;
         for (const match of matching) {
             if (alreadyMounted.has(match))
                 continue;
-            this.mountedElements.add(match);
+            if (!me.weakSet.has(match)) {
+                me.setWeak.add(new WeakRef(match));
+                me.weakSet.add(match);
+            }
             if (imp !== undefined) {
                 switch (typeof imp) {
                     case 'string':

package/MountObserver.ts

@@ -2,7 +2,7 @@ import {MountInit, IMountObserver, AddMutationEventListener,
     MutationEvent, dismountEventName, mountEventName, IMountEvent, IDismountEvent,
     disconnectedEventName, IDisconnectEvent, IAttrChangeEvent, attrChangeEventName, AttrChangeInfo, loadEventName, ILoadEvent,
     AttrParts,
-    MOSE
+    MOSE, WeakDual
 } from './ts-refs/mount-observer/types';
 import {RootMutObs} from './RootMutObs.js';
 export {MOSE} from './ts-refs/mount-observer/types';
@@ -14,7 +14,7 @@ export class MountObserver extends EventTarget implements IMountObserver{
     #mountInit: MountInit;
     //#rootMutObs: RootMutObs | undefined;
     #abortController: AbortController;
-    mountedElements: WeakSet<Element>;
+    mountedElements: WeakDual<Element>;
     #mountedList: Array<WeakRef<Element>> | undefined;
     #disconnected: WeakSet<Element>;
     //#unmounted: WeakSet<Element>;
@@ -34,7 +34,10 @@ export class MountObserver extends EventTarget implements IMountObserver{
         if(whereElementIntersectsWith || whereMediaMatches) throw 'NI'; //not implemented
         this.#mountInit = init;
         this.#abortController = new AbortController();
-        this.mountedElements = new WeakSet();
+        this.mountedElements = {
+            weakSet: new WeakSet(),
+            setWeak: new Set(),
+        };
         this.#disconnected = new WeakSet();
         //this.#unmounted = new WeakSet();
     }
@@ -232,10 +235,13 @@ export class MountObserver extends EventTarget implements IMountObserver{
         const alreadyMounted = await this.#filterAndDismount();
         const mount = this.#mountInit.do?.mount; 
         const {import: imp} = this.#mountInit;
-        
+        const me = this.mountedElements;
         for(const match of matching){
             if(alreadyMounted.has(match)) continue;
-            this.mountedElements.add(match);
+            if(!me.weakSet.has(match)){
+                me.setWeak.add(new WeakRef(match));
+                me.weakSet.add(match);
+            }
             if(imp !== undefined){
                 switch(typeof imp){
                     case 'string':

package/README.md

@@ -11,15 +11,17 @@ Author:  Bruce B. Anderson (with valuable feedback from @doeixd )
 
 Issues / pr's / polyfill:  [mount-observer](https://github.com/bahrus/mount-observer)
 
-Last Update: Oct 6, 2024
+Last Update: Dec 11, 2024
 
 ## Benefits of this API
 
 What follows is a far more ambitious alternative to the [lazy custom element proposal](https://github.com/w3c/webcomponents/issues/782).  The goals of the MountObserver api are more encompassing, and less focused on registering custom elements.  In fact, this proposal addresses numerous use cases in one api.  It is basically mapping common filtering conditions in the DOM, to mounting a "campaign" of some sort, like importing a resource, and/or progressively enhancing an element, and/or "binding from a distance".
 
-["Binding from a distance"](https://github.com/WICG/webcomponents/issues/1035#issuecomment-1806393525) refers to empowering the developer to essentially manage their own "stylesheets" -- but rather than for purposes of styling, using these rules to attach behaviors, set property values, etc, to the HTML as it streams in.  Libraries that take this approach include [Corset](https://corset.dev/) and [trans-render](https://github.com/bahrus/trans-render).  The concept has been promoted by a [number](https://bkardell.com/blog/CSSLike.html) [of](https://www.w3.org/TR/NOTE-AS)  [prominent](https://www.xanthir.com/blog/b4K_0) voices in the community. 
+["Binding from a distance"](https://github.com/WICG/webcomponents/issues/1035#issuecomment-1806393525) refers to empowering the developer to essentially manage their own "stylesheets" -- but rather than for purposes of styling, using these rules to attach behaviors, set property values, etc, to the HTML as it streams in.  Libraries that take this approach include [Corset](https://corset.dev/) and [trans-render](https://github.com/bahrus/trans-render), [selector-observer](https://github.com/josh/selector-observer), [pure](http://web.archive.org/web/20160313152905/https://beebole.com/pure/), [weld](https://github.com/tmpvar/weld), [bess](https://github.com/bkardell/bess).  The concept has been promoted by a [number](https://bkardell.com/blog/CSSLike.html) [of](https://www.w3.org/TR/NOTE-AS)  [prominent](https://www.xanthir.com/blog/b4K_0) voices in the community. 
 
-The underlying theme is this api is meant to make it easy for the developer to do the right thing, by encouraging lazy loading and smaller footprints. It rolls up most all the other observer api's into one, including, potentially, [a selector observor](https://github.com/whatwg/dom/issues/1285), which may be a similar duplicate to [the match-media counterpart proposal](https://github.com/whatwg/dom/issues/1225).
+The underlying theme is this api is meant to make it easy for the developer to do the right thing, by encouraging lazy loading and smaller footprints. It rolls up most all the other observer api's into one, including, potentially, [a selector observer](https://github.com/whatwg/dom/issues/1285), which may be a similar duplicate to [the match-media counterpart proposal](https://github.com/whatwg/dom/issues/1225).
+
+### Finite Element Analysis
 
 Most every web application can be recursively broken down into logical regions, building blocks which are assembled together to form the whole site.
 
@@ -33,7 +35,7 @@ At the micro level, components will have few, if any, dependencies, and those de
 
 ES module based web components may or may not be the best fit for these application macro "modules". A better fit might be a server-centric solution, like Rails, just to take an example.
 
-A significant pain point has to do with loading all the third-party web components and/or (progressive) enhancements that these macro components / compositions require, and loading them into memory only when needed.
+A significant pain point has to do with downloading all the third-party web components and/or (progressive) enhancements that these macro components / compositions require, and loading them into memory only when needed.
 
 
 ### Does this api make the impossible possible?
@@ -162,7 +164,7 @@ So what this does is only check for the presence of an element with tag name "my
 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:
 
 ```html
-<script type="mountobserver" id=myMountObserver onload="{...}"  onmount="{
+<script type="mountobserver" onload="{...}"  onmount="{
    const {matchingElement} = event;
    const {localName} = matchingElement;
    if(!customElements.get(localName)) {
@@ -188,11 +190,38 @@ const {modules, observer, mountedElements, mountInit} = myMountObserver;
 
 The "scope" of the observer would be the ShadowRoot containing the script element (or the document outside Shadow if placed outside any shadow DOM, like in the head element).
 
-No arrays of settings would be supported within a single tag (as this causes issues as far as supporting a single onmount, ondismount, etc event attributes), but remember that the "on" criteria can be an array of selectors.
+Once again, arrays of settings could be supported, which, in practice, would greatly increase the ratio between declarative, JSON-parsable instructions that could be performed in low-level c++/rust threads, vs custom JavaScript in the example above.  The events / callbacks would need to provide the index of which set of criteria was just fulfilled.
 
 > [!Note]
 > To support the event handlers above, I believe it would require that CSP solutions factor in both the inner content of the script element as well as all the event handlers via the string concatenation operator.  I actually think such support is quite critical due to lack of support of import.meta.[some reference to the script element] not being available, as it was pre-ES Modules.
 
+## Specific solution for lazy loading custom element definitions
+
+Since the example we've been dwelling on so far (lazy custom element definition) seems like such a pressing, common requirement, and was in fact the originating impetus for this proposal, we can go a step further and make the example above 100% declarative, thus resulting in a less clunky interplay between JSON and custom script.  This is meant as a way of illustrating how the platform could continue to extend this proposal going forward.
+
+The syntax below is just one, "spit-balling" way this could be done, as an example, and would require absorbing final heuristics from other custom element initiatives (such as declarative custom elements) when they get added to the platform.
+
+```html
+<script type="mountobserver">
+{
+   "on":"my-element",
+   "import": [
+      ["./my-element-small.css", {type: "css"}],
+      "./my-element.js",
+   ],
+   "define": {
+      "targetRegistry": "CustomElements",
+      "targetScope": "global",
+      "styleModules": [0],
+      "classDefinition": {
+         "module": 1,
+         "exportSymbol": 'MyElement'
+      }
+   }
+}
+</script>
+```
+
 
 ## Shadow Root inheritance
 
@@ -266,20 +295,25 @@ const observer = new MountObserver({
    on: 'div > p + p ~ span[class$="name"]',
    whereMediaMatches: '(max-width: 1250px)',
    whereSizeOfContainerMatches: '(min-width: 700px)',
-   whereInstanceOf: [HTMLMarqueeElement],
-   whereSatisfies: async (matchingElement, context) => true,
+   whereInstanceOf: [HTMLMarqueeElement], //or ['HTMLMarqueeElement']
    whereLangIn: ['en-GB'],
    whereConnection:{
       effectiveTypeIn: ["slow-2g"],
    },
    import: ['./my-element-small.css', {type: 'css'}],
    do: {
+      confirm: (matchingElement, (e: MountObserverConfirmEvent) => {
+         e.isSatisfied = true;
+         e.preventDefault();
+      }),
       mount: ({localName}, {modules}) => {
         ...
       },
       dismount: ...,
       disconnect: ...,
+      move: ...,
       reconnect: ...,
+      confirm: ...,
       reconfirm: ...,
       exit: ...,
       forget: ...,
@@ -287,7 +321,14 @@ const observer = new MountObserver({
 });
 ```
 
-Callbacks like we see above are useful for tight coupling, and probably are unmatched in terms of performance.  The expression that the "do" field points to could also be a (stateful) user defined class instance. 
+## InstanceOf checks in detail
+
+Carving out the special "whereInstanceOf" check is provided based on the assumption that there's a performance benefit from doing so. If not, the developer could just add that check inside the "confirm" callback logic.  For built-in elements, we can alternatively provide the string name, as indicated in the comment above, which certainly makes it JSON serializable, thus making it easy as pie to include in the MOSE JSON payload.  I don't think there would be any ambiguity in doing so, which means I believe that answers the mystery in my mind whether it could be part of the low-level checklist that could be done within the c++/rust code / thread.
+
+The picture becomes murkier for custom elements.  The best solution in that case seems to be to utilize customElements.getName(...) as a basis for the match, but at first glance, that could  preclude being able to use base classes which a family of custom elements subclass, if that superclass isn't itself a custom element.  I suppose the solution to this conundrum, when warranted, is simply to burden the developer with defining a custom element for the superclass, and thus assigning it a name, applicable within ShadowDOM scopes as needed, even though it isn't actually necessarily used for any live custom elements. This would require already having imported the base class, only benefitting from lazy loading the code needed for each sub class, which might not always be all that high as a percentage, compared to the base class.
+
+However, where this support for "whereInstanceOf" would be *most* helpful is when it comes to [*custom enhancements*](https://github.com/WICG/webcomponents/issues/1000) that only wish to lazily layer some heavy lifting functionality on top of certain families of already loaded and upgraded custom elements (possibly in addition to some (specified) built in elements).  Here, the lazy loading of the *entire custom **enhancement***, based on the presence in the DOM of a member of the family of custom elements, would, if my calculations are correct, result in providing a significant benefit. 
+ 
 
 <!--
 
@@ -295,13 +336,14 @@ Callbacks like we see above are useful for tight coupling, and probably are unma
 
 --> 
 
-However, since these rules may be of interest to multiple parties, it is useful to also provide the ability for multiple parties to subscribe to these css rules.  This can be done via:
-
 ## Subscribing
 
 Subscribing can be done via:
 
 ```JavaScript
+observer.addEventListener('confirm', e => {
+  e.isSatisfied = true; //or false to prevent the mount event below
+});
 observer.addEventListener('mount', e => {
   console.log({
       matchingElement: e.matchingElement, 
@@ -314,6 +356,9 @@ observer.addEventListener('dismount', e => {
 observer.addEventListener('disconnect', e => {
   ...
 });
+observer.addEventListener('move', e => {
+  ...
+});
 observer.addEventListener('reconnect', e => {
   ...
 });
@@ -336,14 +381,28 @@ The moment a MountObserver instance's "observe" method is called (passing in a r
 
 If an element that is in "mounted" state according to a MountObserver instance is moved from one parent DOM element to another:
 
-1)  "disconnect" event is dispatched from the MountObserver instance the moment the mounted element is disconnected from the DOM fragment.
+1)  "disconnect" event is dispatched from the MountObserver instance the moment the mounted element is disconnected from the DOM fragment (but not if employing the experimental but promising atomic moving API).
 2)  If/when the element is added somewhere else in the DOM tree, the mountObserver instance will dispatch event "reconnect", regardless of where. [Note:  can't polyfill this very easily]
 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". 
 
-Some of the events above are subject to change depending on the outcome of the [atomic moving](https://github.com/whatwg/dom/issues/1255) proposal.
+The move event would become available at the outset of the [atomic moving](https://github.com/whatwg/dom/issues/1255) proposal getting shipped universally.
+
+## Justification for callbacks as well as events, and discussion of the signature
+
+Callbacks like we saw in our earlier examples above are useful for tight coupling, and probably are unmatched in terms of performance.  The expression that the "do" field points to could in fact be a (stateful) user defined class instance.
+
+However, since these rules may be of interest to multiple parties, it is useful to also provide the ability for multiple parties to subscribe to these DOM filtering events.
+
+If the performance isn't impacted, I think it would be most convenient for the developer if, at a minimum, the second argument of the callbacks above in fact precisely match the loosely coupled events.  The callback would get the first dibs on the event, and have the opportunity to prevent the event from going any further before getting dispatched, using something like preventDefault. I don't yet have any compelling use cases for that scenario, but I think there probably are some.
+
+In which case the argument becomes quite strong that the inconsistency of making the callback methods above  have a separate parameter where the matching element is passed is unwise. Simply making the matching element be part of the event payload, as is done for the loosely coupled events discussed above, would reduce the learning curve, and make it easier to share logic between the two.  
+
+On the other hand, providing the matching element as a separate parameter makes the ergonomics a tiny bit smoother as far as dynamically ascertaining the local name and other properties of the element (i.e. destructuring requires one more step for lazily defining the custom element).  
+
+I'm on the fence on that one.   I think the benefits either way to DX are so small, that performance metrics should probably dictate which way to go.
 
 ## Dismounting
 
@@ -687,6 +746,16 @@ 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 need for importing templates by id is also demonstrated by Corset's [Todo list example](https://codepen.io/matthewp/details/ZEXpJYr):
+
+```CSS
+#todos {
+   each-items: ${todos};
+   each-template: select(#todo-template);
+   each-key: title;
+}
+```
+
 The mount-observer is always on the lookout for template tags with a src attribute starting with #:
 
 ```html

package/package.json

@@ -1,11 +1,11 @@
 {
   "name": "mount-observer",
-  "version": "0.0.39",
+  "version": "0.0.40",
   "description": "Observe and act on css matches.",
   "main": "MountObserver.js",
   "module": "MountObserver.js",
   "devDependencies": {
-    "@playwright/test": "1.48.0",
+    "@playwright/test": "1.49.1",
     "ssi-server": "0.0.1"
   },
   "exports": {

package/ts-refs/be-a-beacon/types.d.ts

@@ -11,8 +11,9 @@ export type PAP = Partial<AP>;
 
 export type ProPAP = Promise<PAP>;
 
+export type BAP = AP & BEAllProps;
 
 export interface Actions{
-    hydrate(self: AP & BEAllProps): PAP;
-    retire(self: AP & BEAllProps): void;
+    hydrate(self: BAP): PAP;
+    retire(self: BAP): void;
 }

package/ts-refs/be-alit/types.d.ts

@@ -0,0 +1 @@
+//using be-render-neutral for now, but that could change in the future

package/ts-refs/be-based/types.d.ts

@@ -0,0 +1,32 @@
+import {IEnhancement, BEAllProps} from '../trans-render/be/types';
+
+export interface EndUserProps extends IEnhancement{
+    forAll?: Array<string>,
+    base?: string,
+    fileName?: string
+    puntOn?: Array<string>,
+}
+
+export interface AllProps extends EndUserProps{
+    forAll: Array<string>,
+}
+
+
+export interface PuntEvent{
+    count: number,
+    instance: Element,
+}
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type ProPAP = Promise<PAP>
+
+
+
+export interface Actions{
+    hydrate(self: AP & BEAllProps): PAP;
+    //finale(): void;
+}
+

package/ts-refs/be-bound/types.d.ts

@@ -12,10 +12,7 @@ export interface EndUserProps extends IEnhancement{
 export interface AllProps extends EndUserProps{
     bindingRules: Array<BindingRule>,
     bindings: Array<Binding>,
-    //partialBindingRules?: Array<BindingRule>,
     isParsed?: boolean,
-    //parsedWith?: boolean,
-    //parsedBetween?: boolean,
     rawStatements?: Array<string>
 }
 

package/ts-refs/be-buttoned-up/types.d.ts

@@ -0,0 +1,21 @@
+import {IEnhancement, BEAllProps} from '../trans-render/be/types';
+
+export interface EndUserProps extends IEnhancement<HTMLButtonElement>{
+    closeOnSelect: boolean;
+    eventName: string;
+}
+
+export interface AllProps extends EndUserProps {}
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type ProPAP = Promise<PAP>;
+
+
+export type BAP = AP & BEAllProps;
+
+export interface Actions{
+    hydrate(self: BAP): PAP
+}

package/ts-refs/be-calculating/types.d.ts

@@ -8,6 +8,7 @@ export interface EndUserProps extends IEnhancement<HTMLElement>{
     forAttr?: string,
     handler: string
     eventArg: string,
+    js: string,
 }
 
 export interface AllProps extends EndUserProps{
@@ -26,10 +27,12 @@ export interface AllProps extends EndUserProps{
     isAttached?: boolean,
     isOutputEl?: boolean,
     enhElLocalName: string,
+    enhKey: string,
     categorized?: boolean,
     remSpecifierLen?: number,
     propToAO: {[key: string] : AbsorbingObject},
     checkedRegistry: boolean,
+    notYetParsedJS: boolean,
 } 
 
 export type AP = AllProps;
@@ -50,4 +53,5 @@ export interface Actions{
     genRemoteSpecifiers(self: BAP): PAP;
     seek(self: BAP): ProPAP;
     hydrate(self: BAP): ProPAP;
+    parseJS(self: BAP): ProPAP;
 }

package/ts-refs/be-clonable/types.d.ts

@@ -0,0 +1,28 @@
+import { IEnhancement, BEAllProps } from '../trans-render/be/types';
+
+export interface EndUserProps extends IEnhancement{
+    triggerInsertPosition: InsertPosition;
+    cloneInsertPosition?: InsertPosition;
+    buttonContent: string;
+}
+
+export interface AllProps extends EndUserProps{
+    byob?: boolean,
+    trigger?: WeakRef<HTMLButtonElement>
+}
+
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type ProPAP = Promise<PAP>;
+
+export type BAP = AP & BEAllProps;
+
+
+export interface Actions{
+    addCloneBtn(self: BAP): ProPAP;
+    setBtnContent(self: BAP): void;
+    beCloned(self: BAP): void;
+}

package/ts-refs/be-delible/types.d.ts

@@ -0,0 +1,26 @@
+import { IEnhancement, BEAllProps } from '../trans-render/be/types';
+
+export interface EndUserProps extends IEnhancement{
+    triggerInsertPosition: InsertPosition;
+    buttonContent: string;
+}
+
+export interface AllProps extends EndUserProps{
+    byob?: boolean,
+    trigger: WeakRef<HTMLButtonElement>
+}
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type ProPAP = Promise<PAP>;
+
+export type BAP = AP & BEAllProps;
+
+export interface Actions{
+    
+    addDeleteBtn(self: BAP): ProPAP ;
+    setBtnContent(self: BAP): void;
+    beDeleted(self: BAP): void;
+}

package/ts-refs/be-elevating/types.d.ts

@@ -0,0 +1,55 @@
+import {IEnhancement, BEAllProps} from '../trans-render/be/types';
+import {AbsorbingObject, SharingObject} from '../trans-render/asmr/types';
+import { Specifier } from "../trans-render/dss/types";
+
+export interface EndUserProps extends IEnhancement{
+    /**
+     * abbrev for pass server-rendered value
+     * This will pass the initial value from the enhanced element if applicable
+     */
+    passSRV: boolean
+}
+
+export interface AP extends EndUserProps {
+    //parsedStatements?: Array<ElevatingParameters>,
+    bindings: Array<Binding>,
+    rawStatements?: Array<string>,
+    bindingRules: Array<BindingRule>,
+}
+
+export type AllProps = AP;
+
+export type BAP = AP & BEAllProps;
+
+export type PAP = Partial<AP>
+
+export type ProPAP  = Promise<PAP>
+
+export interface Actions{
+    noAttrs(self: BAP): ProPAP;
+    hydrate(self: BAP): ProPAP;
+    getBindings(self: BAP): ProPAP;
+    onRawStatements(self: BAP): void;
+}
+
+// export interface ElevatingParameters {
+//     localPropToElevate?: string,
+//     remoteSpecifiers: Array<Specifier>,
+//     localEventType?: string,
+// }
+
+export interface BindingRule {
+    
+    localPropToElevate?: string,
+    localEventType?: string,
+    dependencyPart?: string,
+    remoteSpecifier?: Specifier,
+
+
+}
+
+export interface Binding {
+    remoteShareObj: SharingObject,
+    localAbsObj: AbsorbingObject,
+}
+

package/ts-refs/be-eventing/types.d.ts

@@ -0,0 +1,27 @@
+import {IEnhancement, BEAllProps} from '../trans-render/be/types';
+
+// export interface EventHandlingScriptElement extends HTMLScriptElement{
+//     on: {[key: string]: (e: Event) => void}
+//     e: (e: Event) => void;
+// }
+
+export interface EndUserProps extends IEnhancement<HTMLScriptElement>{
+    nudges: string,
+    on: string,
+    onNudges: string,
+}
+
+export interface AllProps extends EndUserProps{}
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type ProPAP = Promise<PAP>;
+
+export type BAP = AP & BEAllProps;
+
+export interface Actions{
+    calcDefaults(self: BAP): ProPAP,
+    hydrate(self: BAP): ProPAP,
+}

package/ts-refs/be-formalizing/types.d.ts

@@ -0,0 +1,29 @@
+import {BEAllProps, IEnhancement} from '../trans-render/be/types';
+
+export interface EndUserProps extends IEnhancement<HTMLFormElement> {
+    triggerInsertPosition: InsertPosition;
+    buttonContent: string;
+}
+
+export interface AllProps extends EndUserProps{
+    byob?: boolean;
+    trigger: WeakRef<HTMLButtonElement>
+}
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type BAP = AP & BEAllProps
+
+export type ProPAP = Promise<PAP>;
+
+export interface Actions{
+    addFormalizeBtn(self: BAP): ProPAP;
+    setBtnContent(self: BAP): void;
+    openDialog(self: BAP): Promise<void>
+}
+
+export interface IFormDialog{
+    openDialog();
+}

package/ts-refs/be-formidable/types.d.ts

@@ -0,0 +1,64 @@
+import {BEAllProps, IEnhancement} from '../trans-render/be/types';
+
+export interface EndUserProps extends IEnhancement<HTMLFormElement>{
+    invalidIf: Array<FormCriteria>,
+    checkValidityOn: string | Array<(string | CheckEventMonitor)>,
+    checkValidityOnInit: boolean;
+}
+
+export interface AllProps extends EndUserProps{
+    invalidClassesToApply: Array<string>,
+    invalidClassesToRemove: Array<string>,
+    isValid: boolean,
+    updateCnt: number,
+}
+
+export interface FormCriteria{
+    noneOf?: Array<(string | FieldOptions)>,
+    //instructions?: string,
+    invalidCssClass: string,
+}
+
+export interface FieldIdentifierOptions {
+    name?: string,
+    prop: string,
+    find?: string,
+
+}
+
+export interface FieldValidationOptions{
+    enabled?: boolean,
+    required?: boolean,
+    min?: number | Date | string,
+    max?: number | Date | string,
+    pattern?: string,
+    type?: string,
+}
+
+export interface FieldOptions extends FieldIdentifierOptions, FieldValidationOptions{}
+
+export interface CheckEventMonitor{
+    type: string,
+    options: AddEventListenerOptions,
+}
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type ProPAP = Promise<PAP>;
+
+export type BAP = AP & BEAllProps;
+
+
+
+export interface Actions{
+    hydrate(self: BAP): ProPAP,
+    markStatus(self: BAP): void,
+    checkValidity(self: BAP): void,
+    applyInvalidClsses(self: BAP): void,
+    removeInvalidClasses(self: BAP): void,
+    // onInvalidIf(self: this): Promise<void>;
+    // onCheckValidityOn(self: this): void;
+    // onCheckValidityOnInit(self: this): void;
+}

package/ts-refs/be-kvetching/types.d.ts

@@ -0,0 +1,24 @@
+import {BEAllProps, EventListenerOrFn, IEnhancement} from '../trans-render/be/types';
+
+export interface EndUserProps extends IEnhancement<HTMLElement>{
+
+}
+
+export interface AllProps extends EndUserProps{
+    isParsed?: boolean,
+}
+
+export type WithStatement = string;
+
+export type AP = AllProps;
+
+export type PAP = Partial<AP>;
+
+export type ProPAP = Promise<PAP>;
+
+export type BAP = AP & BEAllProps;
+
+
+export interface Actions{
+    register(self: BAP): ProPAP;
+}