Replies: 2 comments
-
In the apps I've written, parent loaders are typically "global" data, like current user, or summary data, like "sidebar" or "list", and the current route is the "detail". So I don't normally run into cases where I have a dependency on parent data. I try to structure my routes so the loader knows what data to fetch based on the contents of the URL (either via $params or query string). I like to think of the route as a function and the URL as the arguments. Any shared data, like the user, will typically be stored in a cache or session object. Each loader is responsible for fetching the needed data (but can be retrieved from shared cache). I try not to return the same data in multiple loaders. So the global user would be returned from the root loader. If I need that data in a child component, I use |
Beta Was this translation helpful? Give feedback.
-
In practice, the parent never renders as much of the data as the child, so you're pretty much always over fetching. Consider a List/Detail view where the sidebar renders some information about many records and the detail view renders a whole lot of one single record. If the parent loads the entire record for every record in the list and then you share that data with the child, you're fetching 10x to (literally) 1000x the data you actually need for the UI. Making two fetches, in parallel, will be much faster because it will send far less over the wire:
Additionally, these types of UIs are usually backed by data with thousands if not millions of records. You can't fetch all of them so there's no guarantee that the sidebar will be scrolled to the record you're looking at in the URL since the sidebar will be paginated (or a virtual list). |
Beta Was this translation helpful? Give feedback.
-
I'm currently working on a client-side framework which is centered around client-side filesystem routing and simplicity at the cost of possibilities (and occasionally performance). Thus, one of my goals is to abstract
react-router
as much as possible, so users never have to interact with the router itself. Since this blog post, I've been thinking about preparing for the implementation of remix-like data loading and creating some sort of abstraction for it.One of the things I've noticed with this feature is that, since data loading happen in parallel, there logically isn't a way to reliably fetch data which relies on data fetched by a parent route since the parent's data probably won't be available in time for the child. Unless I'm missing something, that means users would be required to use the "old way" of fetching when it requires some other data from the parent.
Since you all have been using these APIs for a while, what has your experience been with fetching data based on a parent's fetched data? Is it common? Are you required to fetch using the original method more often than not?
If it's extremely common that you can't make use of the new APIs, I might just not implement an abstraction for them at all to reduce complexity.
Also yes, while this feature isn't that complex once you understand it, my framework isn't targeting the experienced crowd. It's more of a middle-ground framework. It's designed to bridge the gap between simple one-page react apps and massive complex SPAs and abstract boilerplate code to allow users to start projects faster, assuming it's not too complex of a project.
Thank you for your time, I really appreciate it!
Beta Was this translation helpful? Give feedback.
All reactions