Something which is really useful for a routing system is something like https://guides.emberjs.com/release/routing/loading-and-error-substates/ which depending on the pessimistic mutation output will load an error / loading substate

@U6Y72LQ4A I was thinking that that’s already covered by the loading story itself, and is an orthogonal concern. The only “real” work to do in providing feedback in loading in Fulcro in general is to write the UI…something you cannot really get around in any non-trivial app. So, if you could point to a particular way in which “providing” feedback would be generally usable beyond what Fulcro does, then I’m happy to hear it. These docs tie the routing up with the specific method of loading that has to do with models (ORM I assume). In Fulcro you might have to run a pessimistic mutation, load some data, etc. Those tools already give you the ability to update app state as they proceed (which is identical to changing UI in a pure rendering system)….so what can/should the router add? Ah, so perhaps there needs to be some “intermediate” UI that shows for loading (which you define elsewhere)?

So, how about:

(defrouter MyRouter  Settings User
  (dom/div "Loading..."))

the syntax could then probably use some work, but that’s not a bad idea. Convenient place to put the UI to show when a route is deferred. It would probably be useful for that code to also know: 1. Which route is being left 2. Which is going to be shown and it might be useful to also be able to configure a “timeout” for what constitutes a delay to prevent flickering.

Refining that a bit (including an extra timeout for giving up on a really slow route):

(defrouter MyRouter
  {:routes #{Settings User}
   :error-ui (fn [some-info-about-issue] (dom/div "Error loading this page"))
   :deferred-ui (fn [from-ident to-ident] (dom/div "Loading..."))
   :deferred-timeout 50 ; time before showing loading
   :error-timeout 5000}) ; time after which a deferred route that isn't ready should change to an error 

This looks like a job for (sound of trumpet) UI State Machines!!! 😛

Ah, and this will also make the “initial state” case consistent, since I can start the router state machines on mount, and let them trigger initial setup, meaning I can lift the restriction that routers have an initial view for startup that does not require loading….sweet

Done. The latest tip of that branch has timeouts for doing flicker-free load UI, error UI, and custom timeouts. The routers now use state machines internally.

This looks absolutely amazing! We will definitely try this out soon

Great talk Wilker, when you lay it all out it is insane how much leverage you get by using Fulcro and Pathom. And how nice the development tools are.

thanks man 🙂

@U066U8JQJ Like wow... was 90% set on graphql backend, now think eql & pathom are the right call... You're presentation topped the REBL & rich's talks for me. Re-watching it again now 🙂