Async resource definition

[theKashey]

Feature request

• Allow route definition level code splitting.

Details

Right now the only way to code split resource logic is to implement getDataLoader for a resource, while resources are more or less static property on the route definition.

While getDataLoader seems to be the correct way of doing it - it allows some "already loaded resources" to act sooner - it creates some over complications if has to be compulsorily used, and in our case it is.

Proposal

• extend resources field of Route to also accept a function resolving into a set of promises
• or extend resource in resources to accept a LazyResource, and expose a helper function to convert import('my-resource') into such object.

What is solves

In feature request is not changing anything for the end customer, however makes life of a developer a little easier, decreasing the initial bundle size as well by making it easier to defer resources without any extra code written.

[albertogasparin]

This is an interesting idea. Needs some spiking as not entirely sure of the implications if we cannot immediately know the type and the getKey function. I'm especially thinking about hydration from SSR, where we pass the state directly to the router and expect useResource hooks to immediately render with data 🤔

[theKashey]

The resource chunk existence before the application start sounds not like a big problem for code splitting, however in this case it will be loaded with the full dataLoader as well, bringing more code than required initially. Quite far from the perfect.

Sounds like writting a little more code is still a better idea.

[albertogasparin]

I'll close this issue for now, if we have better ideas for the future happy to reopen :)