webcomponenthelpers / imperajs Goto Github PK

Add possibility to attach to already instantiated object.
Meaning: now can only attach to a class HTMLElement trough a mixin. Make this functionality available also for already instantiated objects

Somehow the functions are there in recursive inheritance but not the props.
Seems like the constructor (that runs twice) will run both times with the last list. For now workraound is to put in listOfComponents both stateVariables.

This can be an advantage because then one can split states in several files that after will import with

import * as AwesomeName from ....

and one could feed directly that object to stateMixin...
writing those list is annoying...

if one enhance a web-component via the statesMixin it is assumed that this web-component is defined afterwards the StateElement (state manager).

Problem:
If one enhance to state manager a view element and wants to lazily load that view with all its states, well this works, but it will fail if one of the state-enhanced web-component was already defined, for example because used in another view.

Why:
it fails because the watch-handler events are send at the connectedCallback.

Fix:
Maybe one can add a property (maybe better attribute or constructor?) to fill for this use case by the user with the name of the element to check if defined, with something like:

window.customElements.whenDefined("...")

To make easy communication between custom elements one could immagine to register all of them to a message channel, so all of them will get the payload when posting a message to that channel.

modifying like this would work better:

on_update_message(event){
if(this === event.target) ---> do nothing
}

set a flag in the event detail to turn on/off this behavior.

so that one can add state variables declaratively via attribute. Useful if a state is view related and so not all component of the same type should have same states.

Problem: how do one define the update function?

Motivation

It suck a bit that async is not fully supported, meaning async-await pattern is not supported inside a transition (one can use a promise with callback to a transition, no problem), since the state must be changed sincronusly to guarantee a consistent state change and no possible race conditions. Also it sucks that it throws for transition in transition or similar, a good tool helps the developer and it feels like he shouldn't be worring about these things, should just work.

Refactoring idea:

Make the whole transition async, use the lock mechanism already in place. State transition would hold a promise that resolve when all watchers are called. This transition-promise gets stored in a global object. Each new transition check this object, exchange the found promise with one that resolves on its own transition and before start changing the state will await the promise previously found in the object.

Pros:

• Now Naturally all transition wait for each other and get executed in order.
• Nested transition also wait for completion and get executed in order
• Can use async-await in transition
• Fucking elegant solution

Preliminary syntax:

stateVar.AddTransition("data-fetch", async ()=>{
         await lock(()=>{ change state here; });
         await Net.fetch(....)  // do network call, the state is not locked here and other transition can happen in the mean time
         await lock(()=>{ change state here; }); // regain lock while before waiting on eventual transitions.
});

Cons:

• Is it really useful? I mean one can easily do the same pattern by just two independent transition and a net call.
• I don't seem to easily find a less ugly syntax.
• I get that Redux supports nested transitions and now one could do it also with impera, but why would you ever want to do that? Why would anyone want to run a transition from a callback that is supposed to apply UI state change, if you need to change state again, do it in the first transition, no?

Although not sure how usefull that can be...

Possibility for a global list, so that middleware added automatically to all, or push to list of single state component.

Add a list to StateTransition from which run middleware, before and after.

Give the possibility to user to define an overall storage engine or per variable storage engine.

Possible storage strategies:

• in memory
• localstorage
• indexDB