Alternative API proposals

[gaearon]

This API is taken from Redux <Provider>, <Connector>, @provide, @connect.
Right now I don't have examples in this repo but it matches what you've seen in Redux so far.

It's the best we've got now, but I think we can do better!

Common pain points:

• Not intuitive how way to separate smart and dumb components with <Connector>, @connect
• You have to manually bind action creators with bindActionCreators helper which some don't like
• Too much nesting for small examples (<Provider>, <Connector> both need function children)

Let's go wild here. Post your alternative API suggestions.

They should satisfy the following criteria:

• Some component at the root must hold the store instance. (Akin to <Provider>)
• It should be possible to connect to state no matter how deep in the tree
• It should be possible to select the state you're interested in with a select function
• Smart / dumb components separation needs to be encouraged
• There should be one obvious way to separate smart / dumb components
• It should be obvious how to turn your functions into action creators
• Smart components should probably be able to react to updates to the state in componentDidUpdate
• Smart components' select function needs to be able to take their props into account
• Smart component should be able to do something before/after dumb component dispatches an action
• We should have shouldComponentUpdate wherever we can

[gaearon]

For example, we could drop <Connector> altogether and encourage people to use @connect decorator as a function in another module.

Common case

A dumb component would look exactly as it does now.
A smart component would look like

import React from 'react';
import { connect } from 'react-redux';
import Counter from '../components/Counter';
import * as CounterActions from '../actions/CounterActions';

export default connect(
  state => ({
    counter: state.counter
  }),
  dispatch => ({
    increment: dispatch(CounterActions.increment()),
    decrement: dispatch(CounterActions.decrement())
  })
)(Counter);

Note that the smart component doesn't have to be declared as a component. Also note that state => ... and dispatch => ... is all it accepts.

Case with more control

Want more customization? Want a componentDidUpdate hook? Want to select different things depending on the current props? Well, maybe you need to put a component in the middle then:

import React from 'react';
import connect from './connect';
import { bindActionCreators } from 'redux';
import Counter from '../components/Counter';
import * as CounterActions from '../actions/CounterActions';

class CounterContainer {
  componentDidUpdate() {
    ...
  }

  render() {
    const props = somehowSelectChildProps(this.props);
    return <Counter {...props} />
  }
}

export default connect(
  state => ({
    counter: state.counter
  }),
  dispatch => ({
    increment: () => dispatch(CounterActions.increment()),
    decrement: () => dispatch(CounterActions.decrement())
  })
)(CounterContainer);

This is an “explicit” smart component that is required for more advanced cases.
Note that you didn't have to move files or refactor anything.
You just put a component in the middle into the same file.

Shortcuts

Finally, we can still offer bindActionCreators, but with a actionCreators => dispatch => obj signature, so that the result is usable as the second parameter:

import React from 'react';
import { connect } from 'react-redux';
import Counter from '../components/Counter';
import * as CounterActions from '../actions/CounterActions';

export default connect(
  state => ({  counter: state.counter }),
  bindActionCreators(CounterActions)
)(Counter);

Perhaps we can even go further and bind automatically if an object is passed.

import React from 'react';
import { connect } from 'react-redux';
import Counter from '../components/Counter';
import * as CounterActions from '../actions/CounterActions';

export default connect(
  state => ({  counter: state.counter }),
  CounterActions
)(Counter);

“Wait!”, I hear you say. What if an action depends on some prop from the state? Well, in this case you put a component in the middle like I described above.

import React from 'react';
import { connect } from 'react-redux';
import Counter from '../components/Counter';
import * as CounterActions from '../actions/CounterActions';

class CounterContainer {
  increment() {
    this.props.increment(this.props.id);
  }

  render() {
    return <Counter {...this.props} increment={this.increment} />
  }
}

export default connect(
  state => ({  counter: state.counter }),
  CounterActions
)(CounterContainer);

Any sufficiently complicated case => component in the middle. Easy!

