More and more there seems to be hooks-based React stuff I'd like to use in my Reagent projects. My first thought is that I'd like to put it all behind a component interface down in a private lib and use Helix to provide the interface ... reagent then is none the wiser. Is there good guidance anywhere on the current way to do this? I guess some of this question is around using the :bundle target and somehow not pulling in React twice, as well as how exactly that vanilla cljs compiler :bundle target interacts with libraries.

it's possible these statements aren't even wrong; I'm just forming up the problem in my head

hm, think I've figured it out with figwheel's autobundle. But it seems like the consuming project has to know what NPMs the cljs lib needs so it can be provided somehow (eg react, react-dom). In my case, I'm trying to use downshift-js and react-select as internal implementation details. Is there an in-band way to publish this so the parent doesn't have to specify it, or is it a thing you just have to document?

(not the end of the world if so; there's still some value in providing a handy cljs wrapper to hide a lot of the tedious cli->js/bean goop).

you can easily use helix components in your app.

in fact, you can use helix $ and react components anywhere in your reagent components

(defn my-reagent-component
  []
  [:div
   [:div ($ helix-component {:foo "bar"}
            (r/as-element [another-reagent-component [:div "child"]]))]])

regarding :bundle and the deps/lib stuff... not really sure

> Is there an in-band way to publish this so the parent doesn't have to specify it, or is it a thing you just have to document? publishing a CLJS lib that depends on an npm lib can be done using a https://clojurescript.org/reference/packaging-foreign-deps

however, I removed the one from helix because the compiler was warning people when they used a different version of React than I specified. I simply document that you must use a version of react with hooks in it

Thanks. I was shocked that I actually got it working in the consuming app. It's gotten so much easier than it was back when I got started in cljs. I'll take a look at deps.cljs … somehow I missed that. Not planning to put in react but some of the more exotic npm stuff that it's hard to imagine conflicting.

I've kind of lost track of whether it's socially encouraged to rely on cljsjs or is the new bundle stuff preferred where possible.

Oh wait deps.cljs is the mechanism for cljsjs. Never mind me.