Fork me on GitHub
#om
<
2016-04-08
>
tomjack00:04:46

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

tomjack00:04:06

this sound familiar? trying to extract the bug into a smaller example

tomjack00:04:59

oh, hmm. they have the same om/path

tomjack01:04:51

metadata is weird simple_smile

tomjack02:04:32

I guess that patch might be unacceptable, though, because we don't want to rerender everything if a list is reordered?

tomjack02:04:25

well, :pathopt true is a workaround for now if the affected components have Ident simple_smile

iwankaramazow08:04:20

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?

hlolli11:04:47

react15, now all svg functions supported. Look forward for this in om.next simple_smile

peeja14:04:17

@kendall.buchanan: That's actually the opposite of normalization. simple_smile Normalization is making everything table-y and related by some kind of id (in this case, with idents)

peeja14:04:08

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)

peeja14:04:15

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

kendall.buchanan15:04:04

@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...

kendall.buchanan15:04:49

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?

peeja15:04:05

Om Next is largely concerned with giving components the power to ask for the data they need

peeja15:04:26

So most of this is in the service of making that possible

kendall.buchanan15:04:10

Okay, cool, thanks. Not to drop too many tool names, but it’s trying to solve the same problem Relay is?

peeja15:04:14

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

peeja15:04:20

That's exactly right

peeja15:04:36

Although, to be clear, Om doesn't really do normalization

peeja15:04:45

Or rather, it can, but often you do it yourself

kendall.buchanan15:04:45

Right, it indexes it.

peeja15:04:58

That's right.

peeja15:04:38

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

kendall.buchanan15:04:50

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.

kendall.buchanan15:04:06

Thanks for the help.

peeja15:04:13

Sure thing!

dnolen20:04:04

@anmonteiro: so have you been working quite a bit with your branch with the query stuff.

dnolen20:04:19

I’m seriously considering just merging it in the next few days

dnolen20:04:51

also would be nice to hear from people about their code bases with this PR merged https://github.com/omcljs/om/pull/633

anmonteiro20:04:18

@dnolen: I've been working off of it in a few projects, yes, nothing to report so far

anmonteiro20:04:50

I suppose I should just make something with more hardcore dynamic queries just to test the limits

anmonteiro20:04:02

I'll see if I have time over the weekend

anmonteiro20:04:40

I'd definitely be interested in hearing people's feedback with that branch

anmonteiro20:04:02

@dnolen: I'm thinking that once that's merged in, we should think about putting queries somewhere other than the app state

anmonteiro20:04:20

to provide people that are using DataScript a way to change queries

dnolen20:04:31

agreed - will think about that

taylor.sando20:04:02

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.

tomjack20:04:34

managed to reproduce my "bug" (?) as a bugs.cljs devcard

tomjack20:04:21

to see the bug, unfollow alice, then follow alice

tomjack20:04:36

it turns out it's important that the [:app/user :user/id] is the same as bob

tomjack20:04:55

this made it difficult to reproduce. maybe I can diagnose given this..

hueyp21:04:54

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)

kendall.buchanan22:04:35

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]?

cjmurphy22:04:50

Sometimes they are just put in from habit I believe.

tomjack23:04:50

@iwankaramazow: for 'extra stuff' in the props, you should use om/computed

tomjack23:04:27

see default-ui->props and Reconciler's reconcile! in the source for an explanation, I guess simple_smile