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

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.

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.

(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

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"

Hmmm, ok. Fair. But I’ve gone that path where every component is its own “island” and does its own IO. It didn’t turn out very well in terms of the complexity it brings. For example, what happens when you need two requests to be processed in a specific order, but they belong in different components?

Perhaps if you design everything so that the order of requests does not matter, it can be good.

I can also see oportunities to do dynamic batching, like Falcor does https://netflix.github.io/falcor/

the basic idea is to debounce the API requests, so you can accumulate items and send a single request, would be interesting to see how much we can optimize/combine those with EQL