This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-08
Channels
- # admin-announcements (7)
- # aws (5)
- # beginners (37)
- # boot (39)
- # cider (4)
- # clara (2)
- # cljs-dev (32)
- # cljsjs (1)
- # cljsrn (12)
- # clojure (235)
- # clojure-austin (3)
- # clojure-belgium (7)
- # clojure-berlin (11)
- # clojure-dev (36)
- # clojure-france (10)
- # clojure-japan (10)
- # clojure-poland (2)
- # clojure-russia (39)
- # clojure-uk (4)
- # clojurescript (81)
- # code-reviews (9)
- # core-async (6)
- # core-logic (1)
- # datomic (32)
- # editors (7)
- # emacs (1)
- # hoplon (191)
- # jobs-discuss (14)
- # juxt (4)
- # lein-figwheel (4)
- # leiningen (3)
- # off-topic (7)
- # om (49)
- # onyx (34)
- # other-lisps (1)
- # overtone (11)
- # parinfer (1)
- # proton (5)
- # re-frame (11)
- # reagent (12)
- # spacemacs (2)
- # untangled (90)
- # yada (15)
I have two sibling components with :keyfn (and data-reactid and (.. c .-_reactInternalInstance .-_currentElement .-_key)
look good). after some mutations, one renders the props of the other. looking at the actual component instances, (.-props c) is good, but (.-state c) for the first instance has the second's data
I guess that patch might be unacceptable, though, because we don't want to rerender everything if a list is reordered?
Just noticed something I don't quite understand:
Some component renders twice after a mutation, although componentWillReceiveProps
only fires once.
First render after a mutation: rendering App with props: {:x {:x/prop "test"}, :app {:app/title App!}}
Second render after a mutation: rendering App with props: {:app {:app/title App!}}
The query of component App
is [:app/title]
, notice the props {:x {:x/prop "test}
come from the query on the component above App
Why do the props get modified? i.e. why is the {:x {:x/prop "test}
removed after a mutation, and available on an initial render?
@kendall.buchanan: That's actually the opposite of normalization. Normalization is making everything table-y and related by some kind of id (in this case, with idents)
Then, you resolve those idents on the way out to your components, so they see the data as deeply nested graphs (and in a form that matches their queries)
That way your components get nested data in a form that lets them pass pieces of that data to subcomponents, but the data store keeps each piece of data in a single place, so any change is consistent
@peeja, right, so if I understand correctly, the goal is to let your components deal with the data in a non table-y way, while keeping normalization stable within the app state...
I suppose what I don’t fully understand is this: why is om.next taking this job upon itself? redux, flux, re-frame, etc. let the component framework be just that: rendering components. Is om.next basically saying there’s an inherent coupling that must be met?
Om Next is largely concerned with giving components the power to ask for the data they need
Okay, cool, thanks. Not to drop too many tool names, but it’s trying to solve the same problem Relay is?
Components need to ask for data in a form that doesn't make sense for storage (because it's not normalized), so it does this transformation
Right, it indexes it.
And the parser system (`read` and mutate
) is really flexible, so a lot of what's seen as things that Om "does" is really the patterns that Om expects you to probably use
It’ll be interesting to see if Om.next sticks – not to be a pessimist – it’s learning curve is significant, but it feels like it’s working towards a solution at all the right problems.
Thanks for the help.
@anmonteiro: so have you been working quite a bit with your branch with the query stuff.
also would be nice to hear from people about their code bases with this PR merged https://github.com/omcljs/om/pull/633
@dnolen: I've been working off of it in a few projects, yes, nothing to report so far
@anmonteiro: wow ok cool
I suppose I should just make something with more hardcore dynamic queries just to test the limits
I'll see if I have time over the weekend
I'd definitely be interested in hearing people's feedback with that branch
@dnolen: I'm thinking that once that's merged in, we should think about putting queries somewhere other than the app state
to provide people that are using DataScript a way to change queries
I had made some notes on the om source code for my own understanding, and I think they could just be placed in the reconciler's state.
for looking up by id — use [{[:user/by-id 1] [:user/name]}]
or [({:user/by-id [:user/name]} {:id 1})]
(I might have the syntax wrong on the param one ;p)
Another noob q, probably simple: I’m noticing a lot of syntax quoting going on in queries, but finding seemingly identical queries without quoting. I can see where it helps with params, but why might I quote something basic like this ’[:user/count]
?
K, makes sense.
@iwankaramazow: for 'extra stuff' in the props, you should use om/computed