bahrus / be-preemptive

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

be-preemptive

be-preemptive loads dependent resources eagerly, but not too eagerly.

<link rel=lazy id=package-name/theme.css as=script crossorigin=anonymous integrity=... fetchpriority=low be-preemptive=css href=https://some-cdn.com/package-name@1.2.3>

First use case (short-lived, hopefully) -- preemptive use of CSS Modules

Browser vendors and CDN's are taking their sweet time in providing support for CSS Modules. In the meantime, we can use this web component decorator / behavior to avoid that obstacle:

await customElements.whenDefined('be-preemptive');
const linkOrStylesheet = await self['package-name/theme.css'].beDecorated.preemptive.linkOrStylesheetPromise();

NB: Alternatives exist

In the case of Chromium-based browsers, you will be provided a Stylesheet, which can be adopted as needed. If not, you will probably want to append the returned link into your ShadowDOM root.

The value of rel can also be preload, which is really useful for non-lazy loaded web components. And because pre-emptive actually downloads the file, the browser won't complain about having a preload tag go unfulfilled.

rel can be anything, really.

Second use case (medium term, at most, hopefully?) -- passionately, but not aggressively, get needed resources ahead of time, without being chastised.

Beyond this short lived usage, be-preemptive will also preemptively perform a css module import, but (since the value of rel is lazy), after waiting for the document to finish parsing (at a minimum), so as not to slow anything else down.

However, calling the api above will start the download regardless.

This is meant for use cases where a web component lazy loads. Having css kept separate allows for multiple components to share the same css, and also web components can enable having the web component consumer design their own css without incurring any penalty from the default css if the developer chooses to just use the provided css with no customizations. A third benefit of maintaining separate css files is better fine-grained caching. Finally, tooling may be better when editing css separately (though tooling could also merge the files, so that is a rather weak consideration).

Having the css pre download ahead of time in this scenario is quite helpful, especially if streaming is used to stream in the HTML needed for the web component, w3c willing. This would allow the browser to render the web component progressively without suffering from FOUC.

The browser probably has a good reason for complaining about abusing link rel=preload, so this provides a way to achieve that goal, hopefully in a responsible way.

This functionality works well in combination with be-loaded and be-lazy.

Specify not doing anything preemptively based on the user agent's network connectivity [TODO]

But remember, the moment anyone calls the api above, the download will begin regardless of any hesitation parameters specified.

Use of fetchpriority [TODO]

Support for media queries [TODO]

Support for integrity [TODO]

Not yet supported, apparently

Resource Types supported

  1. CSS
  2. JSON [TODO]
  3. XSLT [TODO]
ezoic increase your site revenue

About

License:MIT License


Languages

Language:TypeScript 53.8%Language:JavaScript 46.2%