You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 🤔
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.
Feature request
route definition
level code splitting.Details
Right now the only way to code split resource logic is to implement
getDataLoader
for a resource, whileresources
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
resources
field of Route to also accept a function resolving into a set of promisesresource
inresources
to accept aLazyResource
, and expose a helper function to convertimport('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.
The text was updated successfully, but these errors were encountered: