Experience Report about hx HOT 7 OPEN

Thanks for the report. Very happy to hear a successful story.

from hx.

I appreciate the time you put into writing this up! I'm glad you're feeling productive in it and that it's solving a pain point for you with other libraries.

A couple things that might help:

1. Regarding Context: If you're using reagent-context, it might be easier to construct the Context value using react/createContext (or hx.react/createContext which is just a proxy for it) and then create a reagent-context type using reagent-context.core/->Context. Example:

(def my-app-context (react/createContext))

(def ctx (reagent-context.core/->Context my-app-context))

(hx.react/defnc [props]
  (let [ctx-value (react/useContext my-app-context)]
     [:div (prn ctx-value)]))

(reagent-context.core/defconsumer my-component ctx
  [ctx-value prop1 prop2]
  [:div (prn ctx-value)])

2. Regarding conversion of CLJS data to JS: This happens anytime you pass in props as an element (e.g. [:div {:on-click #(js/alert "hi"}]), and each time your components are rendered. hx only converts things to and from either shallowly - so for instance, passing in a hugely nested map as a prop won't have any performance penalty. Likewise, any JS data structures passed into your component will be left alone. The perf penalties in this case are not that bad. If you find yourself in a particularly hot-path and need to optimize, you can use JS interop in that one place without affecting the rest of your code.

3. Regarding using JS data: You can use any CLJS data with all of the hooks. The only place that you have to use raw JS data is when passing in dependencies to things like useEffect; hx.hooks/useEffect et. al. handles that conversion for you. You can certainly store CLJS data inside of useState. Please do!

4. Regarding naming: good feedback! I'll think about exposing the same functions with descriptive names, as well as adding docstrings to both of them.

Once again, thanks for taking the time to write this up and I hope that we can help aid in things like clearer documentation and easier interop with existing libraries.

from hx.

@tomconnors I would love some numbers about the code size. Did switching to hx reduce the final bundle size?

from hx.

This is an internal application so I haven't made any effort at all to optimize the build size. Tough to give any useful numbers because I added hx + react-dnd without removing reagent.

from hx.

Indeed, if you added react-dnd and hx at the same time it's impossible to compare. And you @Lokeh do you have some numbers?

from hx.

I don't know where to put it and this seems like the most appropriate place.
I tried to incorporate hx components in a Reagent app. Namely, I wanted to add react-beautiful-dnd. I couldn't do it in Reagent alone since table dimension locking requires getSnapshotBeforeUpdate which Reagent doesn't support yet. The example I tried to recreate: https://react-beautiful-dnd.netlify.com/?path=/story/tables--with-dimension-locking

All was well except for table dimensions not being locked. After a fun debug session, it turned out that I have to use react-beautiful-dnd using only hx. I cannot use hx only for the component that requires getSnapshotBeforeUpdate - I have to use it for the whole functionality.

I think the reason behind it is that React and Reagent have separate async rendering machinery. In the working example, getSnapshotBeforeUpdate is fired before the styles of the parent component are updated. And in my version, it was consistently happening after, preventing table cells from locking their dimensions.

from hx.

@p-himik I think reagent has recently added support for new lifecycle methods like get-snapshot-before-update-test reagent-project/reagent#443

from hx.