This is a doodle about a re-frame idea that's been rattling around in my head for a few days. It hasn't quite clicked, but I don't want to let it go yet.
I propose a new standard effect
.
Currently, re-frame has the :db
effect which replaces what's in app-db
holus-bolus.
Imagine a new effect named, say: :db-crud
.
You would use :db-crud
instead of :db
.
The value of :db-crud
would be a vector of proposed changes to app-db
. Update this. Delete that. Add another.
Imagine:
{:db-crud [{:add [:some :path] :val 2}
{:del [:a :path]}
{:upd [:a :b 2 :c] :val "hello"}]
The format used is not very important right now. The sketch above is just for flavour.
Question: why do it this way?
Answer: more information
When you use :db
to make a complete app-db
change, you pass on one piece of information - state has changed.
But you don't say what, how or why.
A :db-crud
effect says more. It says what path(s) changed, and how. It could even say (somehow)
"why" the path changed, maybe. More information.
So, how could this additional information be useful?
Assume we could look at the nominated paths looking for matches
(maybe using something like meander)
On finding a match we could, what? ...
- rerender?
- dispatch an event ?
- compute further app-db crud?
A simpler, less pure variation of alex-dixon's precept?
This information could be used like a database WAL. Or a Kafka-like, event-sourcing bus-ish thingo.
There's a good, useful idea lurking in here, I think.
But ... the key is working out what useful thing can be done with the "extra information".
Every bit of flexibility is potentially useful, yes, but it always comes with a cost. I'm still trying to figure out the tangible benifit.
I like the idea of describing the change (e.g. like assoc-in) instead of passing and mutating db directly. One thought, I find it difficult to write helpers to which pass and contribute to generating the fx context. For example, if two helpers use :dispatch then one clobbers the other. I guess the fix is some kind of consolidation step in between each helpers. Specific issue related to :db-crud is how to apply :db-crud to db so that a helper gets a unified view of db. Not sure I've communicated that well.