Am I missing something?

[acdlite]

👍 I like this. It's essentially the same API as https://github.com/acdlite/redux-rx#createconnectorselectstate-render, just without streams.

[acdlite]

Ah, only thing I see missing is a way to access props from owner — e.g. if you're wrapped by Relay.

[gaearon]

Can you clarify?
Isn't this “Case with more control” above?

[acdlite]

That works, I'm just not sure I like it... Seems like too common a case to necessitate what is essentially two smart components.

[acdlite]

Could we just pass the owner props as the second argument?

[gaearon]

From the user point of view they're just declaring one “real” component so no big deal IMO. On the other hand once you start selecting data in a tricky way, you begin to want finer control over perf optimizations, lifecycle hooks and maybe passing data down in a trickier way so it's likely you'll want a component anyway.

Once we start passing props to the state getter, we'll also probably want to pass props to the action creators getter. However, this forces us to bind on every prop change, which is a perf hit and unfriendly to shouldComponentUpdate optimizations down the rendering chain.

Example: you might want to read from props if you have a route handler that gets specific data related to the current route parameters. But then you already want to fire an action in componentWillReceiveProps and componentDidMount to fetch the data! So you already need an intermediate component anyway.

[skevy]

So are you just removing the idea of a higher order component here? The signature of "connect" seems the same as what was proposed in #86 (at least the shorthand one you suggested where you just pass an object of actions as the second param).

[acdlite]

@gaearon

On the other hand once you start selecting data in a tricky way, you begin to want finer control over perf optimizations, lifecycle hooks and maybe passing data down in a trickier way so it's likely you'll want a component anyway.

I really think accessing props from the owner is a much more common case that using lifecycle hooks. Props passing is the fundamental contract of React. We'll soon live in a world where pure functions are valid React components. The fewer "smart" components the better — creating class components will start to become a low-level implementation detai. Function components will be the new default. (At least that's what should happen. We'll see if the community catches on.)

However, this forces us to bind on every prop change, which is a perf hit and unfriendly to shouldComponentUpdate optimizations down the rendering chain.

This seems like a micro-optimization but okay. You could get around this by binding once if an object is passed ("bind automatically if an object is passed") but bind every time if its a function. Also if an action creator depends on a prop it's going to lead to updates further down the rendering chain, anyway.

[acdlite]

^ The reason I say it's a micro-optimization is you're rarely going to pass action creators more than one level down the component tree.

[skevy]

@acdlite also, it's easy enough to prevent constant rebinding with memoization. We had explored this a bit in redux#86

[ryancole]

I also agree with the sentiment that you'll rarely pass action creators more than one level down a component tree. This makes me question the over all usefulness of bindActionCreators. It seems to contrast the simplicity and obviousness of redux in general. It seems like it'd be clearer to just force users to pass dispatch down as a prop to every component, as described in the current readme file.

As a user, it seems like if dispatch is always needed to call an action, then maybe some way to remove the onus on the developer to pass dispatch down the tree. It'd be cool if you could just import your action methods and call them, no?

[acdlite]

@ryancole I still think bindActionCreators() (or some equivalent) is useful. You shouldn't pass dispatch() to a dumb component; you should bind it in a smart component first. E.g. your dumb components should look like this:

class CounterButton extends Component {
  render() {
    const { increment } = this.props;
    <button onClick={increment} />; 
  }
}

Rather than this:

class CounterButton extends Component {
  render() {
    const { dispatch } = this.props;
    <button onClick={dispatch(increment())} />; 
  }
}

It may seem like a trivial difference, but the first version is more separated from the implementation details of how it receives its callback. This leads to more scalable, maintainable, testable code.

It'd be cool if you could just import your action methods and call them, no?

You have to bind them somewhere. Remember, action creators in Redux are simply pure functions. Either we bind them in smart components, or we have to bind them at store creation time, in which case we'd need some sort of API for accessing the bound components. Or you could use singletons, but yuck.