Fork me on GitHub
#fulcro
<
2019-05-10
>
exit218:05:19

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?

exit218:05:22

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

wilkerlucio19:05:16

@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

exit219:05:52

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

wilkerlucio19:05:37

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

wilkerlucio19:05:18

did a quick look here, its :parallel true ๐Ÿ˜›

exit219:05:48

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

wilkerlucio19:05:06

no, you do multiple df/load calls

wilkerlucio19:05:12

like your example

exit219:05:19

I was on track then ๐Ÿ™‚

wilkerlucio19:05:27

you'r welcome ๐Ÿ‘

exit219:05:56

@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

exit219:05:58

Just a thought..

exit219:05:20

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

wilkerlucio19:05:58

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

wilkerlucio19:05:43

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

exit219:05:49

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

wilkerlucio19:05:51

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

wilkerlucio19:05:10

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

wilkerlucio19:05:22

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

exit219:05:30

in my case: resource โ€œaโ€ has a value in its response that tells me the id of resource โ€œbโ€

exit219:05:47

if that makes sense?

wilkerlucio19:05:57

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

wilkerlucio19:05:07

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

exit219:05:29

I suppose

exit219:05:13

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

wilkerlucio19:05:36

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

wilkerlucio19:05:02

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

exit219:05:23

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

wilkerlucio19:05:29

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

exit219:05:17

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

exit219:05:42

post mutations I suppose ๐Ÿ™‚

wilkerlucio19:05:17

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

wilkerlucio19:05:10

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

exit219:05:47

I havenโ€™t looked into that yet

exit220:05:23

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

wilkerlucio20:05:00

interesting, what makes you require that?

exit220:05:31

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