Fork me on GitHub

Hello Fulcro lovers. I have a strange behaviour that i don’t understand. This is a minimal example of a router ( When I reload the page on the /home the router begin by display No route selected and after the text Home of the component. In fact, current-state of the Router is always nil in this case and nil again when the router doesn’t know the route path. How can better control this?

Jakub Holý (HolyJak)09:01:27

Targets must have a query. I do not think [] is enough, change it to ['*] . See point 1. under Example 1 under

Jakub Holý (HolyJak)09:01:01

Also see the comment about :initial vs nil at point 2. under Example 4.

Jakub Holý (HolyJak)09:01:47

When you reload the page, the route starts as unrouted (= nil) before the change-route! kick is (which I assume your (history/dispatch-current!) calls). To deal with that you can tell the UI not to display until the state has settled down. Here I do that by using the flag :ui/ready? which I only set to true after my ui is ready (here after the data is loaded, in your case you could transact it right after you call dispatch-current) > and after the text `Home` of the component. In fact, `current-state` of the `Router` is always nil in this case Does it mean your routing does not work and the router is simply displaying the default = first target? Notice that when the state is :routed then the body of the router is not executed so you would not see the state printed. Thus it is to be expected that the only state you see printed is the initial nil (after which it presumably goes right into :routed and displaying Home) What does the DB contain? What does the Transactions tab show? Is everything there as you expect?


Thanks @U0522TWDA to answer me 🙂 > Does it mean your routing does not work and the router is simply displaying the default = first target? I think the router works because when I reload the page on /foo the router display correctly No route selected For the moment I have no DB and no transactions. I will check all your advices.

Jakub Holý (HolyJak)10:01:15

When I speak about DB and Transactions, I speak about the tabs of Fulcro Inspect

Jakub Holý (HolyJak)10:01:30

A possibly better alternative to using :ui/ready? is what is shown in in the second code block, checking the router's state for :initial or nil and displaying "loading..." instead

Jakub Holý (HolyJak)10:01:32

If you haven't, I would highly recommend going through to get familiar with Fulcro Inspect and troubleshooting fulcro apps


Thanks you very much @U0522TWDA I will take a look

🙏 1
Thomas Moerman18:01:20

Hi gang, I have a situation where a prop change of some component should trigger an async call and merge the result of that call (a js data object that doesn't belong in the fulcro DB, probably something to keep in an LRU like cache) with the props to a child component that does the rendering. I was thinking of using something along the lines of react-async-hook, is there perhaps another idiomatic Fulcro approach suitable for this?

Jakub Holý (HolyJak)19:01:24

Not as far as I know. Personally, I would prefer to keep the site effect outside of rendering, ie there where the change enters the system (eg an onChange handler or a load's post mutation). You could store the value eg in an atom and just change a flag in the the client DB (eg :ui/external-data-version) to trigger Re-rendering of the component that needs to read the atom

Thomas Moerman19:01:49

Thanks. I'll tinker with it some more


“where a prop change”…what causes the prop to change? That’s where the logic belongs IMO


I was trying to show a RAD form inside a modal (so not using a router). I used start-form! to start it and show it in modal. However I couldn’;t make it work without router involvement because UISM itself has references to routing that you cannot disable. in form.cljc:969 which has route-target-ready . is there some way around that?


I think you will find the master-detail example from the RAD demo repo helpful: The state machine is just a map, so you can disable anything you want by assoc'ing in a different handler function to any event you want handled differently. You could copy/paste the existing handler and remove the lines you don't like, if that's what you need. I don't know if there's a cleaner way to do it.


Another problem I sometimes face is when i navigate to a form of some entity, if the data is missing or wrong for any reason, then the initial state of the form is invalid. And the issue is that user is then unable to close/exit the form. Is there a remedy for that?


THis commonly happens when a user has a form open and the entity gets deleted in the mean-time. When the user hits refresh, form will try to load the entity, get nothing from remote and open an empty form. Due to required fields being invalid now, the user cannot navigate from this form and they are stuck.