Clojurians Log v2

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

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?

@samcf what you mean by unpredictable data needs?

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

https://github.com/omcljs/om/wiki/Thinking-With-Links%21 does this explain what you mean?

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

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

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

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

which seems to be what you're asking for

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

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?

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

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

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

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

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

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

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

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

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

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

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)

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

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

and the reasoning's a bit fuzzy either way 🙂

👍 this has been informative

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

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

still learning/toying around

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