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

Prepare all the things #3319

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

Prepare all the things #3319

wants to merge 6 commits into from

Conversation

sidvishnoi
Copy link
Member

No description provided.

@marcoscaceres
Copy link
Contributor

Can you help me understand a bit more of what we want to achieve here? The original plugin design was to allow anything synchronous (e.g., preloading, loading styles, etc) in the module to happen independently, in parallel, and in a mostly indeterministic manner to every other module.... maybe that was a bad thing? I'm worried that prepare() puts us back into a linear plugin execution order, although maybe the determinism of calling .prepare() might be good in places?

@sidvishnoi
Copy link
Member Author

sidvishnoi commented Feb 23, 2021

I'm worried that prepare() puts us back into a linear plugin execution order, although maybe the determinism of calling .prepare() might be good in places?

All prepare calls are non-blocking (yet serially deterministic), so we won't get a bad form of linear plugin execution order. That is, no prepare call will cause a slowdown.

As we've access to conf and state, we can start some requests earlier in parallel without waiting on other plugins. So we should get faster processing instead of "slow as in serial". (See core/a11y here and core/caniuse earlier as examples)

It'll also add consistency in how plugins and their state are managed. For example with core/biblio: earlier even if we called core/biblio late in plugin order, its dependencies still did await biblio, adding a convulated serial order. With conf.state and prepare, only the plugin order in profiles determines what's available to subsequent plugins, which is much cleaner.

It terms of clarity, also see how we removed an unnecessary async-await with resolveRef.

@marcoscaceres
Copy link
Contributor

I'm not really liking the conf.state thing... could each plugin just export its own state instead?

@marcoscaceres
Copy link
Contributor

As we've access to conf and state, we can start some requests earlier in parallel without waiting on other plugins. So we should get faster processing instead of "slow as in serial". (See core/a11y here and core/caniuse earlier as examples)

I like this idea in principle.

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

Successfully merging this pull request may close these issues.

2 participants