So this is just me thinking (because we use kee-frame to handle routing in our application) but I would assume you can add-watch to the app-DB and call the subscription's fn on new-state and old-state to determine if the item has changed.

Thanks, the thought struck me. That’s what I would have done in pure Reagent, but I’m not sure what’s considered state-of-art to handle non-rendering-related-yet-event-independent side-effects in Re-frame.

It seems I can add-watch a subscription for the data in question. I wonder if this is preferable to watching the entire DB.

Basically, I’d add it on :component-did-mount and remove it on :component-will-unmount.

The track function from https://github.com/vimsical/re-frame-utils/blob/master/src/vimsical/re_frame/fx/track.cljc might be appropriate also

^, or if you use (ra/run!), it returns an object that you can dispose with (ra/dispose!)

@U051H1KL1 Thank you!

@isak Can you elaborate? Is this related to the above track suggestion, or is this something else?

@U06B8J0AJ Here is an example, it is basically doing what you were talking about in the lifecycle methods: https://gist.github.com/isaksky/75277660572c079a97b71babe80b5667

(it is more complicated because it is also trying to solve another problem, but ignore that)

@isak Interesting, are you using this to avoid running text area updates through the DB, but still having it sync/react to changes in the app DB?

@U06B8J0AJ yea, exactly

An interesting solution, thanks for the suggestion!

I’ve run into that problem previously, before I learned not to lean too heavily on the app DB for precisely everything.

Yet, when containing component state in a ratom, you end up passing around a reference to it in a manner incompatible with the affordances that re-frame provides, so I can see the value.

yea, I was motivated to try to solve that problem, since there were a lot of ways in my app to change the same piece of data

I think even a lawful-good person would be ok with 3 🙂

I agree with isak, 3 is the most natural way You want your event handlers to be computing the new "state of the world", given "the existing state of the world" and "the new event". So getting access to the "the existing state of the world" via access to app-db, is pretty natural.

2 is used rarely IMO.

Chaotic good or at least neutral good, perhaps. The downside is, now your event handler has to know the location of the value in addition to the subscription. In my experience, it leads to a minor explosion of PlOP in a big enough app.

That concern doesn't bother me

I'm perfectly happy with subscriptions knowing about the structure of app-db and ALSO event handlers knowing.

Fair enough, it’s bothered me a couple of times, and then it was really bothersome.

I.e, hunting down all the cases where an assumption was made about the location of a value in order to nest it one level deeper or something like that.

@U06B8J0AJ One thing a lawful-good person could do in such cases would be to use a function to get the value in the handler, which could also be used other places as appropriate

subscriptions are there to: 1. make sure that views don't know about the structure of app-db 2. perform that calculation of materialised views, as necessary

@isak That’s the solution I ended up with in practice.

event handlers have to mutate the structure in app-db so i can't see how they could or should be shielded from the structure of app-db

slightly related: there is an interceptor called path which can "narrow the focus" of an event handler.

In the same way that update-in narrows focus to a certain part of a map.

@mikethompson It’s just that when two things make an assumption about a location, you have to keep them updated in lockstep if you need to refactor that location for any reason (for example, a value became more complex and went from being a string to being a map; now the desired string is a level deeper than before). In addition, this seemed unnecessary as well, seeing as I already had a named reference to the location of that value: the subscription. If something is of such domain importance to me that I have a named reference, I want to use that name everywhere, since it is the semantically meaningful unit. The physical location is unimportant.

We find that our event handlers tend to read/write fairly "locally". Ie. almost all the data they need to read is proximal to the data they they will be mutating. And given they have to know the structure of what they are mutating its not much of a problem for them to also know about the nearby, related data too. Perhaps a bit depends on how you design your app-db? Not sure.

@U06B8J0AJ ^^

Yeah, that must be it. The correctness of the solution will depend on how widely your event handlers have to read when doing their job. I believe it is generally a good idea for them to read/mutate in a narrow area (although obviously that might be harder or easier depending on the domain)

Yeah, maybe it’s a design question. I have a fairly complex, deeply nested tree with about a dozen events operating across it (inserting, deleting, swapping values, clearing, removing sub trees, various kinds of reformatting and updates, and so on) in addition to interceptors (selectively reformatting and persisting the bare minimum serialized in the URL, storing the rest in cookies/DB, querying external services) etc., and subscriptions to match. I’m not sure if this counts as a complex component or not, but it’s seemed complex enough to me in that chasing location assumptions has been tedious enough for me to want to do something about it. I’ve been trying to pull the entire thing more into the realm of the semantically meaningful rather than the incidental aspects of the particular representation as laid out in the DB (though that connection must exist somewhere of course)

Thank you guys! I had to step away last night. Interesting discussion. I'll use #3 with impunity then! My uses case is the app-db has an auth-token that needs to be used to make http requests.

One final question about 3 is the async nature of things. I have a event that gets the key from local-storage, and has a effect map like:

{:db (-> db
            (assoc :auth local-store-auth)
            (assoc-in [:auth :auth?] false))
    :dispatch-n (list
                 [:auth/check-token (:auth-token local-store-auth)])}