Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When to render #51

Open
c-harding opened this issue Jun 24, 2019 · 4 comments
Open

When to render #51

c-harding opened this issue Jun 24, 2019 · 4 comments

Comments

@c-harding
Copy link
Collaborator

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
Copy link

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

@c-harding
Copy link
Collaborator Author

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
Copy link

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
Copy link

*gere -> here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants