Rename preload method to load in lazy

[snnsnn]

solid/packages/solid/src/render/component.ts

Line 316 in 1593dd6

): T & { preload: () => Promise<{ default: T }> } {

The name preload implies something that happens beforehand and does not describe the action it carries out. load would be a more accurate name for it.

[deluksic]

IMO the naming is actually good as it reminds me of image preloading, see https://web.dev/preload-responsive-images/. If I understand the API correctly (not documented!) preload is used to trigger fetching before rendering the actual component later (this where pre- comes from, I assume).

[snnsnn]

No, there is no preloading mechanism in lazy loading, that is why it is called lazy loading and that is exactly why it is misleading which you prove it unknowingly :)

[deluksic]

I don't understand what you mean by "there is no preloading mechanism". I can call .preload() and it will fetch the component ahead of rendering, so once the component is actually rendered, the user doesn't need to wait (as long). In other words, the component was "preloaded".

I also understand that the action itself is indeed to "load" the component. I just wanted to voice my preference for keeping it preload as that is how I think about this situation and it correctly conveyed the meaning in my personal experience (even without docs explicitly explaining it).

I admit I don't have much experience with it in SolidStart and how it interacts with SSR.

[snnsnn]

What I meant by "there is no preloading mechanism" is that there is no preloading mechanism akin to image preloads. The functionality of the lazy function is all about module loading, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import, i think it is best to keep the terminology close to the underlying mechanism and the general use of the concepts. Modules are always meant to be loaded. The action is loading, not doing something in advance. Pre would be a good fit if the function controls a setting that triggers the loading mechanism. Its use is not limited to components, you can lazy load any JavaScript module.

The import() syntax, commonly called dynamic import, is a function-like expression that allows loading an ECMAScript module asynchronously and dynamically into a potentially non-module environment.

I believe it is best if there is less room for assumptions and associations. So, the name "load" in my mind bring it closer to what it does while preload shifts the balance towards prefetching and calls mental association with all the browser API that is prefixed with the word pre. "load" is also good for documentation because now a single line like "It loads the module" is enough. We should actively dissociate from the word pre because of all the connotations.

From the SSR perspective, a lazy loaded module is not any different than other async values.

[deluksic]

I understand that perspective as well, thank you for writing it out. 👍🏻

[lxsmnsyc]

The thing is preload is the more correct term here because you're loading the module ahead-of-time, unlike the usual way of "load the module when attempting to render the component". This is also how preloading in the other resources like images behave.

The only visual difference here is that a non-preloaded lazy component would have to go through the fallback process (Suspense).

[ryansolid]

Yeah I see the argument for both sides, but components purpose is to be lazily loaded on render. I know we could argue it either way. But generally loading it before render is preloading in this case which isn't enough for a breaking API change. Since this is going nowhere I'm doing some cleanup and closing.