Structuring Components dependent on resources

[Swandog]

Apologies if this has been answered before, I had trouble finding an answer.

I'm trying to figure out how to structure some of my components. My basic task is this:
I have a REST service that I am writing a CSR Leptos app for. One type I can get back from the API using a GET is a Dataset. Datasets have a list of Tasks associated with them, and also a list of Versions associated with them. However, getting the list of Tasks or Versions each require a separate GET request.

I'd like to make a page that can show, for a given dataset, the information about the dataset, the list of its tasks, and the list of its versions. Essentially, I'm thinking of something like this:

let dataset_information = create_resource(|| (), |_| async move { retrieve_dataset_info().await })

view! {
  <DatasetInfo dataset_information>
  <DatasetTaskList dataset_information>
  <DatasetVersionList dataset_information>
}

where DatasetInfo, DatasetTaskList, and DatasetVersionList are each components, and dataset_information is SOME type that can be used by each to build themselves.¹

But I'm having trouble deciding what is the best way of doing this. I've been testing out 3 options:

1. Make retrieve_dataset_info fetch all information relevant to all 3 components, i.e. retrieve_datset_info will do 3 separate GET requests and bundle up all the data from each into a new type that can be passed to each component, and those components just pick and choose which data is relevant to them. This is fairly straightfoward and easy to implement. But it feels incorrect; for one thing, it tightly couples all of this data in a way that makes me think will cause headaches down the road. I'm not used to web programming, though, so I have trouble trusting my instincts in this case. Another issue I can see with this option is that if I wanted to refetch only one part--say, I wanted to refresh the task list--I would have to refetch all the data, which doesn't seem useful
2. Make DatasetTaskList and DatasetVersionList create their own resources based off the dataset_informationresource. These resources would take the ID from the Dataset and use it to call the appropriate GET request for Tasks and Versions. This is the way that makes sense to me, but was having trouble understanding what the parameter/properties to DatasetTaskList and DatasetVersionList should be--is it a Resource<(), Dataset>? Or should I have a Signal<DatasetId> and use Signal::derive on dataset_information? I was also thrown off by a comment in this issue: Dependent resources #843 (comment)

It's semi-intentionally difficult for a resource to depend on another resource, as this kind of async-request waterfall is usually a bad idea. I'm assuming you're doing something on the server like reading this data from a database... In which case, why doesn't search_items just take the category slug as an argument instead of the ID? It's usuall better to do two reads from the database (to look up category info, then to look up items) on the server in a single request than to do it in two separate requests. But maybe I'm missing some context.

That sort of indicates to me that this approach is wrong for web development, which again I'm not used to. But I couldn't tell if that comment was meant for SSR pages, or for resources in general.

3. Some sort of nested resource situation. In this option, instead of passing Resources to each component, I would instead react to the output of that resource, and pass in the Dataset to each component. The DatasetInfo component would just render the view with the relevant information, but the DatasetTaskList and DatasetVersionList would make the appropriate GET request based on that Dataset passed into it (probably using a Resource?). So it would look something like this:

let dataset_information: Resource<(), Dataset> = create_resource(|| (), |_| async move { retrieve_dataset_info().await })

view! {
  <div>
    {
      move || {
        let dataset=dataset_information.get().unwrap();
        view ! {
          <DatasetInfo dataset>
          <DatasetTaskList dataset>
          <DatasetVersionList dataset>
        }
      }
    }
    </div>
}

(I haven't really worked this one out yet so I'm not sure that that code is correct)

Basically, I'm just looking for advice. Should I try to fetch all my data at once? Should I create resources that fire when other resources update? Or should reacting to my resources create new resources?

(As a side question, is it better for components to have parameters of aResource, Signal`, or something else?)

Thanks

Footnotes

1. I've intentionally not written any <Suspense> bits for the moment while I try to figure out this first problem ↩

[gbj]

Datasets have a list of Tasks associated with them, and also a list of Versions associated with them. However, getting the list of Tasks or Versions each require a separate GET request.

Does the Dataset need to load before the Task and Version can be fetched, or can all three run at the same time? From your description of 2 and 3, it sounds like the Task and Version requests need to have a Dataset in hand before their requests can be made.

If Dataset needs to be loaded first, this is bad. Here's the chain of events

• client makes request to server
• server sends back HTML
• client fetches JS and WASM
• server sends back JS and WASM
• client sees it needs to make a GET request for Dataset
• server sends back Dataset
• client sees it needs to make GET requests for Tasks and Versions
• server sends back Tasks and Versions

After 4 full round trips to the server and back, you're finally ready to render the page.

If it's at all possible, you should try to join the three separate GET requests for data into a single request that can return all the data that is needed on a particular page. This will have a much larger performance impact than anything else.

1. Make `retrieve_dataset_info` fetch all information relevant to all 3 components, i.e. `retrieve_dataset_info` will do 3 separate GET requests and bundle up all the data from each into a new type that can be passed to each component, and those components just pick and choose which data is relevant to them. This is fairly straightfoward and easy to implement. 

This is the best approach. The 3 GET requests will run concurrently. If you can structure your API so that they are 1 GET request, that's much better, but at least this way avoids the waterfall.

If I am misunderstanding and the 3 requests can be run independently, without Task and Version depending on the received Dataset, then creating 3 separate resources is also plausible.

The ideal situation would be one in which any of the three fields could be fetched separately, with only (for example) a dataset ID, rather than the full dataset, which would allow you to create three resources that can reload independently to refresh separate pieces of the data, but can all run concurrently.

Part of the reason that resource waterfalls are a pain to implement is that resource waterfalls are bad.

[Swandog]

Hrm...I hadn't thought it through but I suppose I could construct the Task and Version GETs without having the results of the first GET. Those components will want some of the information from the result of the Dataset GET but strictly speaking they don't need those results to make their GET requests.

At this time I'm not at liberty to change the backend API so there will have to be 3 requests for now. I'm not overly concerned with performance at this stage (this is more exploratory than production). But I take your point that the "waterfall" style is bad and should be avoided/removed.

2 things I'm still not clear on:

1. You said this

After 4 full round trips to the server and back, you're finally ready to render the page.
If I put in the proper Suspense elements, the page would start rendering before that, right? I could render the main infobox for the Dataset while the Tasks and Versions are still loading?

2. Is it right to derive Signals from Resources? Or is it better to keep them as a Resource when you pass them into components, etc

Thanks for your help!

[gbj]

You're absolutely right about Suspense -- with the waterfall, you could have nested spinners

• Show the shell with a spinner for Dataset
  • Show the shell and Dataset with a spinner for the Tasks/Versions
    • Show the whole page

Running the three requests concurrently lets compress that into a single spinner for loading all the data, which will be loaded faster, so probably a better UX but of course it's up to you!

Re: deriving Signal from Resource -- yes, should be fine, just remember that it's a lossy conversion in the sense that you lose access to things like Resource::refetch() if what you have is a Signal not a Resource. In general I'd only convert them to Signal if you're either actually doing some derived-signal transformation (like mapping some other function over the resource's result) or if you need to create a component that also accepts other kinds of signals.

[Swandog]

Thanks for the help!