Ugh. Just noticed the bundler throwing an error;

Error: Unable to resolve module `./debugger-ui/debuggerWorker.d9da4ed7` from ``: 

None of these files exist:
  * debugger-ui/debuggerWorker.d9da4ed7(.native|.native.js|.js|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx)
  * debugger-ui/debuggerWorker.d9da4ed7/index(.native|.native.js|.js|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx)
    at ModuleResolver.resolveDependency (/Users/kennethtilton/dev/matrix/cljs/mxnative/react-native/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:163:15)

Nope. I fixed what was breaking the bundler. Still no hot reloading.

I'm not super familiar with using fast refresh with RN

one thing to note is that helix's support for react's hot reloading capabilities is done via defnc

we need to register certain information with react, like the name of the component and what hooks are used inside of it, so that react knows whether to re-mount any instances of the component or not

I know that you're mostly using fnc, right? which doesn't do any of that registration. react will deopt to re-mount any components it doesn't have any information about

now, if all of your state is being stored outside of the react component tree then you could get by using defonce on your reactive values, like people do with reagent/re-frame

Thx, @U4YGF4NGM. Interesting. I did not realized how targeted was hot reloading. Hitting the refresh button is not the end of the world, and it sounds like, where I decide to go with a named defnc component, I will get some hot reloading. I have every component allocate a useState hook. When matrix state management sees a change to a component, it calls setState passing the internal state "clock" that drives matrix state management. Application state is spread across a tree of atoms, each bound to some property of some map. React has no idea what I am up to, it just sees all these setState calls of a monotonically increasing value. So far so good. btw, I programmed this way for twenty years without a problem with hot reloading. Hot reloading is nice, but in fact is just the fix for eternal build times occasioned by nonsense tool chains try to get something programmable out of crap like CSS and JS. We shoulda used Lisp for the Web. Natively, I mean. Is no one working on a WebASM Lisp? :)

yeah, the issue is that most JS bundlers (for various good and bad reasons) build your code as a bunch of nested IIFEs

which breaks the lisp-like ability to reload specific functions or data, because any references to them have been closed over by their dependents and are stale

this is different than how CLJS compiles, because we have namespaces. so we can do things like redef a function via the REPL and depends will pick it up under most circumstances

or we can recompile and reload a namespace but trivially use something like defonce without doing any hacking around closures

it sounds like if all state is stored outside of the tree, then you should be able to persist that state using something like defonce

Haha, that confirms how little I understand about the coolio things going on behind the scenes. But thanks for the glimpse. I have to look up IIFEs next. With all state in one atom, does not React think all view functions need to run when that one atom changes? In which case only the internal React VDOM diff heads off unnecessary DOM manipulation? Or do things like Reagent/re-frame use shouldComponentUpdate to avoid regenerating VDOM where not needed?

reagent/re-frame do things similar to what it sounds like matrix does, which is anytime an atom changes it calls setState in the components listening to it. if your components are all listening to one atom, then yeah they will all re-render. you can create multiple atoms for different state. reagent & re-frame also give you tools to create dependent calculations which will cache their values, so that they only re-render components listening to them when the value is different. a typical pattern for a reagent or re-frame app will be to store all state in one atom that is kept in some lone namespace in a defonce, and then create dependent calculations which are used throughout your components. then when your components or calculations change, you can just restart the app, but the state in the atom persists

IIFE stands for "immediately invoked function expression" and is javascript-web-lingo for a closure. i.e. ((fn [a] (prn a)) "foo")

Heh-heh, thx @U4YGF4NGM. I did look it up and was all, "Oh, that." 🙂 I did get into Reagent pretty well recreating my WhosHiring browser in pure Reagent. Felt very much like Matrix. Matrix spreading state across dynamically allocated atoms has the win of hiding state management altogether, but I fear will break hot reloading. Gonna be tough weaning the kids off that. 🙂

I don't know. But one thing I've seen happen a lot, when users must be authenticated, are "shells" like this where authentication is an after thought which results in a sign-in component in the main area with the sidebar and top-menu rendered around it. The sign-in component should be a top-level component too. Planning ahead for a situation like this in the early stages could be helpful.

I don't think macros or higher order components would be necessary

typically we have layout components that take children, i.e.:

($ page
   ($ sidebar
      (d/ul
        (for [item menu-items]
          (d/li (d/a {:href (:href item)} (:label item)))))
   ($ main
      (d/h1 "Welcome to the app!")
      (d/p "We hope you have a nice time")))

page, sidebar and main are components that define some structure and styling and render any children passed to them

(defnc page
  [{:keys [children]}]
  (d/div {:class "page"} children))

(defnc sidebar
  [{:keys [children]}]
  (d/div {:class "sidebar"} children))

(defnc main
  [{:keys [children]}]
  (d/div {:class "main"} children))

Gotcha, thanks! I think I wasn't thinking about the children prop and that gets me some (maybe all?) of the way there definitely. I also found this https://github.com/keechma/keechma-next-toolbox/blob/75f7c44cba3c5e827b0340479a57c42aa63c3982/src/keechma/next/helix/template.clj, which I think might be what I'm looking for but haven't quite got it working yet

that looks quite a bit more complicated

you can also pass in named props, if you want to have more control over the layout. i.e.

($ page
   {:sidebar (d/ul
              (for [item menu-items]
                (d/li ,,,)))
    :main (<>
            (d/h1 "Welcome to the app!")
            (d/p "We hope you have a nice time"))})

ah! I think might be just what I needed

and then the page component can ensure they get put in the right order:

(defnc page
  [{:keys [sidebar main]}]
  (d/div
   {:class "page"}
   (d/div {:class "sidebar"} sidebar)
   (d/div {:class "main"} main)))

Yup that's just what I need thanks!

another thing to consider is to just not have components for layout, since they are just composition of components, in this way, when using something like Tailwind CSS, you can just make layout arrangements as you need

I use tailwind, but tend to extract common combinations of tailwind classes into React components, i.e.:

(defnc page
  [{:keys [children]}]
  (d/div {:class "container mx-auto py-2"} children))

for those cases I have a custom macro that I like to use, that just wraps a tag with some initial classes that may be modified when instantiating them