Clojurians Log v2
fulcro
Uh, why do transitions match events as a prefix in general? So in documentation it is mentioned that instead of saying route-to.* you can just make a transition of route-to and I took that to mean that :route-to would match :route-to and :route-to.* but the pattern seems to be that a transition matches events by prefix in general? I had a sm that had :level1 and :level11 transitions and when I sent event :level11 it would match the :level1 transition. Tested it out and :xyz transition matches event :xyzmfgrere. I think this is pretty unexpected behavior.
I didn’t realize. That’s a bug. According to the spec they match on tokens (dot-separated segment) not substrings.
I mean try to double check,
Released fix in RC8
I am still getting hundreds of these messages in my console (the setup seems to be working otherwise). These happen even if when I reload the page with Fulcro Inspect tab open.
2026-03-29T19:03:44.371Z DEBUG [com.fulcrologic.devtools.common.connection:84] - Request to devtool timed out (no devtool open?) [(com.fulcrologic.fulcro.inspect.devtool-api/db-changed {:history/version 41, :history/based-on 40, :history/diff {:fulcro.inspect.lib.diff/updates {:com.fulcrologic.fulcro.application/active-remotes #{:remote}}, :fulcro.inspect.lib.diff/removals []}, :type com.fulcrologic.fulcro.inspect.devtool-api/db-changed, :com.fulcrologic.fulcro.application/id #uuid "53b5fec6-4169-4234-bde9-6a7bea96ce95", :com.fulcrologic.fulcro.application/label "53b5fec6-4169-4234-bde9-6a7bea96ce95"})]I have the tab open and working:
but for some reason the plugin icon next to address bar seems to think otherwise
Chrome ext 4.1.0,
com.fulcrologic/fulcro-inspect {:mvn/version "1.0.5"}odd…can’t say I’ve seen that
Here’s another thing I just noticed. istates block certain kind of sequences. So bear with me here. I’ve got this transition:
(transition {:event :auth/logged-in :target ::ui/Dashboard}
(script {:expr replay-bookmark!})).my-company.ui/OtherDashboard rstates. But if OtherDashboard is within an istate, the event seem to do nothing, it never changes the state of the istate chart to the desired state. It seems to have to do with late invocation start. I guess that when browser page is reloaded, and these bookmarking things happen, the istate chart is not started yet.Ah, so the event is sent too soon you think?
Let me check out a theory.
Ah, when I use scf/send! from repl it navigates. But that is logged as external-event, but the one I do is logged as internal-event
not sure if it matters
ok. invocations themselves ferry the pending child route through params. In terms of plain URL restore
and certainly the timing is going to be different between an internal (raise, runs on internal steps of the top-level invocation) and external (which runs from an external event queue that can’t possibly trigger until the current processing is done)
Per the spec, section 6.1 of w3c standard:
Since an invocation will be canceled when the state machine leaves the invoking state, it does not make sense to start an invocation in a state that will be exited immediately. Therefore the <invoke> element is executed upon entry into the state, but only after checking for eventless transitions and transitions driven by pending internal events. If any such enabled transition is found , it is taken and the state is exited immediately, without triggering the invocation. Thus invocations are triggered only when the state machine has reached a stable configuration, i.e., one that it will be staying in while it waits for external events.So, the internal events done with raise will not reach an invocation that is entered in the same step
Hm, but in my case the the thing that seems to be missing is the event triggering assignment to pending child route
hm ok
I’ll work around it
but the “external event queue” IS avaiable on the env, so you can submit it
if it’s on the external queue, it should work
or use scf/send!
or you can pass data to the invocation that it can read on start to “continue”… Is the “URL Routing” working through invocations for you? I haven’t had a lot of time to test this new ns, so it likely has some other rough edges
yeah if I drop all this interception of route to events I need to fix, then entering an url routes correctly I think
ok. So, you’re trying to intercept routing somehow?
Yeah I did the thing with saving a bookmark, but I commented that out for these tests
No this should work fine
thanks
I’m interested in your use-case…was it just a lack of understanding on your part, and all is well?
I basically copied routing_demo2 from statecharts
so the save bookmark etc… but I moved things around a bit and this thing where istate only gets initialized when SM settles tripped me up