Clojurians Log v2

The element picker in fulcro-inspect is a real blessing!

Fulcro 3.4.2-SNAPSHOT is on clojars (git SHA 3edf1aab7e6578bf59fc5d0018df3682f78834a5) with a few patches to dynamic routing: 1. Nested routers that can act as disconnected subtrees should now work correctly. Of course mapping the resulting multi-headed monster to an HTML route is left as an exercise (in futility?) for the reader. Basically, a relative route change will no longer ask parent routers if that is allowed (route changes up till now could have been denied by a parent). This allows you to use dyn routers in a dashboard-like setting where screen-local routing is relative to a feature, and is not necessarily understood (or routed to) by the parent. For such scenarios to work properly you will have to add logic that routes a given nested system on the very first entry. 2. Changed the implementation of change-route so that it sends routing instructions depth first (instead of top down). This should prevent flicker on route changes that have no I/O.

Sorry if I missed this in the documentation, but how do I tell a component (i.e. in a defsc definition) to use a different remote than the default for its query? I have several remotes defined, and I can see them in inspect, but sorry I don't know how to use them in a component query (not a mutation) instead of the default. Thanks

Hi, @tvaughan I have only one remote so I answer by guessing. The component queries the local database. You trigger df/load to load data from a remote. The manual mentions in chapter 10.2.5 that you can pass a :remote to df/load.

I trigger my loads on app load or on routing.

Or sometimes on button pressed 😉

On some components I do call load! in a deferred route using the will-enter lifecycle method. I can do that, but my assumption is that I should also be able to do something like:

(defsc Session [this {:keys [:session/id] :as props}]
  {:query [:session/id]
   :initial-state {:session/id nil}
   :ident (fn [] [::session :id])
   :remote-name :sessions}
  (dom/div))

Remember Fulcro is pluggable and you can add your custom keys to a component just as you show. And as @magra says, you query the local state so there is no remote during query. But you somehow, somewhere must be loading the initial data. There you can specify the remote, or walk the root query and split it into multiple loads based on your custom remote annotations.

Does usim/begin! trigger a remote query?

Thanks for the help @magra and @holyjak. I'll keep digging

I don't know. It certainly can but I would be shocked if it did so by default. Depends on the actions of the UISM I guess

This is the docs on the initial data load http://book.fulcrologic.com/#_loading_something_into_the_db_root

Thanks. This appears to work:

(uism/load :session/session-id :actor/has-session {::uism/ok-event :event/ok
                                                              ::uism/error-event :event/error
                                                              :remote :sessions})

Since the query will trigger a load! either automagically in RAD or in your own code, I think you can just put a {:remote "some-remote"} on your component. But I may be wrong. However, you're probably looking for this: http://book.fulcrologic.com/#LoadOptions

I need to look at the source again to see if RAD actually passes that :remote keyword through to the load

Oh, I see you found the answer a thread below. Just ignore this then 🙃

I’ve just updated the chapter on dyn routing in the book to include some commentary on things that I think confuse people, and also added some details about using nested routers where you might want to show more than one at a time on the screen. See these sections in particular: http://book.fulcrologic.com/#_partial_routes http://book.fulcrologic.com/#_simultaneous_on_screen_routers

All loads name the remote of interest, as you’ve discovered. UISM is just about state machines. It does nothing in I/O without you telling it to. RAD is simply an expansion. At the moment RAD is only capable of using a single remote. The eventual intention is for attributes to declare their location in your data topology and have both client-side and server-side logic that can resolve things. A given report, for example, could technically combine attributes that require hitting multiple remotes on the client side, and multiple different databases on the server side. I have not had time to write this multiplexing into RAD, but it is part of the design and intention to eventually do all of that, and for it to be as seamless as possible. A federated data model like that is RAD’s holy grail, and is actually quite tractable…just have not had the time.

@tvaughan @holyjak