Clojurians Log v2

This might be a silly question (apologies - I’m new to clojurescript, coming from a python background), but what are the benefits of using helix instead of just reagent?

As someone who used helix for many months now but never tried reagent, my reasoning was that this way I can use react state management and any react developer can understand the code, if they squint a bit 🙂 Even though possibly the state management tooling provided by the core of clojurescript is one of the biggest value propositions, having to sell all of it at once to my bosses would've been more difficult. And I wasn't very experienced with cljs.

yep, like Aron said, helix is very close to React. Reagent adds a bunch of stuff on top

both are fine choices. reagent has a lot more discussion, blog posts, and usage in the ClojureScript world. if you're new to both ClojureScript and front end development, it might be easier to get help

however, if you're already familiar with front end development using React, helix should make it very easy for you to jump in, learn the syntax and start building UIs

awesome, thanks @ashnur and @lilactown. So if I understand this correctly, Helix is more like React, and Reagent is more idiomatic clojure. I kinda like the idea of having something that almost looks like React, but that interfaces well with Clojure. The only shortcoming I see for Helix right now is that it doesn’t have super straightforward interop with re-frame, which is arguably the most popular state management framework for clojurescript. I looked at the hooks on github but it’s a bit confusing (at least for a noob) on how those hooks exactly work, so I haven’t managed to make re-frame work with helix (yet).

I am also a bit confused by the situation. In theory there is a use-subscription hook somewhere, but I think that's only experimental?

Or uses pre-Fiber assumptions

I’ve been using React/ReactNative since 2014 or so. I’ve seen a number of libs/frameworks/state management approaches come and go, both in CLJS and JS world. I think sticking as close to React as possible makes sense (to the point where I don’t use any libraries at all, I just use direct JS interop with React and have my own basic state management on top). If I’m forced to pick a library today, Helix would be my choice.

One less than great thing about trying to combine reframe and helix is that you will end up with both helix and reagent in your application. For a production application that is probably less than desirable

I think using React directly + using basic Clojure(Script) constructs is an underappreciated option. It does require very good expertise and understanding of both React and Clojure(Script), perhaps that’s why.

I think if I were to use react directly, I would end up writing very similar helpers, so since @lilactown already took the work, I use it 🙂

That’s fair, but esp. around hooks, I think just using interop is super basic.

one thing to consider here is that DCE is quite good in CLJS, this means you can use reframe, but use just the hooks helpers from Helix, this way you pay a very low price on it, in fact, only what you use

(def use-effect (.-useEffect React))

(use-effect 
 (fn []
  (fn cleanup []
   )))

What kind of wrapper do you really need here 🙂

when you have a cleanup, I think looks good, but this botters me:

(def use-effect (.-useEffect React))

(use-effect 
 (fn []
    (do-something)
    js/undefined))

Not familiar with the js/undefined case. Which hook does that apply to?

because if you don't return js/undefined, React complains that you can only return a fn from a effect

this is because of JS vs CLJS different, in JS, if don't use return on a fn, you get undefined as the return, but in CLJS it will return the value of the last expression

which, if it is anything other than a fn, or js/undefined, will throw an error from React

Yeah, I suspect in practice though you may run into more issues than just code size. Closure dead code elimination is definitely great. But you will also potentially have conflicts with dependencies. You could have confusion on a team about which way things ought to work. etc. Definitely not suggesting don't do it at all. Just that is probably worth thinking through and really testing out what it is like in practice before making the decision. Also, though, if people really like reframe and those people also want to use helix, making a reframe like library is a great opportunity for someone.

Hmm, I’ve always been returning a cleanup fn.

(for that past few months since I started using hooks and useEffect)

I guess that’s how I avoided running into that case, I always put an empty (fn cleanup []) even if it did nothing.

FWIW, my whole medium-sized project has only 4 (useEffect …) usages. I try to keep any side-effecting stuff out of the components as much as possible.

I do use a lot of effects to integrate foreign libraries, like Cytoscape graph renders, D3 integration, CodeMirror integration, for those effects are super handy 🙂

Yes, I think those are good use cases. Mostly non-IO related stuff. If people start putting HTTP calls, etc in use-effect I think it’s not good.

I used to think like that in the past, but nowadays I'm starting to think it can be good, and the Suspense + Async Rendering seem like something that will favor this kind of approach. my long time as a Fulcro usermade me aware of advantages and how we can reduce the number of requests. but at same time I feel the pain of *needing* to connect every component in the same query. so I'm excited with Fulcro Raw, which allows some effects to tap into the app state, and they may also trigger IO in the middle, I have coded a few projects playing with that, and I quite enjoy the results, I can develop really fast, and if I see the number of IO going off the rails, Ican always refactor, connect some queries and move the IO up.

still feels experimental, but I have big hopes with this path of "ui tree processing"