Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal/Question for mapStateToProps mapDispatchToProps #985

Closed
SanzSeraph opened this issue Jul 30, 2018 · 3 comments
Closed

Proposal/Question for mapStateToProps mapDispatchToProps #985

SanzSeraph opened this issue Jul 30, 2018 · 3 comments

Comments

@SanzSeraph
Copy link

I'm relatively new to React and VERY new to Redux/react-redux, so this could just be the result of my lack of experience, but I find the react-redux API to be exceedingly clunky, particularly as regards the mapStateToProps, mapDispatchToProps, and connect portion.

This part of the API seems to reinvent the wheel. React already has a mechanism for mapping stuff to props: a parent component.

Imagine instead that connect() took one and only one argument: a component that would have access to the state object and the dispatch function. The relevant portions of the state, and the dispatching behavior, would be passed like normal props in JSX to the presentational component that actually needs them.

import { Component } from 'react';
import { connect } form 'react-redux';
import PresentationComponent from '...';

class ConnectedComponent extends Component {
  render() {
    var { state, dispatch } = this.props;
    return <PresentationComponent someStateProp={state.someProp} someBehaviorProp={this.dispatchSomething} />
  }
  dispatchSomething() {
    ...
  }
}

export default connect(ConnectedComponent)

You could even replace the connect function with a component, to make it even more consistent with the React way of thinking. I know HOCs are a React pattern, but I think you could achieve the same thing declaratively.

<ReduxConnector>
  <ConnectedComponent />
</ReduxConnector>

In short, react-redux seems to be inexplicably mixing paradigms between declarative with functional syntax, which is quite confusing.

As I said, I'm new to all of this, so maybe I've left out some important consideration.

@markerikson
Copy link
Contributor

markerikson commented Jul 30, 2018

connect has several purposes:

  • It abstracts away the interaction with the store, so that you don't have to write the subscription logic yourself
  • It abstracts away the question of which store you're working with, making your code more testable
  • It implements some hefty performance optimizations, so that your own component only re-renders when the data has actually changed
  • It allows you to keep your own components plain and "unaware" of Redux - they just get data and functions as props, like any other components.

So, ultimately connect does generate a wrapper component that does the kind of work you describe, but it does so by using the mapState and mapDispatch functions you provide. That's because the only things that change between various components is what data and what functions they need as props.

You might want to read through my workshop slides on integrating a UI with Redux, and using React-Redux.

Note that per the development roadmap in #950 , we are open to suggestions for new API approaches for a future v7.0 release.

@SanzSeraph
Copy link
Author

SanzSeraph commented Jul 30, 2018

Thanks for the info. I'll definitely take a look at those slides.

I know connect does some heavy lifting, but is there anything that would prevent implementing those same features using the declarative approach I described?

@markerikson
Copy link
Contributor

markerikson commented Jul 30, 2018

Is it possible? Sure - as a friend of mine says, "you can do anything - it's just software". But, that's already all the stuff that connect does for you.

You might want to go back and read some of the discussions in issue #1 to understand the intent behind this API design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants