In case you're using Reagent, #C0620C0C8 would be a better place for this question. Create as many ratoms as there are components that change them, and replace the top-level ratom with a reaction that checks that all those other ratoms are true. Alternatively, if the number of buttons is known, replace the boolean ratom with a counter. Increment it when something "enables" it, decrement on "disabling". Consider the final state to be "enabled" when the counter is equal to the number of buttons. Note that this approach requires you to be rather careful.

how do i do the first approach with a reaction? any documentation or examples anywhere?

Uhm... In the Reagent docs? :) Reagent is extensively documented (except for its internals).

I am a beginne so I dont know where to look for this specific example exactly

https://github.com/reagent-project/reagent/blob/master/doc/ManagingState.md#reactions

It'll end up as something

(let [enabled? (r/reaction (every? deref [enabled?-1 enabled?-2 enabled?-3]))]
  ...)

Alternatively, given that the body of the reaction is so simple, you can avoid it altogether and just go with (every? ...). Unless you have other components that expect a single atom-like thing to deliver the "enabled" state.

Thing is Its a dynamic number of components

Have them all have unique IDs, create a single ratom that contains a set of disabled IDs. When that set is empty it means that everything is enabled. There are many solutions to this problem.

If you use shadow-cljs in that project, then it has shadow.cljs.modern/defclass.

Cheers! I'll check it out.

A macro? Assuming paths are static. Then they can also become keywords. And then... you got yourself cljs-oops. :D But it also has dynamic accessors, maybe there's some good code in there, dunno.

macros aren't an option here, for reasons

Suppose you are in pure JS land, no other tools

const dynaGet = (obj, path) => path.split('.').reduce((obj, key) => obj[key], obj);

maybe you can use Map.prototype.get() somehow

IME replacing reduce with a for loop will win you some tens of percents of performance in at least Chrome.

@U04V4KLKC Objects aren't maps.

There's 0 reason to use any functions when you have [] in JS.

That's even slower:

cljs.user=> (def dynaget (js/eval "(path) => (obj) => path.split('.').reduce((obj, key) => obj[key], obj)"))
#'cljs.user/dynaget
cljs.user=> dynaget
#object[Function]
cljs.user=> (let [x (clj->js {:a {:b {:c 3}}}) accessor (dynaget "a.b.c")] (prn (inc (accessor x))) (time (dotimes [i 10000000] (inc (accessor x)))))
4
"Elapsed time: 702.958042 msecs"

Weird. Definitely not what I would've expected.

I get opposite results in Chrome.

Can you eval it once and reuse the helper?

yes, that's what it already does

Ohh, I missed that :thumbsup:

@U04V15CAJ Seems like the performance here is largely dictated by the platform. In that case, it's kinda hard to figure out what the best approach is - even if your platform is fixed, it might have different performance under different OSes or when updated to a newer version. In any case, I would still try replacing reduce with an explicit for loop.

I was testing in planck (self-hosted on webkit) so yes, different host. still 400ms vs 10ms... there must be a way to get that 40x speedup somewhere without eval?

Not necessarily - there might be special handling for . that's for some reason missing for [] (perhaps because the former cannot accept integer indices whereas the latter can).

beware micro benchmark such as that one. it is basically useless to tell you anything about actual performance

JS engines work on "shapes", and if this function is called with multiple shapes its performance profile is going to change drastically

so at the very least test with objects of different shapes and depths

It seems lodash has a kind of function like that. Maybe worth looking into: https://lodash.com/docs/4.17.15#get

It's just a while loop in there.

yeah, pretty similar to what you had

there is also https://github.com/google/closure-library/blob/9fc3162d1561f0d48e3d66502e322613d05c3fa1/closure/goog/base.js#L728-L738

Loosely translated from goog.base, eliding the null check

cljs.user=> (defn getObjectByName [cur parts] (loop [cur cur i 0] (if (< i (.-length parts)) (recur (unchecked-get cur (aget parts i)) (inc i)) cur)))
#'cljs.user/getObjectByName
cljs.user=> (let [x (clj->js {:a {:b {:c 3}}}) arr (.split "a.b.c" ".")] (prn (inc (getObjectByName x arr))) (time (dotimes [i 10000000] (inc (getObjectByName x arr)))))
4
"Elapsed time: 103.103084 msecs"

@U04V15CAJ js/Function is often available where eval is not

@U017QJZ9M7W Do you happen to know if many sites restrict that or not?

http://twitter.com seems to block both:

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'

I found out about it reading posts on the function constructor as a “safer alternative” to eval but I don’t know anything about what’s more available in the wild unfortunately

It will work only for string literals and not for string objects. And I'd say that extending built-in types for convenience is discouraged. There was a nice article on that that I can't find right now but I have definitely been bitten by it before.

Then covering both string and js/String should suffice, no? I believe String in JVM Clojure is extended to implement IStack I guess implementing IStack for strings in CLJS is a bad idea anyway because CLJ doesn’t do this. For some reason I had thought it did

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IPersistentStack.java clojure doesn't have IStack, it has that, which extends IPersistentCollection which makes implementing it more involved

Also on the jvm the interfaces a class implements are part of the definition of a class and cannot be changed after the fact

Be not discouraged! This is an excellent use-case for which you could (I'm sure it would take only a weekend) implement the much-talked-about "Clojure-in-Clojure" based on the protocols developed as part of ClojureScript. And then do your experiment extending String to Stack. Let's defer discussion of whether that extension is a good idea until after you're done with Clojure-in-Clojure.