2nd load???

you cannot trigger loads from post mutations

it is action-only, so remotes aren’t processed

@roklenarcic

If you need more than one load, you need to trigger it from the UI or from the first-class mutation. post mutations are about morphing data that you received, never about chaining actions

Think about the chaining case: why do you want to do that? Well, the assumption would be “I need to see what I got back”. No. The server knows what you want to know already. Do the logic there

and if the server doesn’t have all the info it needs, pass what it needs to know in the initial remote interaction as params

This is part of the reason I’m hesitant to make anything but state available in post mutations (ident and query are ok). The model is designed to keep you away from async behavior as much as possible. If you start chaining things you’re back in callback hell. .

yeah well, that was kinda the idea. I load something, then I see if I need to load more (loading a chain of parents). I cannot do things on the server as I'm using a REST API on a backend that isn't mine. I can however change my network implementation for this call, which is what I'm going to do.

defsc looks wonderful! 😄

@roklenarcic Ah yes…legacy REST. Not the central target market of fulcro 😉

what should be the policy for erroring out when I issue two df/load loads which results in a single network invocation with a combined query for both things, and only one of them fails, but the other one loads successfully? I'm assuming ok/error callbacks expect only one of them to be called and only once?

You’re writing your own networking, right?

technically everything is just merge. There are some extra bits stacked on, but ultimately you’re just trying to get the correct thing in the app state so the UI shows the right thing

the error callback has the plug-ins for fallbacks. Both ok/error have logic for the refresh.

But, if you have access to the app (which you can give to your networking layer in started-callback), you can do whatever you need to do. The networking layer is kind of exempt from most rules, because you’re in the guts where async crap has to happen.

Or, you could look at FileUPloadNetwork from forms.

it implements the updating form of networking, where there is an ok and update and an error. You could just choose to treat an update with error state followed by an ok or error as your way to report errors like that.

For your case, I’d probably use the updating network support that you can find an example of in the file upload networking (fulcro.ui.file-upload).

I'll look at the sources, thanks