dxinteractive / dendriform Goto Github PK

New data type that can lazily derive, async, for heavy operations.

• LazyDeriver can subscribe to dendriforms and other lazyderivers
• its value returns a promise and accessing it kicks off the lazy derivation
• each lazy derivation waits for all the lazyderivers it is subscribed to before doing its own computation
• lazyderiver results are cached, and the cache is only cleared when any dendriform it is subscribed to changes, or when any lazyderiver it is subscribed to has its cache cleared
• if a lazyderiver has its cache cleared but also has a currently active useValue() hook, it will kicks off its lazy derivation again
• some option to say what the fallback value for the lazyderiver is, to be used by the useValue() hook - it may even want to pass through something that its subscribed to (e.g. image rendering that builds up over time) or keep its old value until the new one is done deriving.
• some piece of state that says if derivation is in progress

const nameForm = new Dendriform('cool');
const ageForm = new Dendriform(12);

const picture = new LazyDeriver(async () => {
    coolCanvas.text('name', nameForm.value);
    coolCanvas.text('age', ageForm.value);
    return await coolCanvas.render();
}, [nameForm, ageForm]);

button.onClick(() => {
    document.appendChild(await picture.value);
});

// react
function Compy() {
    const picture = useLazyDeriver(async () => {
        coolCanvas.text('name', nameForm.value);
        coolCanvas.text('age', ageForm.value);
        return await coolCanvas.render();
    }, [nameForm, ageForm]);

    const pictureInverted = useLazyDeriver(async () => {
        return await picture.invert();
    }, [picture]);

    return <div>{pictureInverted.useValue()}</div>;
}

Be able to make forms that test potential changes with a function, and do not accept changes if that test fails. Also don't allow changes to go through if derived functions fail too. Might involve an internal revert function that can be called on all derived things.

This could allow for a generalised "collection of items whose ids refer to specific other items lifespans" construct

See facebook/react#955 (comment)

Async buffering is an API nicety, but the timing issues it causes aren't worth the hassle.

Right now if two changes can squeeze in rapid succession before a setTimeout(..., 0) can fire, then dendriform may push out an update that is stale compared to any state hooks that are tracking the same data in real time. This isn't the worst thing but can cause unavoidable cursor jumping if values are bound onto text inputs, and maybe worse.

Proposed solution

• Make .set() not async by removing the setTimeout()
• Add a batch() and flush() methods, and If someone wants to call 2 set() in a row they must call batch() first and finish with flush(). In dev mode we can warn if 2 sets get called too fast (less than setImmediate), and if flush isn't called fast enough (more than setImmediate)
• Confirm all the deriving still works

Perhaps onDerive is good enough for this?

Relies on #20

It can be useful for a set to pass along additional information in a set() so that onChange handlers can conditionally behave in a different way.

If any state is related to other state's lifespans, then we'll need to be able to know when a particular item in a dendriform tree is deleted.

• Treeshaking is not working properly
• Moving to multi entry imports would be a big win. The codebase is suitable to be split like this, and doesnt rely on treeshaking.
• Ditch tsdx and try using something like https://github.com/rollup/rollup-starter-lib/blob/typescript/rollup.config.js

// proposal
import {array} from 'dendriform';
// changes to
import {array} from 'dendriform/array';

Wouldn't require a breaking change.

When sync is used, people shouldn't also use onDerive() between the same forms, but making people do this is a tough ask, especially if different parts of a system may be deriving to each other. Instead make Dendriform have a register of sync groups, which sync can add to, and check which members of each have synced after deriving is complete, and throw no-change's in the others.

Instead of

const [value, setValue] = form.useValue();

it will be cleaner in most cases to have

const value = form.useValue();
// to set, call form.set();

because it avoids going form.useValue()[0] to do one-liners, reduces the API size (setValue and form.set are identical), and reduce confusion (setValue doesnt need to be used via a hook, but value does in order to receive updates)

Haven't hit this in the wild yet.

Quite a lot of potential crossover with #73.

Add something like form.readonly() that returns the same form but where .set() is disabled. This'll allow the observable abilities of forms to be spread around an app while also being able to whitelist where the forms value can be updated from.

Because form.buffer() and form.done() aren't global, and they rely on callAllChangeCallbacks() not being called in order to buffer changes.

Make it rely on focus to the correct demo too

Allows debouncing to be used anywhere a .set() can take place. Perhaps as form.set("new", 200)