Fork me on GitHub

@mdhaney ah, good pt 🙂 So, it would just be an additional call that you’d make to add options to the current state change transaction. Probably should have had that no matter what.

(uism/apply-action f {transaction options})
I think


might make sense just to have it as a separate step (uism/transact-options env {})


could also be a special key to include in the options map on trigger!?


and then there is the actor model to consider…you want to probably list actor names for refresh


big question is: should it be driven externally (where you may have UI code that is triggering events from some location that knows little of the SM structure) or internally (where the definitions know at least the actors).


I guess this doesn’t yet address the translation from actor names to refresh…I hate to mix the render plugin logic with high-level uism logic


::uism/only-refresh-actors would be sort of ideal, but then we’re mixing a render-specific optimization with the UISM forever


I’m remembering now that I had intended to analyze what actors had changed in the UISM code automatically and optimize that internally, but again we have the problem of mixing UISM logic with something that can be plugged in with arbitrary custom things.


Guess I could make :only-refresh a “standard name” for a thing that renderers can choose to implement. Then the refresh actors stuff would be doable


would love to hear your thoughts


A couple quick thoughts, then I’ll look in more depth tomorrow: External vs internal - I’m thinking handle it internally in the SM. It’s a detail the UI (usually) shouldn’t have to care about, and in the cases where the UI does care, it can always pass event data to the SM to help it do the right thing. I really like the idea of something like ::uism/only-refresh-actors. My initial thinking is you call this once in a handler, then subsequent calls that mutate the state db would adjust accordingly. I was thinking we could just conditionally add :only-refresh to the underlying mutations called by the SM, so no direct changes to the renderer. But it sounds like maybe it’s not that simple. I’ll have to take a closer look at the implementation.


(defmutation add-wire
  [{wire-list-id :wire-list/id
    wire-id :wire/id}]
  (remote [_env] true)
  (ok-action [{:keys [app state]}]
             (df/load! app [:wire/id wire-id] (comp/registry-key->class :wires.ui/Wire))
             (df/load! app [:wire-list/id wire-list-id] (comp/registry-key->class :wires.ui/WireList))))
Isn't something like that considered "bad practice"?


I think that is fine (pessimistic). In theory you could avoid chaining by having a returning mutation, that would both add the wire and bring back wire information. (I've never used, but in the docs:


mutations joins would be the best, specially if you can make the two resources load in a single go (if they are related, you can create a new component that express the query that you need to reload, and use that in returning), this way you can reduce from 3 requests to one


What @U066U8JQJ said…but hard to tell what you graph looks like. If the wire list holds wire, then there is no need to load that specific wire is there? And then if so using returning in the remote would be much better.


Or it's correct way of doing "pessimistic" ui?


Looks like there is a bug in dynamic router when a router has not been started yet. Calling route on it will fail with deferred routes. Working on fixing that now.


ah…not a bug…just a lack of an error message to tell you what you did wrong


3.1.5-SNAPSHOT updated to include the router errors improvement


still testing the form fields a bit just to be sure before cutting a real release, but it looks solid so far