Clojurians Log v2

GC of that sort is really up to you. Browsers have lots of RAM, and in my experience many apps don’t really fill it up that much during real operation. So, I don’t GC much unless I specifically know the stuff is getting out of hand in real use (e.g. the user stays logged in for days and very actively uses the app that whole time). Many apps are used in a more transient fashion, and you won’t actually gather up that much cruft.

I’m starting a new Playlist on YouTube titles “Grokking Fulcro”. This is a dual-purpose video series: • Help existing Fulcro users understand the low-level details. • Show common patterns. Fulcro does things differently than people expect, so knowing how to “think” about common problems requires some shifts that people often struggle with. • Expose people less familiar with Clojure(script) to some of the superpowers you gain by using it. First video just dropped. Here’s the playlist: https://www.youtube.com/watch?v=3dZK5seIaVI&list=PLVi9lDx-4C_TBRiHfjnjXaK2J3BIUDPnf&index=1&ab_channel=TonyKay

Are there any concrete examples of websocket push-handlers around? I’m leaning towards figuring out a way that the data provided by a push is in the same shape as a mutation with targeted return values (https://book.fulcrologic.com/#ReturnValues). Does this seem reasonable? I’d like to see what others have come up with.

That is exactly the plan you should have.

That’s reassuring!

In developing your push messages, include an indicator of what component (name in the UI component registry key?) should be used for merge. Then it’s just merge-component!.

creating edges (targeting) is also something you’ll need to decide on…perhaps generalizing that to something in a UISM actor model?

then your messages could be much more generic and not tied to the UI, and the actors in the UISM could provide what you need.

https://cljdoc.org/d/com.fulcrologic/fulcro/3.1.20/api/com.fulcrologic.fulcro.ui-state-machines ?

there’s, of course, some coupling of knowing what to push from the server and having that macth UI expectations.

yeah, that’s UISM

see book chapter

Yeah, I’ve been trying to suss out what the minimal coupling would be.

I think UISM is a good match, actually. There’s probably not many “states” to it, but the generalizations UISM allows for hooking in “actors” is handy.

I’ve been leaning more and more towards thinking that state machines are the end state of decoupling.

I’ve read you mention elsewhere that you have a couple of production systems out there using websockets. I can understand not being able to share that code. Do you happen to know of some examples that are available to look at?