Hey there! I actually really like both libraries! I would begin with Reagent because there’s going to be more Clojure examples available to you in open source, documentation will be abundant and reagent comes with a state management library built in which you can opt to use (ratoms) and finally it wraps React in such a way that you can think “Clojure” over thinking “React”.

If you’re goal is to understand React (and this is a great goal!) then you should just work with React for a bit and see what’s up. There is going to be no substitute for going right to the source.

I probably should have begun my responses with: what’s your goal?

@U06FM9QN9 you may find Grokking Fulcro interesting. Irrespective of whether you ever bother to use Fulcro, Tony Kay walks through a lot of the problems Fulcro (and other libraries) need to address to wrap React properly. https://www.youtube.com/watch?v=3dZK5seIaVI&list=PLVi9lDx-4C_TBRiHfjnjXaK2J3BIUDPnf

Oh that YT series is really good. The presentation is a bit ad-hoc, but I find that relatable. What is interesting and educational here is how he breaks through the abstractions of React and really plays with it and shows how Fulcro is wired up. I started watching it to learn more about Fulcro but then I realized how little I understood React in the first place 🙂

Amazing project ! But it's not really clear for me what are the limitations that React wrappers have that your approach does not have

its not react based that is the main limitations you dont have 😛

I make no claims about being better or worse than react

Ok I see 😛

Wouldn't it still be the case for controlled components? E.g. see https://stackoverflow.com/questions/46000544/react-controlled-input-cursor-jumps and https://github.com/facebook/react/issues/955

well, I may be wrong, but I didn't think think this was an issue generally. the last comment in that thread is The canonical solution is to make sure you're calling setState` with `e.target.value` during the `onChange` event. That should be enough to preserve the cursor.`

Yes, but IIRC the Material UI input field does not do that as well. And Reagent does it for all inputs itself, but it cannot access the internals of Material UI - that's why it needs you to provide the input explicitly.

ah sorry you're quite right. I'll delete my comment as misleading

regarding shadow-cljs either shadow-cljs browser-repl or shadow-cljs node-repl. creating a :browser build for local testing also works, or one of the testing builds can also help

so yes you want either of these tools for local development regardless. the lib is just the uncompiled sources in a .jar so it doesn't matter which tool you use for local development

I'd say it looks like a proper bug.

Ah, in that case I’ll file it on github. Or here rather. https://clojure.atlassian.net/jira/software/c/projects/CLJS/issues/

cljs꞉cljs.user꞉> 
(update [0 0 0] 4 inc)
; Execution error (Error) at (<cljs repl>:1).
; Index 4 out of bounds  [0,3]

bug reports don't go in github - they should be filed here https://clojure.atlassian.net/jira/software/c/projects/CLJS/

hmm I think this is actually a difference in inc

update uses assoc under the hood. using just assoc, the behavior is the same between impls

Clojure 1.10.1
user=> (assoc [] 0 1)
[1]
user=> (assoc [0 1 2] 3 3)
[0 1 2 3]
user=> (assoc [0 1 2] 4 4)
Execution error (IndexOutOfBoundsException) at user/eval5 (REPL:1).
null

cljs.user> (assoc [] 0 1)
[1]
cljs.user> (assoc [0 1 2] 3 3)
[0 1 2 3]
cljs.user> (assoc [0 1 2] 4 4)

Execution error (Error) at (<cljs repl>:1).
Index 4 out of bounds  [0,3]
:repl/exception!

A good find!

the difference:

user=> (inc nil)
Execution error (NullPointerException) at user/eval7 (REPL:1).
null

cljs.user> (inc nil)
1

Given that, my guess is that it will be closed with "won't fix". Numerical differences are usually preserved between CLJ and CLJS.

yeah

yeah, cljs is more lax from all kinds of angles, often due to the host semantics

I think even considering js vectors as "associative" is wrong. Why would anyone do that? I can't come up with a single good idea why would I want to assoc or update in a vector?

vectors are associative structures in both clojure and clojurescript

And js arrays are actually maps lol

it's part of their core performance characteristics - you should be able to quickly read and update a value by index with a vector. as opposed to a list, which you would have to traverse the list up to the index, which is why they do not implement IAssociative

@U0G75ARHC we're so used to updating things by mapping over them, we forget that we'd want to, but how else would you update a vector by index?

<troll>
(vec (doto (js/Array 1 2 3) (.splice 0 1 5)))   ; => [5 2 3]
</troll>

Oh, look. It predictably fails successfully when given out of bound index. Javascript is full of ... things that make Gary Bernhardt happy 🙂

Wait am I missing something. It seems strange to me that this works in either implementation.

user=> (assoc [0 1 2] 3 3)
[0 1 2 3]

Looks like (assoc v (+ 1 (count v)) 9) is supposed to be synonymous with (conj v 9)

https://github.com/clojure/clojurescript/blob/aec9f0c576ac6b11d3e30e79553c8ebe67bf0f73/src/main/cljs/cljs/core.cljs#L5653

So as to allow using assoc'ing on the end of a collection as a conj op

Guessing the same logic is happening somewhere in the guts of clojure.lang.RT

well, (assoc v (count v) 9) I guess, since the count of v would need to be converted to zero-based index

But adding an element to the end of the coll, as with conj, seems to be an intended use case for assoc in that way

Which is nice if you're iteratively associng on the same vec over a range

Ah cool, thanks @U050PJ2EU for pointing me to that. Makes sense