A question about general re-frame rather than an issue

[bpicolo]

So I've had trouble finding a way to do the following, and it looks like the coeffects strategy in this package might be along the right lines, so hoping someone will take a look at this and give me some advice.

Say I hit a new page (in the SPA) that has some ACLs, so only certain users can see the page.

I dispatch some [:load-acls user].
After the acls come back, if the user doesn't have said permissions, I want to redirect the user away.

This is the thing I've had trouble finding the appropriate pattern for (as well as other similar cases where there's a data dependency). But there may be times I want to load those same ACLs and then not redirect a user.

Would it be sane to pass a coeffect to the load-acls, e.g.

(re-frame/dispatch [:load-acls user 
                                 :coeffects blah])

That's not quite the whole store, as a data load may be asynchronous, but that's roughly my thought at the moment.

Is that sort of where I want this in the stack? Would there be a better place? Potentially-dispatching in the pure render function seems like a big no-no, but it's currently the only place I actually have view-specific code outside of callbacks.

I've mostly had to rely on callbacks for this sort of behavior, which seems suboptimal. (that is, :load-acls has an optional callback for after data is loaded)

What's an appropriate/good/clean pattern to do these sorts of dependent-asynchronous-loads?

[danielcompton]

Hey, the general way we would model this is with several events. So one way you could do this is:

1. Load new page (via a dispatch). That will change some state in your app (say switch the current view and display a loading dialog). It will also emit an effect [:load-acls user] which is an HTTP request.
2. The event finishes
3. Your view updates with the loading dialog
4. Your HTTP request comes back, and in the on-success/on-error callbacks, dispatches [:acls-loaded {...}]
5. In your :acls-loaded event handler you can then make the decision about whether this user is authorised or not. If authorised you do one thing, if not authorised, you dispatch a [:change-panel :dashboard] event.

Hope that helps? You might also want to look at https://github.com/Day8/re-frame-async-flow-fx. Both that library and this one are mostly higher level patterns on top of re-frame primitives. I'd probably recommend starting off trying the pattern I suggested above. If that gets too unwieldy or you end up with too much duplicated code then you could look at those libraries to clean up some of the code.

You might also get different opinions from others on the #re-frame Clojure Slack channel, the ClojureScript mailing list, or the Reagent mailing list.

[bpicolo]

@danielcompton Hi daniel, thanks for the response! (I have tried clojure slack but didn't have success there with this particular issue :)

So I think the one missing part is where I mentioned that [:load-acls] may or may not need to do this effect after the fact. Does passing a custom callback handler like [:load-acls :success-callback #(foo)] seem like a reasonable pattern?

[danielcompton]

So I think the one missing part is where I mentioned that [:load-acls] may or may not need to do this effect after the fact.

Sorry, I don't quite understand. Can you explain further?

Does passing a custom callback handler like [:load-acls :success-callback #(foo)] seem like a reasonable pattern?

I would try to do as little work and decision making outside of handlers. You can look at sending your HTTP request as an event, and modelling the response as another event. Your event comes back and in the response handler you decide what to do about it (maybe nothing).

[bpicolo]

@danielcompton It's not the case that every time I run [:load-acls] I want this event to execute, is what I mean there. Some pages may just want to load acls and not consider redirection at all.