If I have multiple server side fetches I perfrom to do to populate a form (different resources for different parts of the form), would I just do several df/loads? Or is there a different way?

(df/load this [:person/by-id person-id] etc..)
(df/load this [:animal/by-id animal-id] etc..)

@njj ideally you wont need, query composition is made so you can group the same query, but if still you need, just call multiple loads, by default it will serialize then (so the second one will only happen after the first finishes), if you want to run in parallel there is a flag, I just dont remember its name

@wilkerlucio Thanks, can you give me an example of what that looks like?

@njj its some option you send to df/load, check the docs and you probably will see it

did a quick look here, its :parallel true 😛

heh

and I can just pass [:person/by-id person-id :animal/by-id animal-id]

no, you do multiple df/load calls

like your example

cool

I was on track then 🙂

Thanks @wilkerlucio

you'r welcome 👍

@wilkerlucio Is there anything for async? Like if I wanted to wait for person/by-id to come back, use a value from that for looking up animal/by-id

Just a thought..

I guess I could remove the parallel, store the value in the state and then reference it

that feels pushing too hard on the client load, the design goals is to delegate all of that to the server, coordinating loads in the client is a bad pattern

you could make your query in some way that it loads everything at one, that is a better way to see it, but requires design thinking around your problem

so I could modify my server side fetch to be both, return each entity and then store it that way (or something similar)

what is your case, why are you having to do those separated?

yeah, as long as they are linked with the correct components, you can pull as many things as you want

its ok to create a new fulcro class just to compose the queries (and display nothing)

in my case: resource “a” has a value in its response that tells me the id of resource “b”

if that makes sense?

yeah, that seems like b should be a relation from a, correct?

[:a/id {:b [:b/id]}]

I suppose

its like child and parent, I guess - so a {:parentId 123}, then look up parent by that

yeah, if you chain your data like that it will make things easier

if for some reason you need that separated, you can use a post-mutation to adjust the data, after normalization this tends to be a simple thing

right

I think I’m going to try to just have the server handle fetching both things on one df/load, then have the client add each to their prospective places in the state

yeah, because this kind of coordination tends to get more and more complex over time, if you get the practice to keep then in a single query you can delegate this complexity to the server and keep your client clean and simple regarding fetching

I guess the tricky part is separating them on the client if its one df/load, so lets say the response comes back {:person {} :animal {}}, then on the client I’d have to find a way to store person/by-id and animal/by-id

post mutations I suppose 🙂

@njj what you just describe seems like union queries, to get polymorphism on the query, had you looked into it?

it comes down how you think about your data and its relationships, graph apis in general will assume the entire data you wanna load is connected somehow, so you can describe it in a single batch

I haven’t looked into that yet

@njj eql docs on unions: https://github.com/edn-query-language/eql#unions fulcro docs on unions: http://book.fulcrologic.com/#Unions

not sure if that will work because I need resource a to respond before I can look up resource b

interesting, what makes you require that?

just the way the UI is laid out, looking up by one resource and then fetching another based on that response