Fork me on GitHub

Is there any particular reason to avoid passing a vector as props to a component (other than that it feels kind of funky)?


well, it is not designed that way, though I cannot think of a particular technical limitation. That said, using the API in ways it was not designed leads to application fragility over time. Props is meant to be a map.


I figured as much, thanks for confirming. I’m struggling with a deeply nested map that sits as a single value in the database, containing no sensible idents for me to break it up, and now I need the UI to traverse it.


The leaf nodes are vectors right at the point where I need to insert a component that groups the (vector) leaf nodes in question. I’ve resigned myself to using select-keys on the parent to avoid sending a straight up vector as props to the grouping component.


So, it is perfectly reasonable to use components without queries/idents at the leaves of your tree for things like that


but the problem you describe: You’re wanting to do a group-by on elements of the vector and then render those in a particular way? Why not just do the group-by in the parent (which results in a map) and select things out of that map to render in subcomponents? perhaps that is what you meant ?


I’ve been trying to avoid manipulating the shape of the data in the parent component since I got the impression that the data should preferably flow directly from parent to child in order to avoid unnecessary component updates when dependant data changes. But maybe that ship sailed anyway with the absence of idents?


The shape is roughly,

{:a {:b [d1 d2 d3 … dn]
     :c [d1 d2 d3 … dn]}}
With there being no difference between :b and :c at all, so they don’t warrant different components to handle them. The fact that they are named differently, though they contain data of the same shape, leads to some awkwardness in writing components for them (without rewriting :b and :c to some common key that the group component can recognize).


correct. In the situation you’re in you might consider creating a memoized function using :initLocalState that does your data manipulation…then at least if your get a spurious update that doesn’t change the dependent data you’ll get a cached value

👍 4

Good idea!

Jp Soares13:10:30

I'm new to Fulcro and I'm having problems using it with Material-UI components. I also posted this question in stackoverflow ( I'm following the Fulcro 3 Dev Guide, section Using Javascript React Components, with the Fulcro Template ( project, trying to import the Material-UI React components. I added the package with npm install --save @material-ui/core and modified the demo_ws.cljs file

(ns app.demo-ws
  (:require [com.fulcrologic.fulcro.components :as fp]
            [nubank.workspaces.core :as ws]
            [nubank.workspaces.card-types.fulcro3 :as ct.fulcro]
            [com.fulcrologic.fulcro.mutations :as fm]
            [com.fulcrologic.fulcro.dom :as dom]
            ["@material-ui/core/Button" :default material-button]
            [com.fulcrologic.fulcro.algorithms.react-interop :as interop]

(def ui-button (interop/react-factory material-button))

(fp/defsc FulcroDemo
  [this {:keys [counter]}]
  {:initial-state (fn [_] {:counter 0})
   :ident         (fn [] [::id "singleton"])
   :query         [:counter]}
    (str "Fulcro counter demo [" counter "] ")
      {:variant "contained"
       :color "primary"}
      "Another Button")
    (dom/button {:onClick #(fm/set-value! this :counter (inc counter))} "+")))

(ws/defcard fulcro-demo-card
    {::ct.fulcro/root       FulcroDemo
     ::ct.fulcro/wrap-root? true}))
and having the error in the console:
Uncaught TypeError: Cannot read property 'root' of undefined
    at eval (Button.js:323)
    at renderWithHooks (react-dom.development.js:16242)
    at updateForwardRef (react-dom.development.js:18125)
    at beginWork$1 (react-dom.development.js:20187)
    at HTMLUnknownElement.callCallback (react-dom.development.js:337)
    at Object.invokeGuardedCallbackImpl (react-dom.development.js:386)
    at invokeGuardedCallback (react-dom.development.js:441)
    at beginWork$$1 (react-dom.development.js:25739)
    at performUnitOfWork (react-dom.development.js:24666)
    at workLoopSync (react-dom.development.js:24639)


I’ve not personally tried material ui, but the “undefined” thing makes me thing your require isn’t working…which is not unusual given the fragmented way js ecosystem works. Try logging material-button and see if it is undefined. If so, tinker with require…I often look in the node_modules folders and see how it’s packaged, and then also use the docs for shadow-cljs. Some libraries are much harder to use than others because they expect you to do strange things. In principle you’re doing the right thing for Fulcro.


It is strange that the stack trace seems to have found Button…the error is coming from line 323?


sounds like it might be a “version mismatch” sort of issue?

Jp Soares16:10:35

Thank you, I'll test it soon. I thought it couldn't be the version because I have the same working in Fighweel Main.


yeah, but npm dep management can screw up for all manner of reasons, and adding shadow-cljs to your package.json will change the dep tree. It is working for me in fulcro-template with the change to deps.


(I upgraded React to latest as well)

Jp Soares17:10:26

It worked, thank you very much. I added the hoist-non-react-statics version 3.3.0 and updated react and react-dom.