This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-06
Channels
- # announcements (3)
- # aws (23)
- # beginners (61)
- # calva (57)
- # cider (121)
- # clara (1)
- # clj-kondo (9)
- # cljs-dev (62)
- # cljsrn (3)
- # clojure (79)
- # clojure-europe (2)
- # clojure-nl (19)
- # clojure-spec (9)
- # clojure-uk (14)
- # clojurescript (92)
- # clojureverse-ops (2)
- # cursive (3)
- # data-science (2)
- # duct (1)
- # figwheel (2)
- # graphql (6)
- # jobs (1)
- # kaocha (5)
- # leiningen (11)
- # off-topic (25)
- # overtone (1)
- # pedestal (4)
- # portkey (1)
- # re-frame (1)
- # remote-jobs (2)
- # shadow-cljs (179)
- # slack-help (3)
- # specter (7)
- # testing (14)
- # tools-deps (14)
- # unrepl (12)
- # vim (2)
- # yada (3)
Q: I’m struggling with interop to https://github.com/FezVrasta/react-popper. Does anyone have sample code for this? I have it working for an older version but I want to use the latest and I can’t get the react refs working properly in reagent
this worked for me:
(ns popper-example.core
(:require [reagent.core :as r]
["react-popper" :as rp]
[applied-science.js-interop :as j]))
(defn popper-example []
[:> rp/Manager
[:> rp/Reference
(fn [props]
(let [ref (j/get props :ref)]
(r/as-element [:button {:type "button" :ref ref}
"Reference element"])))]
[:> rp/Popper {:placement "right"}
(fn [props]
(let [{:keys [ref style placement arrowProps]} (j/lookup props)]
(r/as-element [:div {:ref ref :style style :data-placement placement}
"Popper element"
[:div {:ref (j/get arrowProps :ref)
:style (j/get arrowProps :style)}]])))]])
(r/render [popper-example] (.getElementById js/document "app"))
@U4YGF4NGM any chance you’d be willing to show me how to style it (using Emotion I presume). That’s not obvious either
I also found https://github.com/bwalex/verktyg but I’d prefer to avoid another dep if it’s not too much interop
Seems straight forward. Pass in classes / styles to the elements you render in the render prop
yes it should be but I don’t do js interop much so the incantation is not obvious to me
I always forget why we need the global and local installation of shadow-cljs?
$ npm install --save-dev shadow-cljs
$ npm install -g shadow-cljs
@teawaterwire you don't need the global install
you only need it if you want to use shadow-cljs ...
instead of npx shadow-cljs ...
makes sense, thanks!
you need it in the project to ensure that other dependencies are installed in the project
@thheller I read somewhere that you tried getting react-native hot reloading to work without expo, was it a struggle, you think it's possible to implement?
@hlolli Maybe you read my posts here about it? I had trouble with it because I also wanted to use “React Native Navigation” (from Wix). With Thomas’ help I was able to get it working, see https://github.com/svdo/CLJSReactNativeNavigation. With normal react-native stuff it should just work with shadow-cljs, no difficulties that I know of.
@stefan.van.den.oord nice! There have been no difficulties so for, I can turn on "Live Reload" on the iPhone simulator, but I can't see if the websockets are connecting.
You actually don’t need to turn “live reload” or “hot reloading” on in the simulator; shadow-cljs uses a different mechanism for live reloading.
ok good to know, it's a new territory for me, I'll pop up some questions after digging trough your code 🙂 thanks again
Sure but remember that my code is needlessly complicated if you’re not using React Native Navigation…
@hlolli the "complicated" bit was only that react-native wants a react component class registered as the root
with a bit of hackery it is easy to overcome though. see https://github.com/thheller/reagent-react-native/blob/master/src/main/test/app.cljs#L33-L59
do you enable something in the simulator, because I'm using this code character by character, and a nested compinent isn't updating, except via CMD+R
(defn root []
[:> rn/View {:style (.-container styles)}
[:> rn/Text {:style (.-title styles)} "Hello!"]
[:> rn/Image {:source splash-img :style {:width 200 :height 200}}]])
there were same caveats with the react-native-router, going to look better at the repo which @stefan.van.den.oord sent me
its basically the same code I used for expo https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/expo.cljs
I wonder if that will get better soon. I know the RN team is working on a re-architecture and supporting more modern React development practices
I was never quite happy with react but told myself that the value of react is in the ecosystem not react itself
well ... its changing everything and is even for unfriendly for CLJS than components were
can't change equality semantics of the inputs check so forever doomed to work around it
can't use hooks within components either so have to replace everything with something new
of course thats not something you should ever do if you actually care about 3rd party react components
but I started building a new app and tried to do so with hooks and I don't like the experience one bit
that’s the fun bit. I think there’s plenty of places to explore outside of the React model
Svelte, Ember, Phoenix LiveView are all things I’m watching. it would be interesting to explore those in a CLJ(S) way.
if we could leverage more static analysis of CLJS code it would be pretty cool to see the kind of compile-time tricks we could play with it
right. we have the tool chain built into the language. seems like we should be able to leverage that far better than the JS ecosystem
yes, ReactElements are annoying because you can’t extend them without extending js/Object
no idea if that’s what you’re talking about, but I just remember running into issues when I first started building hx since I wanted to build it using only protocols. funnily, the lack of OO-ness in React internals bites us
plus I wanted to do weird things like datafy and nav React elements, React components
I’m also curious, the dislike of the Hooks experience: was that using hx? anything in particular you didn’t like other than the equality semantics?
but this one seems different enough and so far is more promising than all other attempts combined
hahaha. well, I’m just interested in trying to get outside of my React box in general
but the protocol thing seems worth talking about as a concept for react alternatives in CLJS
I kinda realized after debating with yogthos for the billionth time about React that maybe I need to chill and take a wider view of what’s out there
(defprotocol IConstruct
(as-managed [this env]))
(defprotocol IManageNodes
(dom-insert [this parent anchor])
(dom-first [this]))
(defprotocol IUpdatable
(supports? [this next])
(dom-sync! [this next]))
angular was a whole-app thing. class components and react hooks can live side-by-side in the project
hm. I would move it into context, and then each component can consume it in whatever way is best
I see your point that it makes it so that you essentially split your development paths: one API for class components, one API for hooks
I was moving to React after angular v1.4 and saw the explosion in my rear-view mirror 😎
yeah maybe I exaggerated a bit ... still to me it felt like writing in a new fragmework
😄 yes. there are pros and cons to returning a closure (like reagent does) vs creating the closure implicitly like React does
I ended up creating a useValue
hook that handles clojure equality for things like deps, but in practice I haven’t used it. https://github.com/Lokeh/hx/blob/master/src/hx/hooks.cljs#L108
the nice thing is since we have hicchup as a basis switching between frameworks doesn't mean throwing away your entire HTML 🙂
but yeah, IMO the inputs deps are the wrong place to optimize. I think we want to optimize by memoizing components and efficient state updates. if you maintain referential identity (e.g. aren’t passing in literals every render) then you can take advantage of the tools the same way JS React does
(let [ev-handler (react/useMemo #(handle-some-event clojure-data) #js [clojure-data])] ...)
that depends. if you’re re-creating the clojure data on every render, then yes it’s not going to memoize correctly
in my experience, I’m usually depending on something that is in useState
or a callback function
the former case, identical?
works great. the latter case, there’s useCallback
(gross but it’s a solution)
I think it’s kind of annoying in that it is making us all think about how to leverage immutability again
we had it kinda figured out with class components + sCU, and reagent and Om went a long way to covering it up (for me at least)
now we gotta figure it out again. and it’s kinda turning out that it’s more about following React idioms than using actual immutable data
I think that even if we could customize the equality, that we would find out that all the places where we were doing deep equality of clojure data would be a bottleneck as well and end up optimizing it the same way we are now 😛
so just things like const props = useSpring({opacity: 1, from: {opacity: 0}})
already suck