This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-13
Channels
- # aws-lambda (7)
- # beginners (80)
- # boot (134)
- # cider (11)
- # cljs-dev (5)
- # cljsjs (3)
- # cljsrn (19)
- # clojure (144)
- # clojure-austin (2)
- # clojure-berlin (3)
- # clojure-greece (6)
- # clojure-italy (3)
- # clojure-russia (95)
- # clojure-spec (57)
- # clojure-uk (120)
- # clojure-za (2)
- # clojurescript (71)
- # component (1)
- # css (1)
- # cursive (22)
- # datascript (2)
- # datomic (101)
- # dirac (9)
- # docker (3)
- # emacs (10)
- # events (2)
- # immutant (3)
- # leiningen (2)
- # om (63)
- # om-next (1)
- # onyx (6)
- # pedestal (55)
- # portland-or (3)
- # protorepl (2)
- # re-frame (30)
- # reagent (10)
- # ring-swagger (1)
- # rum (31)
- # spacemacs (5)
- # specter (9)
- # untangled (90)
- # vim (46)
- # yada (2)
hey all I’ve had some pretty long-term musings about React/om-next if anyone has 3 min to chat I’d love to get some feedback 🙂
I’ve been using React+om for like 2+ years now and somehow I still haven’t figured out 1 thing and I’m just wondering if I’m missing something super obvious
it boils down to this: is a parent component “required” to pass all the props to a child component that the child component needs?
from I understand: no, it does not BUT… it always seems to create one subtle problem for me - the fact that on the first render, the prop that isn’t passed from the parent down to the child is nil (basically not there)
so I’m just wondering if this is just not recommended, or I’m missing something obvious
Right! There's a caveat in using a javascript object mounted on an html page and that is ... your component structure has to look like nested DOM elements... much like html... So the "root" component effectively holds all the other components.
this is not a critical problem in some cases, or even most of the time, but sometimes it creates subtle animation/user experience issues
The way Om.next works, there's a reconciler that keeps track of stuff, but the way it keeps track of stuff is basically by asking the root of the tree "hey yo what all do you want to keep track of while the app is running?"
right, yes, I’ve been using Om.next for almost a year now (I’m using it via React Native, but it’s all pretty much the same)
Cool. Yeah so that's what I'm confident about so far. I'm pretty new in comparison. You were wondering about why they are nil
if you don't ask for them at the root element?
Interesting.
Have you tried including all the elements you query about ... from the root element "downward" to the asking component?
It's cool you notice that. I wonder if it makes your UI code look a lot cleaner just having them in the spots you want and not all-the-way-down
Because it seems like a pre-render step could be in order, to just go through the whole potential component Ui and just make its own tree that is more-or-less invisible to the coder...
then you effectively have to structure your data around how the UI render tree is built
Right . Hrm . Well that is a nice thing to have for verifiability of rendering and stuff... yes I see what you mean about readability.
Ah, like have fewer (but more deeply HTML-nested) components... yes..
I think for most applications a shallow UI tree is what one aims for. Or at least balance (and if possible elegance) in the breakdown
yeah man. i like where you're going with that. there's probably a way to pre-render all that ... and then just not worry about making your data tree grow along your UI tree .. ttyl
hey everyone, i made some progress on the issue i had yesterday regarding chaining remote queries so that the result of the first query can be used as the parameter to the next query. as @hlolli recommended, i used componentWillUpdate to catch the results of the first query, and then used set-query! to update the params for the next query. it fetches the proper data! however, since i am calling set-query! in componentWillUpdate, i believe set-state is called in react, which leads to an infinite loop because componentWillUpdate keeps getting called. anyone know a way around this?
i also tried to use componentWillReceiveProps but that causes an infinite loop too because props are being passed in after each query.
@azzikid yes you need to watch out for the logic, componentWillUpdate gets called many many times. So you need to set the query only on conditions that statisfy what you need. To help you with that you have last-props and last-state that you can compare to the next state/props. So if you are seeing changes in 1 value from 1 update to next, then start the query.
also try componentDidUpdate, it gets only called once while componentWillUpdate gets called twice, at least as far as I see.
I have some components whose queries depend on attributes of the logged in user. I'm passing user to them as a computed property and trying to access user in IQueryParams to initialize the query parameters. IQueryParams is called several times, the first few times with user: nil. I'm not sure if this is a valid pattern, or what I should be doing instead?
It seems to work, except on the first load, because I initialize the properties with user: nil and they're incorrect.
It's strange because componentDidUpdate gets called with the correct params and I update the url with the correct params....but it doesn't seem to be re-rendering wth them
Basically, it seems like the query is sent when IQueryParams is first called (with user nil) but by the time I receive the new props, it has been called again and params have been updated correctly
i am trying to use set-query!
on a component that is not "this" component but am getting the error: Uncaught error: Assert failed: (or (reconciler? x) (component? x))
@tmulvaney i actually tried that and got the same error 😞
an instance is either this
or reconciler. A trick worth noting is that you can pass down this
as properties of a child. It has some caveats to is.
@azzikid I have tried creating the component first then set the query, ex:
(let [sc (section {})] (om/set-query! sc [:a :b]))
(defui View
static om/IQueryParams
(params [this]
{:activeq {:startkey "active-data"
:endkey "active-data"
:include_docs true}
:sectionsq {}})
static om/IQuery
(query [this]
[:app/learn
'({:learn/active [*]} ?activeq)
'({:learn/sections [*]} ?sectionsq)])
any reason why that query would only call the read method for :learn/active but not for :learn/sections? they are both remote if that matters.
i want all three queries (:app/learn, :learn/active, :learn/sections) called. they are all top-level in my state.
@azzikid your query definition is wrong in specifying parameter => '({:learn/active [*]} {:activeq ?activeq})
@danielstockton I was just talking with @raspasov about this very issue. It will eventually render but the first pass through is nil, presumably because whatever query you want to do doesn't do the walk all the way from the root component to the asking component (meaning one would need that query piece in the root component and every component that nests around your asking component). Not having it there will still render the data, but it is nil
on the first pass-thru ... is my understanding thusfar
I have an interesting issue: when I use set-query! to set a parameter inside of componentWillUpdate (based upon the next-state), it triggers a parser read and hits remote if necessary. When remote is hit, parser is re-read again and merged into app-state, however, this time the parameter is missing from the query...anyone else have this issue?