Clojurians Log v2

Tying I/O to UI is one of the things Fulcro is trying to help you divide out. As soon as you start tying application lifecycle to UI lifecycle all sorts of badness occurs (over time). This is why I made UI state machines, and then statecharts. Having a better abstraction of larger lifecycles within your app that are NOT tied to UI behavior is very helpful. These days I’m using statecharts for kind of everything that isn’t trivial logic in my new code.

nothing I can think of would be a problem on the Fulcro end, and Fulcro and Pathom both follow the EQL standard (we defined it)…so no, I don’t expect this is a problem with either library.

Can confirm that Fulcro and Pathom3 plays well together, including df/load!

what am i doing wrong? After watching Fulcro – Part 6 : Full Stack Part One, my expectation is that if i use load! like so:

(defonce APP (-> (app/fulcro-app 
                  {:remotes 
                   {:remote (http/fulcro-http-remote {})
                    :client-did-mount (fn [app]
                                      (df/load! app :all-products toto.ui.root/Product
                                                {:target [:component/id :toto.ui.root/ProductList :product-list/products]}))}})
                 with-react18))

and it's strange when the eql queries work in fulcro inspect as expected. Also both, manually pass some products to initial state or using merge, work fine

I put the df/load! in the init function instead(after mount), as per documentation and it worked. No i wonder why in part 6 video, it's mentioned as not a good idea to place in init since it's called every time the client remounts 🤔

(defn ^:export init
  []
  (reset! SPA APP)
  (app/mount! APP Root "app")
  (df/load! APP :all-products toto.ui.root/Product
            {:target [:component/id :toto.ui.root/ProductList :product-list/products]})
  (ido
    (it/add-fulcro-inspect! APP))
  (js/console.log "Loaded"))

I do want to add a timer for the MCP ping, and need to delay events as well. Would an Invocation processor that reads from stdin on a timer work instead of blocking the main thread? It would block but in a go-loop so could be parked?

invocations are about statecharts starting other things/services/charts…so no, that’s not what I’d use

What you want is a thread that processes an event queue (possibly the core async one I provide). The main loop would be the I/O, and it would turn the data into events. The statechart, in turn, could trigger outputs if you needed.

the point is to NOT think of the statechart as “running” in the sense of blocking/consuming CPU. The statechart runs on events…period

That's how I have it now with the (while true (read-line)) That main thread blocking loop just read-lines and spits it into an event.

ok, sounds right…so what is the question?

I mean, it sounds like starting a new thread that does the event processing in a loop is the way to go

I wanted to see if it's possible to move the poll of stdin to a series of states, instead of just blocking the main thread with a stdin->event handler.

I think if I background the stdin loop it won't work in babashka, I would still need to block the main loop for babashka.

I'm sure I'm over thinking it, it's working with the simple block on the main thread. Thank you.

I am actually doing it just a bit different, I create a let outside the while loop to create the bufferedreader for *in* I just shortened it for the example above.

isn’t that just (read-line) in clj? 😄

BUT, blocking the statechart logic this way is very bad idea (i.e. putting it IN a statechart)

Babashka does not wait on background threads so blocking -main this way is actually the only way I have been able to make it work in clojure and babashka both.

read the manual….statecharts are pure-state -> event -> new pure state. If you block in the event handling, you’re blocking the entire chart

I block -main at the end, after the statechart is running on a background thread.

https://github.com/fulcrologic/statecharts/blob/main/src/examples/traffic_light.cljc See the bottom of that file. You want to write a loop that reads input, turns that into an event, and does a “swap!” on an atom holding the statechart

then you don’t need threads at all

well, unless you use delayed events…then you would

is babashka graal, or sci?

I don’t remember

I think it's both? I see a lot of sci. namespaces in exceptions, and it's for sure compiled to a single graal binary.

right, so (.wait obj) won’t work?

(to block a thread)

but if you’re really just wanting to treat the lines of stdin as event data, and you don’t have deferred events, then don’t make a thread, process it more like the example I showed you

Thank you for the pointers I will keep playing with this. It's for an MCP server that does json-rpc on stdin/stdout.