Hey, I'm trying to play with the new functional-compiler thing
I was wondering, now that I'm doing the following:
(rd/render [:f> app] (. js/document getElementById "app") functional-compiler)
using functional components like from material-ui needs to be how? like this?
[mui/Button "hello"]
or
[:> mui/Button "hello"]
?
When I try without the :>
I get some errors, and I'm trying to figure out if I'm using it wrong
@eliraz.kedmi157 the option is for generating function components from Reagent components (defn) no need for interop.
So [:> mui/Button "hello"]
, this doesn't change how interop works.
Difference between [foo]
and [:> foo]
isn't as much if class or function component is generated, but what JS object is used as React props. For Reagent components (first case), JS object with argv
property is created which contains the Cljs value, interop :>
exists because React components need to see the JS object with properties from props map directly, which is why :>
and adapt-react-class
convert the Cljs props map to JS object.
@juhoteperi thank you for your answer. so using the interop :>
will generate a function component in my case? (`mui/Button` is a function component)
In the interop case, Reagent doesn't generate any component as mui/Button
is already a component. It will just generate createElement
call.
oh okay
so if I get it correctly :>
only converts the props to a js object and generates the createElement call?
so what's the :r>
and :f>
for?
:r>
doesn't do any cljs map to JS object conversion, so you can pass in JS object yourself. The conversion is inconvenient sometimes as it recursively converts all Cljs values to JS, so you can't e.g. provide cljs vector inside properties.
:f>
is for creating Reagent function components from Cljs functions, without using :functional-compiler
. This allows opting to functional components per function, instead of per application.
got it
Thank you so much for elaborating