Clojurians Log v2

@yogthos are pre and post conditions going to be the mechanism by which we can conditionally fire some events but not others based on the result of a handler? The likely have other uses as well, but just wanted to confirm.

yeah what I was thinking was that you could put :pre and :post keys in the options map on the path segment, then those would be injected in each event that takes the segment as its input

and I'm thinking the pre/post can return either the output that gets persisted in the state, or an error

actually maybe it can return a map with a dispatch key that could be used in a multimethod

so the default would be to persist the output, and then you could define custom ones to do whatever

Funny, that is just what I was going to say. 😉

excellent 🙂

I saw your doc changes to indicate taking a map on inputs and outputs. Are you going to change the result of the handler to return a map with named values as well?

sounds like we have a plan

yup

cool.

should already be done in the change

just need to clean up the docs

sweet.

and the resolution logic there is to go by the keys the handler explicitly returns and only modify those

so if it an output is declared but it's not in the output map, then it will be left alone

and clearing an output requires putting the key with a nil value

yeah, that makes sense. But clearing would not fire the event correct? Just remove it from the db?

and presumably if the output key is not present, no event will fire either.

yup

basically the idea is that the handler explicitly declares what of its output keys it's changing

:thumbsup_all:

Given this model

And this transaction

Should one expect the event to fire? I would say yes but that is currently not the case. This is the other side of the coin WRT to firing parent events. Put another way, would we want to attempt to translate the above transaction into (domino/transact @ctx [[[:parent :child] 2]])? Certainly adds complexity and I'm not 💯 that there exists a mechanical transformation vs. one where domino would need to make decisions/assumptions.

I can see use cases for both behaviours

I have been using re-frame as a mental model and re-frame's answer to this is yes. However, we are not obligated to follow the way re-frame works. This is definitely more complex than the other change which made the parent sub-paths fire, as in this case, the model can be arbitrarily complex. However, it should not be too difficult to write a function which simply returns all of the necessary paths (child and parent), given the original input and the model.

And I take that back, there probably is a mechanical transformation.

I'm leaning towards yes on this one since the input value for :c changed, and events should be firing whenever their inputs are updated

Hm, same re yes, but I'm hesitant to be firm due to other possible data collections. Or even do we want to support lose models where you can have nested maps that aren't speced out? Depends how opinionated we'd want to make it

Maybe value in having it as a separate module?

+ I'm very much in favour of keeping core lib lean/just the execution engine, and add additional functionality as separate modular libs. A la reitit

I think we should maintain data that is passed in, even if it is not spec'ed out in the model. That, IMO, is in the spirit of Clojure more broadly. That is, pass along what you don't care about, use/validate what you do care about (and pass that along too).

So, in the above example, if the user ran this transaction: (domino/transact ctx [[[:parent] {:child 1 :other-child 2}]]), we could translate it to a transaction that looked like this: (domino/transact ctx [[[:parent] {:other-child 2}] [[:parent :child] 1]]). I think that works.

At least, I got the expected results when I ran it by hand.

The db then would contain {:parent {:child 1 :other-child 2}}

And, IIUC, the redundent [:parent] path triggering would be pruned due to the use of a set.

WRT implementing it as a separate module, I'm indifferent to that. If others feel strongly about it one way or the other, I'm totally cool.