specifying local data queries as static properties about react-redux

[gaearon]

Do I understand correctly that the main difference is “put it in statics” vs “put it in a parameter to connect call”?

I'm a bit wary of putting anything in statics because different libs have different wrappers and as soon as you combine them, some statics won't be copied over, and it's a pain. This is why I prefer to put these things into a parameter.

Am I missing something?

[jlongster]

Yep, as I mentioned cosmetically it's not too different from a parameter to connect. But the main difference is that you always export a "connected" component, i.e. you never have to separate smart/dumb components. Also I simply find it really intuitive to read the data dependencies of a component at the top of it.

I think there are several solutions to the smart/dumb problem, where you can still treat a "smart" component as a dumb one if needed (just give it some props and render it!).

With statics, I have the option to use react-router, traverse the components needed for a page, gather up data dependencies and actually tell the reducers to fetch it. This is very much like Relay, but a lot more dumb and useful for apps that just need simple data queries.

Also, Relay uses static props. I think we're going to see widespread usage of this pattern once Relay comes out. If a wrapper is supposed to copy static properties and it doesn't, that's a bug.

But also like I said, I'm perfectly happy writing this as a separate project, no changes needed here. Feel free to close the bug! I'll probably blog about it too. There's room for multiple solutions.

[phated]

@jlongster Relay no longer uses static props, but instead pass a 2nd argument to their createContainer API that contains the queries. Let me find the blog post that shows this...

[phated]

@jlongster blog post with the newest API reference I've seen http://facebook.github.io/react/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html

[jlongster]

@phated ah I had missed that! thanks. I really liked the statics approach, but maybe the disadvantages are stronger than I first thought.

It appears that those properties are still available statically on components though. The Story component in that article has a getQuery method, so you can just say Story.getQuery('story') to get that query for the Story component. This is needed for server-side rendering (and is just interesting for debugging).

It's possible they steered away from statics thought so that the can separate smart/dumb components. If you are using static properties, I don't see why you need to do that if you just make the dump component accessible on the dumb static property.

So anyway, I don't know what react-redux might learn from this but I'll probably just experiment outside of it for now and blog about it.

[phated]

@jlongster yeah, their higher-order component produced by Relay.createContainer has a few statics so they can traverse the tree, but I think they are straying away from statics on the underlying components. I've been experimenting with an API similar to the linked Relay API over at https://github.com/iceddev/sovereign but I also want a different API that allows handlers (very similar to your actions and namedActions) to be passed in but be outside the re-render path.

[jlongster]

Neat! I'll ask them more about static props. All of this isn't really that different from what react-redux does right now. Main consideration is if dumb/smart components should really be in separate files (I'm trying to think of a reason they should be), and enabling arbitrary query languages (which is more appropriate for other react interfaces to redux).

[phated]

I have been experimenting with the difference between dumb/smart components in an application we are working on. So far, I actually like to call them Stateless Components and Views. Stateless Components can be dropped into something like https://github.com/skidding/cosmos for viewing, demos, etc and Views are components that are wrapped in sovereign or react-redux/connect and pass stateful data to the Stateless Components that make up its render method. I have also been told the View could be called a Controller Component but I don't know how I feel about that.

[josephsavona]

@jlongster Relay originally used statics + a mixin, but we moved to HOCs for a few reasons. Our goal was to have dumb components receive their data as props, but that meant one of two options:

• The component somehow resolves its own data and updates its own props (an anti-pattern in React). Re-rendering requires using private APIs (because you can't just setState).
• Have some parent component intercepts the props, merge the results of the queries, and pass the merged props to the component. It can also subscribe for data changes and re-render when necessary.

Option 1 requires reaching into React internals and will not be supported going forward. It also complicates the component itself with subscription logic. The only option is for the parent to pass the data in. Without a HOC - if you just use components with static properties - every component would have to resolve all the data for its children and keep them updated. Components become much more complicated to reason about, because for example <Feed> has to handle its own logic, as well as the logic to update all of the <Story>s that it composes whenever their data changes. In short, dumb components get really complicated.

HOCs allow removing this complex, async data-resolution logic and state-machinery from the dumb components, making them much easier to reason about and test.

Another advantage is each type of component will always receive the same type of data:

• smart components receive a "pointer" (ex: which story to render, perhaps just an id)
• dumb components receive data (ex: the story data as query(id))

For Relay specifically, we typically have one file per component with the following:

1. require statements
2. dumb component (render + event handling)
3. container (queries)
4. styles (eg in React Native)

[jlongster]

@josephsavona thanks for much for explaining! to be clear, I'm not advocating for not using a HOC. In fact my current approach does this: https://github.com/jlongster/redux-experiments/blob/master/static-queries/connect.js#L13. connect returns a new component. The difference is I pick off the query from the static property of the dumb component. The dumb component doesn't have to do anything else, it just uses props, so if it's rendered from a smart component it will be live data, otherwise it's just props. Basically: I use static props but not a mixin.

However, it seems like everyone is moving towards declaring the queries outside the component, so I'll probably just do that then. :)

I'm glad to hear you still use one file per component; what I wouldn't want to do is declare a dumb component is one place and a smart one in another file. Do you only export the container? If so, how do you access the dumb component if you want it (for testing or something)?

[josephsavona]

@jlongster gotcha, that makes sense. It definitely seems like the choice of using a static property or an argument to the HOC function is just a matter of preference.

It's up to developers what they want to export - just the container or both - though we typically export only the container.

[phated]

@jlongster @josephsavona I would think you could mock the createContainer method to just return the dumb component for testing

[jlongster]

Yep! I actually stuck the dumb component as a static property: https://github.com/jlongster/redux-experiments/blob/master/static-queries/connect.js#L15 but mocking may be better.

Thanks for talking this through folks, I learned a lot. I'm going to close this issue because I think the things I want to do now don't really affect anything in react-redux, as I'm interested in some basic data fetching on top of the select-style stuff.

[gaearon]

Thanks for talking this through here anyway! (And feel free to come back with more ideas.)