> it’s just a convenient way to pass an expandable bag of crap through the bowels of the UISM code and handlers. sounds like a good sentence to add to the docs 😹

Yeah, my expressions are often a bit colorful…I once had a person on a dev team totally crack up when I was commenting on some imperative-styled code: “You’re side-effecting out your a** here”

I guess even in my 50's my humor is roughly that of an 8-year-old 😛

Let's hope it stays that way :)

Yeah, that could be a better name. When I think "env", I think that it's maintained somewhere as long as the SM exists. That is a useful distinction to be aware of - that the "SM env" is just a short-lived event execution environment, rather than an environment which is owned by the SM during its entire lifespan. Names are hard.

that they are, but I guess acc is just as short to type as env 😄

I really should make more helpers in the ns for direct use with component this, but name collisions are already a problem (trigger mutation vs trigger fn vs trigger-remote-mutations (internal use in handlers)….

hah if only typing speed was the bottleneck 😛 Yes, there does seem to be quite a bit of name overloading. On the one hand it helps that things are similar and are just analogs of each other, but on the other hand, it makes understanding the nuances a bit harder. In my opinion, at least :man-shrugging: I'm finding the ui-state-machines-spec to be a valuable resource. I'm surprised there's no mention of Fulcro's test suite anywhere in the docs. Do you think it would be helpful to add a link somewhere in the intro chapters?

Maybe adding another NS for UISM helpers would help with the delineation?

Yeah I considered that. But there are really several classes of functions you might want: functions that can be used from a component using this, functions that work in a mutation when what you have is primarily the state map in the application, and of course functions that work with the env.

So does that mean UISM needs to be a package, and there need to be three different namespaces? It just sounded a little too messy to do that, so I've just been slow to add functions in the namespace, given that you can already write your own helpers and adapt things as needed. I know that's not ideal, but neither is adding functions that you then wish you could remove