This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-30
Channels
- # aleph (1)
- # beginners (126)
- # cider (2)
- # clara (38)
- # cljsrn (2)
- # clojars (2)
- # clojure (49)
- # clojure-dev (31)
- # clojure-dusseldorf (1)
- # clojure-finland (1)
- # clojure-france (6)
- # clojure-italy (13)
- # clojure-nl (12)
- # clojure-russia (9)
- # clojure-sg (1)
- # clojure-spec (33)
- # clojure-uk (83)
- # clojurescript (206)
- # community-development (3)
- # core-async (40)
- # cursive (4)
- # datomic (7)
- # duct (21)
- # emacs (9)
- # fulcro (36)
- # funcool (2)
- # graphql (12)
- # instaparse (4)
- # jobs (4)
- # lumo (24)
- # mount (1)
- # nyc (4)
- # off-topic (29)
- # onyx (1)
- # pedestal (2)
- # random (4)
- # re-frame (60)
- # reagent (136)
- # remote-jobs (1)
- # schema (1)
- # shadow-cljs (20)
- # spacemacs (6)
- # specter (14)
- # tools-deps (2)
How do I point a cursor to the result of a function instead of a property. I have a javsacript Date object and I want a cursor pointing to each of their time components.
I have a colleague who is working with Reagent for the first time. We are using the ‘react-select’ component: https://github.com/JedWatson/react-select
He needs to override the optionComponent
, and I’m trying to figure out how to do that.
When I return a basic reagent component for that property, I get A valid React element (or null) must be returned
Do I need some magic combination of adapt-react-class
and/or reactify-component
? I’ve not used these before….
@theeternalpulse I don't think you can have a cursor point to the result of a function. A cursor can just access a nested map by their keys. I think you'll have to have the date object be returned by the cursor ... And then with that, use helper functions to access whatever you want.
Here is an example of a custom rendered option component from the docs: https://github.com/JedWatson/react-select/blob/master/examples/src/components/CustomComponents.js
@jmckitrick have you read through https://github.com/reagent-project/reagent/blob/master/doc/InteropWithReact.md
I didn’t know that existed, actually.
you'll need something like #(r/as-element [:div ...])
Only the basic reagent page
the “valid react component” error is because you’ve returned a function or a hiccup rather than a react component
I’ll try it.
Hmm. Same error.
@pesterhazy why the #
--won’t that return a function?
right, I assumed that it expected a component
but maybe that's not the case
Wait! It worked
I had to move some things around…
Let me read that guide now….
@zach.phillips-gary this is what we need
one problem with react documentation is that it isn’t precise with the words “element” and “component” because the JSX makes it magically work
@jmckitrick if there is a pattern in there that isn’t covered let me know
maybe an example of a popular react library (like react-select) would help
So the docs for react-select, as well as the example we wanted to emulate, both refer to optionComponent
prop as a React class.
But @lee.justin.m the docs you linked me to say the as-element
solution is for components expecting a function.
So I’m still confused 😕
For the record, we have react-select working great with the existing reagent import and shadow-cljs setup. But the customization is bringing new challenges.
a function can be a React component ("functional components")
that’s interesting that it worked. i might have expected it to take the result of reactify-component
actually
in that case you're basically short-circuiting Reagent
reactify-component should work as well (and give you Reagent-style access to the props)
@lee.justin.m that’s the route I was going, actually.
Let me try again….
@jmckitrick if you want to help improve the docs you could contribute an example for react-select
I’d be happy to!
even just putting it up as a gist would be helpful
Once I understand why this works the way it does.
the other thing that makes this confusing as hell is that both reagent and react do certain kinds of conversions for you which makes it hard to form a mental model
PR for the docs folder is even better
reactify-component
did not work, while as-element
did
can you show the code?
Definitely.
Is here ok?
sure (as a code snippet)
(defn react-select-component []
[:div {:style {:width "40%"}}
;; Syntax sugar for NPM components.
[:> (.-default react-select)
{:name "form-field-name"
:value @(rf/subscribe [:subs/selected-destination])
:onChange #(rf/dispatch [:events/select-destination %])
:optionComponent my-custom-renderer
:multi true
:simpleValue true
:options @(rf/subscribe [:subs/destination-data])}]
[dl-button-component]])
and then
(defn my-custom-renderer [args]
(reagent/as-element
[:div "foo"]))
does this work?
(defn my-custom-renderer* [args]
[:div "foo"])
(def my-custom-renderer (r/reactify-component my-custom-renderer*))
Let me try… oh, and I found in those interop docs a part that more accurately describes the use case… Creating React Elements from Hiccup Forms
because since this component displays options, it’s displaying children.
Let me try your idea, @pesterhazy
Yes, it works!
But it didn’t work when I used reactify-component
inside the component function like as-element
Yeah that's not how it's supposed to be used
Ah, ok.
It takes a Reagent component function (fn returning hiccup) and transforms it into something digestible by vanilla React
So I had it between the fn and hiccup, rather than around them both.
Also using defs helps avoid re-renders
This is my first foray into interop beyond [:> foo-component]
Yeah it's not rocket science, but the docs still don't cover everything
I actually missed that detail
The good news is anything you can do with React, you can do with Reagent as well
I knew that was the case, but had to convince a colleague we could find the answer in a reasonable time 😉
Fortunately, the support here is fantastic.
Is there something I can contribute to the docs to ‘give back’ in some way?
Or was this just an error on my part, rather than a needed clarification?
A section on how to apply the "customize renderer" pattern in Reagent would be great IMO
In the interop guide?
Like optionComponent
This pattern comes up in many React (and ReactNative) libs
Yeah there, or maybe add an Advanced Usage section. What do you think @lee.justin.m?
It's linked in the readme, but maybe not prominently enough
This page generated by @martinklepsch's cljdoc seems better: https://cljdoc.xyz/d/reagent/reagent/0.8.1/doc/documentation-index/
very nice
Once the dust settles we might link there in the Readme maybe
@pesterhazy I was just talking to @martinklepsch about why his version renders so much better than http://reagent-project.github.io/docs/master/
The cljdoc API docs for Reagent are better than what we currently have
They include source links for example (super useful)
@juhoteperi recently added https://github.com/reagent-project/reagent/blob/master/doc/cljdoc.edn but it still renders terribly on the reagent homepage
Although the cljdoc page should also link to Dan's NEWS style blog posts like http://reagent-project.github.io/news/news051.html
before we do that though we need to fix the docstrings to be in markdown. right now they are plaintext and assume the rendering will be monospace, which cljdoc doesn’t do yet
They include crucial information as well
Oh yeah?
That's fantastic
I’m considering adding the ability to hide items in the sidebar so you could have a news page that links to the various individual posts…
We may want to rename the /docs mds from Tutorials to just Docs or Guide
I definitely had it all in a single document. @mikethompson wanted to keep the docs separate so @gadfly361 merged it, but I think 90% of that stuff made it in
Tutorial isn't really the right word for documentation explaining essentials
cljdoc kind of solves the problem of separate vs. unified for us so that’s super convenient
Yeah it feels like a better entry point for new users
What I'm missing is a short abstract of what Reagent actually is
my original intent was to have something in between “tutorial” and “docstring”: something like a definitive user manual that more completely describes reagent’s rather complicated mechanisms.
this was the way I laid it out: https://gist.github.com/jmlsf/17c588deb326e538dcea6847bc66db9b
Why not just call it what it is, a User Guide?
the questions have been: where does it go? how is it going to be formatted? how do we deal with mike’s more tutorial-like documentation vs. more formal and complete descriptions?
I meant just renaming what we already have to User Guide
The docs Mike and you contributed from a great basis to start from
We can always improve things from there
right now there’s literally no place to title it because it’s spread out over a bunch of docs. (in my gist I had it in a single file titled “Reagent User Manual” with a TOC.) if we were to move to cljdoc and get that all formatted nicely, then it will be obvious: all of the “guides” will be at the top and then you can drill down into the docstrings.
right
if I want to coordinate a join between two http requests, what's the best way to do that with ratoms? I get some timeseries info from one API, then need to look up some dimension values in another API … just chain a bunch of ratoms together with track
?
@hagmonk You mean, how do you coordinate issuing a second http request once the first has returned?
yeah so the situation is I get some results back from one API, then to look up people's names I need to hit a second API … then join both results together, and likely put it in a third ratom (or cursor). I'm just wondering what the "reagent-y" way of doing this is
i mean, i would definitely not use ratoms for coordinating asynchronous communication. the problem with doing that is that shit will just start happening and you’ll have no idea why. best to use ratoms for one thing: triggering re-renders
if you need to coordinate multiple http calls, I would recommend using a promise-based solution. core.async would work too, though I personally am not a fan
that is super helpful to know, the boundaries around ratoms, the "hey don't do that with ratoms" moments, aren't yet clear to me
(I reach for core.async on the server a lot but only when the fiddleyness justifies it)
i personally think the observer pattern is really neat, but it is also dangerous because it gets rid of predictable stack traces and runs the risk of shearing cause and effect. in other words, some handler changes a data value, then a bunch of magic happens, and then some watching code fires. it can be very hard to work backwards from that if it goes wrong.
core.async has too much complexity and much of it is really geared to solving multithreading problems, in my opinion. it also does not handle exceptions in a developer friendly way. I now use the promesa
library with cljs-ajax
. it’s simple and predictable. you just do (-> (first-request) (then (fn [result] do-next-thing)) (catch (fn [error] ...))
I'm trying to settle on a frontend/backend stack that plays well together … it seems like the "fancy" pipework is to do it all over websockets with sente or something, but my backend preference is pedestal + jetty
if you’re going to use websockets you can use promises there too. you just need some websocket client that gives you a place to put callbacks. then you just stick resolve
and reject
from promesa/promise
there and boom you are in the promise land
i’d like to use websockets at some point to but i’m sticking to good ol’ post until i have time to deal with that
yeah I can't really justify it until I'm trickling updates into the frontend, which isn't very high on my feature list
(def grid (r/adapt-react-class Grid))
[grid {:container true}
"foo]
;; I want to create grid-container which do something like that
(def grid-container [grid #(merge {:container true} %)])
;; So I could use it in that way to not write each time :container true
[grid-container {:style {:background-color "red"}}]
How can I achieve it?It is exactly about https://material-ui.com/layout/grid/