This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-31
Channels
- # announcements (5)
- # babashka (105)
- # beginners (92)
- # calva (77)
- # cider (17)
- # cljdoc (8)
- # cljs-dev (8)
- # cljsrn (8)
- # clojure (272)
- # clojure-dev (25)
- # clojure-europe (5)
- # clojure-italy (6)
- # clojure-nl (7)
- # clojure-norway (3)
- # clojure-uk (108)
- # clojurescript (326)
- # code-reviews (4)
- # cursive (6)
- # datomic (37)
- # duct (5)
- # emacs (14)
- # fulcro (23)
- # graphql (1)
- # juxt (1)
- # kaocha (2)
- # leiningen (10)
- # malli (9)
- # music (1)
- # nrepl (12)
- # pathom (21)
- # pedestal (2)
- # planck (4)
- # quil (3)
- # reitit (29)
- # rewrite-clj (10)
- # shadow-cljs (82)
- # spacemacs (29)
- # sql (6)
- # tools-deps (19)
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
I'm new to Fulcro and I'm having problems using it with Material-UI components. I also posted this question in stackoverflow (https://stackoverflow.com/questions/58644394/how-to-npm-packages-in-fulcro)
I'm following the Fulcro 3 Dev Guide, section Using Javascript React Components, with the Fulcro Template (https://github.com/fulcrologic/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
clojure
(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]}
(dom/div
(str "Fulcro counter demo [" counter "] ")
(ui-button
{:variant "contained"
:color "primary"}
"Another Button")
(dom/button {:onClick #(fm/set-value! this :counter (inc counter))} "+")))
(ws/defcard fulcro-demo-card
(ct.fulcro/fulcro-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?
Ah: https://stackoverflow.com/questions/47663765/typeerror-cannot-read-property-root-of-undefined
also: https://material-ui.com/getting-started/installation/ React version matters
and it also sounds like a lot of ppl see this error with Material UI…you’re doing the shadow/fulcro stuff right….just a cursory search leads to all of this: https://github.com/mui-org/material-ui/issues/16202 https://stackoverflow.com/questions/56574417/material-ui-v4-cannot-read-property-root-of-undefined-for-every-component https://spectrum.chat/material-ui/general/cannot-read-property-root-of-undefined~3d925876-6eff-4e33-9c9b-a50517328fe4
This one fixes it for me: https://github.com/mui-org/material-ui/issues/15898#issuecomment-507476163
Thank you, I'll test it soon. I thought it couldn't be the version because I have the same working in Fighweel Main.