cjss-group / CJSS

A CSS based web framework
https://cjss.js.org/
MIT License
670 stars 20 forks source link

When to render #51

Open c-harding opened 5 years ago

c-harding commented 5 years ago

At the moment, rendering happens as soon as the page has finished loading, so every other plugin has to be loaded synchronously as the page is loading.

We could do some funky stuff with promises to await plugins being loaded, so those elements don't load until all the elements are ready, but then we'll have to rethink the loading of plugins with multiple modes (e.g. if we fire the promise the moment a plugin is loaded, then e.g. CJSS.registerPlugin('x', f); CJSS.registerPlugin('x', g, CJSS.Stage.BODY); will fire the plugin with f before the plugin with g). This could possibly be solved by refactoring registerPlugin:

// Only selected stages:
CJSS.registerPlugin('y', { [CJSS.Stage.DATA]: h });

// All stages, with an override for a specific stages:
CJSS.registerPlugin('x', f, { [CJSS.Stage.BODY]: g });

Alternatively, maybe we should require the user to manually call CJSS.render() on the document. If we are doing this, how else could we make the CJSS.render better suited for manual calling? I would suggest allowing it to take an element as an argument, to only apply the rendering to a portion of the DOM (remembering to allow rewriting the element itself, but not in the recursive case). There should also be the option to cache the parsed CJSS (true: use cache if possible, otherwise generate cache, false: use cache if possible, then clear cache), which will save time on future renders if the user anticipates rendering multiple elements/times, but also require a fair bit of memory. There is also the problem that rerendering a component that uses yield will not go well. A workaround would be to store the original contents (which will likely not be too inefficient, as those elements will probably remain in the DOM anyway).

Ryuno-Ki commented 5 years ago

I don't like it personally, but have you considered Reactive programming / RxJS here?

c-harding commented 5 years ago

To me that sounds like overkill, but maybe it would be useful. The current implementation uses very little memory after the initial page load, and I would be worried the pages would get heavier unnecessarily if we do that.

Ryuno-Ki commented 5 years ago

That's one of my main concerns as well. However, the only other alternative I know of are callbacks... But gere, managing the dependencies could be hairy.

Ideally, something „RxJS light“ would be handy (using only a subset of its features).

Ryuno-Ki commented 5 years ago

*gere -> here