This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-25
Channels
- # announcements (16)
- # babashka (110)
- # babashka-sci-dev (11)
- # beginners (50)
- # biff (3)
- # calva (1)
- # clj-commons (19)
- # clj-kondo (1)
- # clojure (17)
- # clojure-art (19)
- # clojure-austin (5)
- # clojure-berlin (2)
- # clojure-denmark (3)
- # clojure-europe (101)
- # clojurescript (84)
- # clr (1)
- # core-async (2)
- # emacs (3)
- # helix (5)
- # honeysql (4)
- # hyperfiddle (8)
- # introduce-yourself (2)
- # jobs (1)
- # lsp (18)
- # membrane (3)
- # reagent (5)
- # releases (3)
- # shadow-cljs (10)
- # tools-deps (24)
Is there a downside to omitting ^:native
when symbols correspond directly to JS components in an ES module? For instance
(require '["@mui/material/Button" :default Button])
(defnc some-component []
;; note no ^:native provided
($ Button "Hello"))
This seems to work, but I’m wondering if that is a happy accident or it is okay to do thiswhat $
does normally is translates your props map literally. so if you wrote
($ Button {:onClick #(js/alert "hi")} "Hello")
it would literally create a call like
(react/createElement Button #js {:onClick #(js/alert "hi")} "Hello")
this is good, because you can look at the documentation of material UI, see it takes an onClick
prop, and write :onClick
in your codemarking it as ^:native
will automatically change kebab-case to camelCase for you, as well as translate DOM props like :class
to :className
and :style
will be transformed into a JS object from CLJS data
IMO this was a mistake to build into $
. it's wrong half the time, because sometimes you want the kebab-case transformation but you don't want :style
, or you do want transformation from clj->js in some other prop but it doesn't do that for you so you have to remember which props it does automatically and which do not