yes this would not work. bind has pretty much the same rules as react hooks or the svelte stuff

no conditions, no loops

(bind {:keys [id data] :as props} (get-in @state-atom [:id 1])) this should also never be done. that will only ever deref once so it'll never updates if you change the value in state-atom

local state is also discouraged so in practice this will never come up 😉

(bind {:keys [id data] :as props} (get-in @state-atom [:id 1]))

(bind local-data (atom data))
  (bind local-data-watch (g/watch local-data))

(bind local-data (atom (get-in @state-atom [:id 1 :data])))

as I said local state is not recommended. neither in fulcro nor in grove. first maybe explain WHY you want local state?

> Storing it in a central atom/db for each instance seems like overkill

it costs pretty much as much as storing it in a local atom, so it is definitely not overkill

but without knowing what exactly you are trying to do its hard to make comparisons

if this is about handlings forms I have a lot of plans for that but nothing implemented yet 😛

> it costs pretty much as much as storing it in a local atom, so it is definitely not overkill I agree, but would also have to handle component lifecycle (add/remove it on component mount/unmount). The use case is: the :data attribute is stored in a central db. Depending on some conditions, instances of a component using this attribute should either: 1. share this value in the central db (i.e. read current value from and update it in central db) 2. or read and store the value only on component instance initialization, then only update the value tied to that instance. Remove the value (wherever it is stored) once the component instance is destroyed.

ok as a general rule of thumb. grove is very much about the concept of "your view is a function of your data". therefore your data drives your components/views. your components should NEVER create data on mount or destroy it on unmount.

instead some part of your data should cause the mount of a component and removing such data should cause your component to unmount

that entire concept somehow got lost in react along the way but it was the promise at the start

it does require rewiring your thinking a little bit but I find it immensly useful personally

of course there is some state that is derived out of your view such as the height of a div or the mouse position or whatever. those are exceptions and bind and local state work for those

everything else should be part of your normalized state

fulcro is very similar in that regard. giving you even more tools to do this such as the forms and uism support

It's currently very difficult to imagine how this would be a practical approach in this case, but I'll try 🙂 Thank you!

I mean the same stuff still happens. its just not your component mount triggering it.

you still haven't provided much info on "in this case". would help if you have some sample code. in fulcro is fine or JS or whatever is fine

Right, sorry, thought I was being clear. You know the 'case': deep recursive trees and toggling. Now, in certain contexts, toggle state should be shared globally between component instances, in other contexts the toggle state should purely be local and transient. Every component shares the same data/state on initialization (and most of the data is 'global'), but there are slight deviations in behaviour depending on context.

:expanded-in-foo-context true :expanded-in-bar-context false

with your component querying whichever context it represents

:expanded-in-contexts #{:foo :bar} :expanded-for #{[:some/ident 1] [:other/ident 2]}

there is ALWAYS a way to express all of this as data

the goal is that if you have all your data at hand you know exactly what your view/ui looks like. no guessing.

with local state that pretty much becomes exponentially harder

Yeah, I understand that and working with Fulcro was so nice because of that. I'm sure there's a way to represent it as data, but it is much simpler (easier? :)) to use local state (in this case). And, in Fulcro, I can always look at the value of that state as well 🙂 The examples you've provided don't work, unless the idents identify the actual component instances. I.e. I have to track :expanded for every component instance. There is absolutely no sharing (in certain contexts). The context simply defines whether the state should be shared globally, not what it should be.

So, the way I see it, representing it as data would be, in some global atom, {id-of-component-instance {:expanded true}}.

again .. flip your thinking and stop thinking about components for a second

there is no such thing as id-of-component-instance. there is id-your-created-in-data-somewhere that is passed to your defc component as a prop

the bind queries something using that id, it gets data back and renders it

in your data you remove that id you created and the component also unmounts

but really this would be much more practical to talk about with some code at hand

Thanks for your effort, truly 🙂 I'll prepare some code ASAP.

I always design data first. meaning I create some EDN data until its in a shape I'm happy with. then I create something that renders it, maybe tweak it again until everything looks good 🙂

Does this help? https://shadow-cljs.github.io/docs/UsersGuide.html#_missing_js_dependency

I don’t know; it looks to me like that’s a different problem. Mine appears to be saying that there is a version mismatch; not that the dependency is missing.

I have a bunch of other similar warnings to do with different deps

Not sure there’s an easy fix. If you are on tools.deps build, you can fork cybermonday and update its deps, and depend on it as a git coord.

Ok I think I see what the issue is… looks like someone on my project added the transitive npm deps directly to our package.json

you can also upgrade shadow-cljs. that check has been removed for a while now 😛

😆 It’s funny you should say that; In parallel I’ve been trying to upgrade shadow-cljs; but I can’t move beyond 2.15.12 without getting test failures. I’m not sure what happened in 2.15.13 that is causing them but I’m assuming it’s somehow related to the closure/clojurescript version bump and perhaps I need to do something with the flag :global-goog-object&array :thinking_face:

Good to know if I upgrade they’ll vanish though :thumbsup:

more details at https://github.com/clojure-emacs/cider/issues/2812 if you want more