This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-27
Channels
- # aws (19)
- # babashka (47)
- # beginners (111)
- # boot (3)
- # bristol-clojurians (3)
- # chlorine-clover (2)
- # cider (13)
- # cljs-dev (8)
- # clojure (143)
- # clojure-europe (11)
- # clojure-germany (10)
- # clojure-italy (3)
- # clojure-losangeles (1)
- # clojure-nl (1)
- # clojure-spec (6)
- # clojure-survey (3)
- # clojure-uk (42)
- # clojurescript (229)
- # conjure (131)
- # cursive (21)
- # data-science (18)
- # datomic (4)
- # emacs (21)
- # events (2)
- # figwheel-main (12)
- # fulcro (18)
- # graalvm (1)
- # hoplon (40)
- # jobs (1)
- # joker (17)
- # kaocha (1)
- # lambdaisland (1)
- # off-topic (19)
- # rdf (7)
- # re-frame (31)
- # reagent (26)
- # reitit (20)
- # rum (4)
- # shadow-cljs (106)
- # sql (17)
- # testing (5)
- # vim (2)
wouldn't it make sense to make functional components the default since it's a major version, breaking change would only affect some specific use cases that can be worked around, and it wouldn't make sense to start a new project without functional components given how important hooks are now in the ecosystem?
Maybe. But there could be some cases I don't know about that don't work.
at Status we haven't updated reagent for a while it's just not necessary, still using "0.7.0" but we would update for the functional components, but having the compiler option being stateful is more annoying that potential breaking changes
I think I'll try updating the project this week to see if functional components are breaking anything, but for sure being able to use hooks without hacks is going to be nice
> wouldn’t it make sense to make functional components the default since it’s a major version
I don’t necessarily agree with this point because up till now, the only option was class components and many aren’t aware of this distinction, so it would be good to have people knowingly opt-in.
> only affect some specific use cases that can be worked around
Can we confidently say this?
> without functional components given how important hooks are now in the ecosystem
I like functional components as much as the next person, but I don’t actually think hooks
are as widely adopted in the React ecosystem as one would initially think. I would argue these are used among early adopters and well maintained projects, but for many large codebases hooks don’t provide enough of an incentive for them to switch.
All these points are assuming I understand the current suggestion which is we opt-in to functional components 😉
I'm not a big user of react hooks (maybe I should be? don't even know what I'm missing out on) but the biggest benefit to me would be updating the React and ReactDOM versions so they don't conflict for more modern React component libraries. Even the most recent Reagent I can't use current builds of Material-UI or antd v4
It adds a lot of value if you are doing daily React development. But doesnt add any value in cljs land
You can use hooks in Reagent, this article explains clearly https://juxt.pro/blog/posts/react-hooks-raw.html
Also this is a an snippet from one of my projects. It uses MUI v4 and makeStyles hook.
(ns app.navigation
(:require
[reagent.core :as r]
["@material-ui/core" :refer [List ListItem Button]]
["@material-ui/styles" :refer [makeStyles]]
["@material-ui/icons" :refer [ExpandMore ExpandLess BarChart] :rename {ExpandMore ExpandMoreIcon
ExpandLess ExpandLessIcon}]))
;;
(defn custom-styles [^js/Mui.Theme theme]
#js {:root #js {:margin-bottom (.spacing theme 3)}})
(def with-custom-styles (makeStyles custom-styles))
(defn navigation-item
[{:keys [title icon label]}]
[:> ListItem
[:> Button
[:> icon]
title
(when label
[:> label])]])
;;
(def nav-list
[{:title "Home" :href "/" :icon BarChart}
{:title "Dashboard" :href "/dashboard" :icon BarChart}
{:title "Projects" :href "/projects" :icon BarChart}
{:title "Calendar" :href "/calendar" :icon BarChart}
{:title "Clients" :href "/clients" :icon BarChart}
{:title "Template Manager" :href "/templates" :icon BarChart}])
(defn navigation
[]
(let [styles (with-custom-styles)]
(r/as-element
[:div {:class [(.-root styles)]}
[:> List
(for [nav nav-list]
^{:key (:title nav)}
[navigation-item nav])]])))
Wow! Which version of reagent/MUI? Did you use webpack for bundle? You didn't get warnings about ReactDOM incompatibilties?
Ah I see. Thank you @UGMEQUCTV for the explanation on the hooks. I can see how they would be quite valuable in daily React land.
does this method
(ns app.navigation
(:require
[reagent.core :as r]
["@material-ui/core" :refer [List ListItem Button]]
["@material-ui/styles" :refer [makeStyles]]
["@material-ui/icons" :refer [ExpandMore ExpandLess BarChart] :rename {ExpandMore ExpandMoreIcon
ExpandLess ExpandLessIcon}]))
do automatic tree shaking on advanced compilation? If so it might be worth learning the technique. Is this shadow-cljs?You don't need hooks at all if you just use cljs with reagent/re-frame, but when you start doing interop and use js libraries, sometimes hooks are unavoidable. For example graphql lib apollo relies on hooks for the queries, and in react-native world you are missing a lot in react-navigation without effects, such as useIsFocused, useSafeArea, useHeaderHeight, useScrollToTop, and all the hooks related to animations
Also maybe I was doing something wrong but in previous versions of reagent I found it pretty hard to use hooks in components without losing some params in the clj->js->clj conversions (not losing completely but losing namespaces in keywords and sets in vectors)
FWIW, I'm using reagent 0.10 and material-ui 4.9.5 (via the cljsjs packages), works just fine. Not using any hooks, though.
@U077MDEDS gotcha. I'm including material-ui v4 in with npm via webpack/figwheel and I'm getting an error with reactDOM stuff. Let me see if I can replicate real quick...
Here's the issue. I get this error: https://reactjs.org/docs/error-decoder.html/?invariant=321 The minimal code that causes this is:
(def text-area (reagent/adapt-react-class js/window.MaterialUI.TextareaAutosize))
(def main-panel []
[text-area])
The build was:
yarn add material-ui
yarn webpack
with an index.js
(if you're familiar with this build style)
import * as MaterialUI from "@material-ui/core";
window.MaterialUI = MaterialUI;
and a dev.cljs.edn
that looks like
^{:watch-dirs ["src"]
:css-dirs ["resources/public/css"]
:npm {:bundles {"dist/index.bundle.js" "src/js/index.js"}}}
{:main project.core
:closure-defines {DEBUG true}
:output-to "resources/public/js/compiled/app.js" }
So based on the docs here: https://material-ui.com/getting-started/installation/
you need react >= 16.8 and the version in my /target/public/cljs-out/dev/cljsjs/react-dom/development/react-dom.inc.js
is var
ReactVersion = '16.13.0';
wait... I still don't see why that's an issue
anyway I fixed it with the following workaround
import * as MaterialUI from "@material-ui/core";
import * as React from "react";
import * as ReactDOM from "react-dom";
window.MaterialUI = MaterialUI;
window.React = React;
window.ReactDOM = ReactDOM;
and it works now ¯\(ツ)/¯
What figwheel version are you using? I get an error when passing from figwheel-main 0.2.0 to 0.2.1
squint that's a good question. I'm using cider-jack-in-cljs
so I'm not sure what it's using