Fork me on GitHub

I just released a statecharts library that I purposely aimed at full-stack operation, but with some fun Fulcro things in mind: . I kind of wanted to do that back when I did UISM, but UISM was quicker to write than a full SC implementation, and the coupling into Fulcro as sort of a mega-mutation felt right at the time (and I'm still happy with it, for what it is...I use it a ton). If you're needing more complex behavior with good structure in your app (front or back end), then the new stuff might be worth a look. I plan on collaborating with whoever is interested on ideas for putting this to good use over time. I'm hoping there's some nice synergies. For example, the "invoke" idea from SCXML allows you to invoke an external "thing" that is auto-cancelled as you exit the state. So, imagine adding a executable element (it's extensible) withing a "loading" state that represents a Fulcro load on a report. If you navigate away and the state machine leaves the surrouding "loading" state, then the invoke is auto-cancelled (clearing the network queue).

(state {:id loading-report-data}
  (invoke {:type :fulcro/load ...}))

❤️ 3
🔥 5
👀 4

This looks very interesting, I wasn't aware of SCXML at all. Down the rabbit hole we go! 🙂


Yeah, I chose that standard because it was either that or read Harel's papers and all of the literature since the late 80's...I figured if they worked out a good standard over a number of years (the early drafts of SCXML were much earlier that 2015) then they'd probably considered and simplified things greatly. I actually am pretty happy with the standard now that I've implemented most of it. It's really well thought-out. I still need to finish understanding how I'm going to do "invocations" and some kind of "system management" abstraction...I want to have something where machines can spring into existence, live over a very long time (e.g. in server databases), wake/sleep, etc. The standard gives you everything you need to implement that, it turns out. Not sure what of that I'll add to the top-level lib, but I'm excited about all the possibilities.


Some other interesting “prior art” of workflow state management and execution systems: “wake/sleep” of machines reminds of the virtual actor concept, as implemented in and invented in – I think a common pattern is to execute the state machine within the virtual actor system, which manages the compute resources and sometimes even the persistence. Another production workflow system with sleep/wake is – that’s a commercial fork of

Thomas Moerman20:12:04

This looks very interesting. I am currently looking at Camunda BPM or Zeebe as part of the back-end of my Fulcro app. The idea is to have an engine that orchestrates long-running workflows with Tasks for both humans and other microservices. Camunda and Zeebe use the BPM standard as the DSL to specify workflows. I found the book ";crid=3M1J3T0YPB9C4&amp;cv_ct_cx=practical+process+automation&amp;keywords=practical+process+automation&amp;pd_rd_i=149206145X&amp;pd_rd_r=ee45a740-5453-4f2d-96c6-b94c44d8e15a&amp;pd_rd_w=Cnepk&amp;pd_rd_wg=7A6pb&amp;pf_rd_p=b6d0be91-09b0-4a6b-9472-c11ec7a0fdf4&amp;pf_rd_r=61MTMKAZCDNCS20PR3MK&amp;psc=1&amp;qid=1639686686&amp;sprefix=practical+process+%2Caps%2C179&amp;sr=1-1-1890b328-3a40-4864-baa0-a8eddba1bf6a" quite useful to understand where such an engine fits in an overall architecture. Also, the talks by the author are worth watching. I'm not familiar with statecharts, will try to read up on that to be able to join the conversation.

Thomas Moerman20:12:10

In the same vein but way simpler: Lacks a "transition algorithm". I briefly tried to wing it and roll an implementation myself, but I quickly realized that doing this correctly is waaaaaaay hairier than I have time for. Workflow engines are a deep subject. Very excited to follow this track in the Fulcro ecosystem!


I've had about as much luck with BPM systems as with ORMs 😄 The idea that you're ever going to hand your business person a diagraming tool and have them actually use it are pretty rare, and them getting it actually right really requires an analyst, but small companies can't afford that, so devs end up just doing it, and devs prefer to just write code. The pretty picture aspect is nice, but easy enough to generate with modern tools (would be trivial to output PlantUML, for example, and have it just generate an image). Then there's the infra question, and BPM could be a win there, but with cloud stuff letting you spin up Kafka for $100/mo to get durable queues combined with Clojure, it doesn't feel very compelling to use a BPMS. If you're "big enough" I guess it works.

Thomas Moerman21:12:30

That was my first reaction as well 😅. However, Camunda caught my attention because they explicitly position the BPM definitions as software artifacts written by developers, not business people. This in contrast to the heavyweight BPM solutions of the past, positioned as "no-code" products. The embedded Camunda bpm, which persists to SQL, is quite lightweight. Zeebe is the cloud-native extrapolation of that, implemented as a Kafka-like event-sourcing system with the BPM engine on top of it. In any case, I think it's worthwile to have a look at as there is probably quite some conceptual overlap.


Cool, yeah, thanks for the tips.

👍 1

I needed it for something much more aggressive and interesting on the "back end" right now, but I'm seeing fun Fulcro things for it in the future


If I want to use lein is there an up to date template anyone recommends?


Not that I'm aware of.


though you could use the lein tools deps integration plugin, and use deps for the deps, and lein for whatever it is you think you need from it.

Jakub Holý (HolyJak)09:12:25

You just need to copy deps way of specifying dependencies into the way that lein does it, no? There is no special magic. You would need to switch shadow-cljs from using deps to lein, which it does support. None of that should be a big deal IMO?

Michael W14:12:48

com.datomic/datomic-free I think is the dep

👆 1
Michael W14:12:33

com.datomic/dev-local also may provide datomic.api


I want to run an application that uses datomic.api and datomic.function using the dev-local library.

Michael W14:12:51

If you get it working let me know because I tried to get it working under graalvm but am not good enough with java or clojure to figure it out. I ended up using xtdb instead of datomic.


The app is not mine but @U6VPZS1EK’s - we shall discuss


the dev-local library is for cloud


which is not that ns


I have installed dev-local


This does work:

user=> (require '[datomic.client.api :as api])


Is there a way to use RAD attribute definitions as the basis for specs/guardrails? Given an attribute definition like:

    [com.fulcrologic.rad.attributes :refer [defattr]]
    [com.fulcrologic.rad.attributes-options :as ao]

(defattr bar ::bar :int
Is it possible to use as a spec that conforms to the :int type?


It is possible, but I have not had the time to write it. Spec uses a lot of macros, so the trick would be to write a version of defattr as a macro that would emit the spec at the same time as the def.


That would be a compile-time transform....malli would be easier. I've spent some time making GR actually be protocol-based so you could use any spec'ing system (Malli or spec or spec2), but I just have not had the time to finish that either. Too many balls 🙂 Another way you could do it is just put the spec under a special key of the attribute, and write a post-processor that installs those into the spec registry...that would actually be easier I think?


not sure that any of that makes sense, probably want more of a real spec, like (s/int-in 0 100), and just putting that in an s/def just below the attribute makes pretty good sense. Spec already uses a global registry, so you are not winning anything by putting it IN the defattr


Yeah, you're right, as it stands there's not much gained by putting the global registry definition inside the attribute definition, but it would be pretty cool if we could just use the attribute keywords throughout the application to do things like GR validation and other operations... things like (s/coll-of ::foo/bar ...). I thought maybe since the attribute type is already registered somewhere, it could be used without additional code. Just musing here, but maybe a registered RAD attribute could have a spec definition - an extension to the base attr. type - in its body which would associate the attribute key with the spec... that would allow this sorta thing.. I think...


So, you can add a predicate to the attribute with ao/valid? , so IMO that would be the thing you could use to emit the spec, instead of the type...I mean, I guess you could use the type as a default.


Any pointers for what to look at when I’ve added com.fulcrologic.fulcro.inspect.dom-picker-preload to my :preloads , and the Element tab tells me to do just that? I’m on current versions of everything (or at least I was a few days ago). I’m pretty sure this was working when I did @holyjak’s re-clojure Fulcro workshop a couple of weeks back, but it’s not working now (in the same project).


I have the same behaviour with both Chrome and Vivaldi.

Jakub Holý (HolyJak)18:12:17

Notice that it shows the > Note > The element picker requires a UI plugin ... message even if you have it enabled - but the "Pick Element" is there and works. Is that your case?


Ah, I hadn’t realised the message always appears. It is indeed working. Thanks again for your help.


But… In the MVC app (your workshop thing), I get feedback when hovering over components. In my other app (where I’m working through the Fulcro video series), I don’t get any feedback on hover, but if I click on a component the inspector shows the component’s details.


Maybe I’ll copy over some of the code from the MVC app to the other app to see whether I get hover feedback.

Jakub Holý (HolyJak)18:12:15

Could be some CSS styles getting in the way


If the tooltips are invisible, do you know what I should do to make them visible? (I’ve been trying to work out how to get two Chrome inspector things up at the same time — one for (ordinary HTML) elements and one for Fulcro Inspect — but I can’t see how to do that.)


I’ve removed all the CSS from my project, but still no hover feedback.



Uncaught ReferenceError: ReactDOM is not defined
    at over_handler (element_picker.cljc:97)
over_handler @ element_picker.cljc:97


Hah! This is fun… • I’ve created a copy of the com.fulcrologic.fulcro.inspect.element-picker namespace in my repo so that I can play with it. • I’ve looked at recent commits in the Fulcro repo. • I found • That commit gets rid of the use of ReactDOM


And the fun bit… The author of that commit is holyjak, and (I assume), that is you (@holyjak)!


I guess I can refer to that specific commit in my deps.edn. (Looking up how to do this…)


Forgot to say, applying that commit to my local copy fixes things.


I’ve upgraded to

com.fulcrologic/fulcro {:git/url ""
                        :sha "cd755fd426aa7773de9ee23c1b9344430dcb6b12"}
and it works.


I was using Fulcro 3.5.9-RC1. Downgrading to 3.5.8 also fixes things.

Jakub Holý (HolyJak)08:12:12

@U0CKQ19AQ perhaps it would be nice to make a new 3.5.9-RC2 release with the element picker react dom removal?


I didn't follow. Is a PR needed?


Hi @U0CKQ19AQ No, no PR is needed. A bug was introduced in 3.5.9-RC1 — there’s no hover feedback from the Element Picker. It’s fixed in the develop branch by


ah....ok, I can cut a release


3.5.9 released

🙏 1

👍 I confirm that 3.5.9 fixes the bug.