Fork me on GitHub
#om
<
2017-07-03
>
wilkerlucio12:07:35

hello people, I would like to announce a new little open-source project I built with Om.next + Untangled, it's a Chrome extension to represent an Youtube Queue based your emails, I made a post about it, I hope you can enjoy it 🙂 https://medium.com/@wilkerlucio/using-gmail-messages-to-track-youtube-channels-ef35308a0ceb

samcf16:07:42

Something I don't see in om.next projects are deeply nested component hierarchies... where the leafs have unpredictable data needs. Are there any examples of that?

wilkerlucio16:07:29

@samcf what you mean by unpredictable data needs?

samcf17:07:10

@wilkerlucio ex. Component A has child Component B which has child Component C, and some feature requirement changes where C needs some data it hadn't anticipated... how do I change C's query to get some data that is at the root of the state map?

peeja17:07:05

@samcf You're talking about at dev time, not at run time?

samcf17:07:42

@peeja Right, trying to change C's query in a way that doesn't necessitate changing A and B

samcf17:07:03

@sundarj I've read it a few times... maybe I haven't grokked it

sundarj17:07:36

the way i see it is, it lets you get an item out of the root state without having to go through all the parent components beforehand

sundarj17:07:43

which seems to be what you're asking for

peeja17:07:01

My gut reaction is that your component hierarchy or your graph may be flawed. You can get back to the root using a singleton link from anywhere, but it's often (in my experience) a smell

peeja17:07:37

If component C represents "a C" in your domain model, why would it need props which don't belong to the C it's representing?

sundarj17:07:09

so if C needs access to :key in the state, you can get at it by plonking [:key _] into the query

samcf17:07:13

@sundarj hmm I will try that! If that works then that's exactly what I needed. @peeja for example, in toy app, https://github.com/samcf/sojourner/blob/master/src/sojourner/ui.cljs#L43 this component needs some data (the current time in milliseconds) that doesn't necessarily "belong" to the component.

peeja17:07:52

Ah, I'd call that a mistake: the current time shouldn't be a prop

peeja17:07:00

Or rather, it shouldn't be part of your data model

peeja17:07:41

The source of truth for the current time shouldn't be your "database", it should be the clock on the wall

samcf17:07:49

the current time is part of the model, since the app is a simulation which may run at different speeds, etc...

peeja17:07:00

Oh! Gotcha. That's different, then. 🙂

peeja17:07:41

In this case, I might pass the current time to the Game as a computed prop

peeja17:07:10

That is, you're asking the Game component to render a game (with all the data it needs about a game) as if the current time were X

peeja17:07:32

and it's the RootView's responsibility to decide on the X by querying for it in the app state

samcf17:07:33

Now let's imagine Game is 10 components deep into the UI tree... either I have to fix my component tree or pass it all the way down (or use [:current-time _] as suggested)

peeja17:07:39

Using a singleton ident to jump back to the root of the graph to look it up works too, but using a computed prop would keep the component a bit more modular, as it wouldn't have to know about the structure of the graph at the root

peeja17:07:18

Yep, that's correct. It's a tradeoff, and I think either way is defensible. It depends on context.

peeja17:07:32

and the reasoning's a bit fuzzy either way 🙂

samcf17:07:41

👍 this has been informative

peeja17:07:05

BTW, it looks like RootView is using query params which don't actually change. Is that right?

samcf17:07:38

yeah that's right, it just looked neat when I had it that way, but its unnecessary

samcf17:07:00

still learning/toying around

peeja17:07:01

Cool. Just wanted to make sure you knew it wasn't necessary