Clojurians Log v2

I'm not opposed to it, but I haven't felt the need for it. Do you have an example use case?

For instance, say I want a maximum of 5 todo items. This works:

(defeffect :add-todo [$todos todos next-todo]
  (when (< (count todos) 5)
    (dispatch! :update $todos conj {:description next-todo
                                    :complete? false})))

(defui my-todo-component [{:keys [todos next-todo]}]
  (ui/vertical-layout
   (ui/horizontal-layout
    (basic/button {:text "add todo"
                   :on-click (fn []
                               [[:add-todo $todos todos next-todo]
                                [:set $next-todo ""]])})
    (basic/textarea {:text next-todo}))

(defeffect :add-todo [todos next-todo]
  (when (< (count todos) 5)
    (dispatch! :update $todos conj {:description next-todo
                                    :complete? false})))

(defui my-todo-component [{:keys [todos next-todo]}]
  (ui/vertical-layout
   (ui/horizontal-layout
    (basic/button {:text "add todo"
                   :on-click (fn []
                               [[:add-todo todos next-todo]
                                [:set $next-todo ""]])})
    (basic/textarea {:text next-todo}))

It could be important for bubbling effects, too. It would be nice if a component could return effects without having to know whether the handler needs a value or its keypath.

Yea, I think something like that could be useful, but there are a bunch of design details that would need to be worked out.

> It would be nice if a component could return effects without having to know whether the handler needs a value or its keypath. That's something that would have to be reasoned through. My intuition is that knowing whether something needs a reference or just a plain value does need to be known about ahead of time.

Although, I think the related syntax could be easier to read and write.

There's several pain points related querying and updating the app state. Ultimately, I think the way to make improvements is to have a database for the app state that's better suited to these problems. I've been evaluating several in-memory dbs, but still haven't figured out exactly what's missing.

I can kind of imagine that. A sort of parity like in O'Doyle Rules, where every rule is also a query. Every value is also a location (somehow).

Ideally, every value also has an identity (rather than a location).