Deprecating connectAdvanced

[timdorr]

I intend to remove the connectAdvanced API from React Redux, essentially replacing connect with its contents.

Why? It's an abstraction that we don't use ourselves, so it just becomes an indirection in the code. It is only minimally used in the community. It creates a more complex code base, which is a barrier to entry for many contributions. Plus, frankly, I just don't like it; it gives me Java flashbacks.

This is mainly to give the few folks that do use it a heads up. It won't go away until the next major release. However, I intend to add a deprecation warning at some point in the future. We'll do that after Hooks, just so we're not dropping two big changes in one minor release. Plus, you can lock to that version to have your Hooks and your connectAdvanced at the same time. Sound fair?

If there are specific use cases, we can see about migrating them into the connect API, most likely as options. This isn't about completely throwing away a big chunk of functionality, just simplifying the code base a bit and making it easier to grok for everyone.

[gaearon]

👍 I could never understand what it does or why it was added. It sounds like if you need this kind of complexity you should just vendor the connect code and maintain it yourself.

[markerikson]

FWIW, the intended use case is for an end user to be able to customize how all the memoization and prop generation is handled, on their own. All the logic for managing the subscription itself stays the same - it's really just changing from calling mapState and mapDispatch specifically, to (storeState, dispatch) => childProps, and connect implements its mapState/mapDispatch handling as one possible (storeState, dispatch) => childProps function.

If y'all are really dead set on removing it, we can, but I truly don't think it adds that much extra complexity.

Lemme tag three folks who I know have a particular interest in this: @jimbolla, @epeli, @mariusandra.

A couple of example usages:

https://github.com/keajs/kea/blob/9491b5a269b4c18644dc4185d43f77da3d7a79d1/src/kea/index.js#L257

https://github.com/epeli/redux-render-prop/blob/7e1fcf4d38b41616f56f3c53eb15233610570215/src/redux-render-prop.ts#L72

[esamattis]

Bummed about this of course but I understand the reasoning and I can live with. Actually just realized I can achieve everything I want with the areStatePropsEqual option of connect().

Farewell connectAdvanced().

[mariusandra]

This would be a bummer. Kea is basically built around it. I'll need to see if I can work around it and will provide a more insightful reply next week, as I'm literally boarding a plane for a weekend getaway now.

Cheers!

[jimbolla]

I'm not using Redux so I don't have an opinion on this.

[mariusandra]

Hey, after tinkering a bit with the code (read: totally rewriting Kea), I no longer need connectAdvanced.

Now that I worked with the code again, I remember why I used it in the first place: I was being sneaky, grabbed the dispatch that was given to selectorFactory and used it to initialise the redux store under certain conditions. I remember I couldn't find any other clean way to directly get dispatch from the react-redux API without caching it on store creation, so I went with connectAdvanced. It simplified a few other things as well... and made many others way too complicated.

Now I bit the bullet and switched to just stealing the store from react-redux and using it directly to dispatch hydration actions in order to regenerate the store when a new reducer needs to be added. I'm not sure if dispatching actions to regenerate the store is better than using store.replaceReducer or not... but it has never caused issues so far.

The rewrite comes with many other changes, some of which are breaking, so it's not released yet. However I got all the tests to pass, so it shouldn't be too long now. I still need to rearchitect the plugin system, integrate thunks and sagas and test it on my own app before I'm ready to release it into the wild.

Thanks for the push guys! This rewrite was long overdue!

[markerikson]

Well, based on those responses, it sounds like the primary folks who were using it have determined that they no longer need it. I'd say that puts a nail in it.

(I still don't think there's going to be much actual difference as far as the internal code goes, given the way things are structured, but we'll see.)

[flipmotion]

Hi to all!
I think connectAdvanced is usefull, basically connect are sliced to 3 part for work with redux and i think it's like tricky. I used connectAdvanced around in our project BUSFOR, and thats awesome:

`

export default connectAdvanced(dispatch => {
  const getActions = {some code};

  let result;

  return ({ search }, ownProps) => {
    const stateProps = ({
      {...}
      ...getActions({ tripId, selectedSeats, bestPrice }),
    });

    const nextProps = {
        ...ownProps,
        ...stateProps,
        dispatch,
     };

    if (!equals(result, nextProps)) {
      result = nextProps;
    }

    return result;
 }; 
})(Trip);

`

For my think, it's cleaner way to put some data from store\from view into Actions.

Or mb i do something wrong?

PS: and no need it more selectors func from reselect, so i do my self with equals of next props

[markerikson]

@flipmotion : would one of the other options for customizing connect's comparisons work for your situation?

[flipmotion]

@markerikson : I think it could be, but it’s, again, more useless code. In ‘connectAdvanced’ it better cuz ur get all props from state, from component it one place, and if u need just 2-3 things, it’s more simple. Again i create selectors for data in first call, then i can combine it in second calling with some storeProps and OwnProps. And the same with actionCreators like with computed data selection. And this do in one place, without cutting it for other functions in connect options.

const mapDispatchToProps = (dispatch) => {
  return {
     dispatchSave: (items) => dispatch({type: "SAVE_ALL", items})
  };
};

const mergeProps = (propsFromState, propsFromDispatch, ownProps) {
  return {
    save: propsFromDispatch.dispatchSave(propsFromState.items)
  };
};

const SaveAllContainer = connect(mapStateToProps, mapDispatchToProps, mergeProps)(SaveAll)

I think it more boilerplate then connectAdvanced.

export default connectAdvanced(dispatch => {
  const getActions = {some code with createSelector};

  let result;

  return ({ storeProp }, { ownProp, ...ownProps }) => {
    const stateProps = {
      ...getActions({ storeProp, ownProp }),
    };

    const nextProps = {
        ...ownProps,
        ...stateProps,
        dispatch,
     };

    if (!equals(result, nextProps)) {
      result = nextProps;
    }

    return result;
 }; 
})(Component);

Like i in my previous post when i can put some data from store and ownProps in actionCreator in one simple way.

I understand that this is a trick, but I am aware of my actions. I consider it a very simple and effective solution.

Or i do something wrong? Thx.

[goszczynskip]

Connecting Deck.gl layers is very convenient with connectAdvanced. Layer classes can't be wrapped directly with connect because they are not React components. To create them you can leverage connectAdvanced's feature of getting dispatch and state in one function.

const selector = dispatch => {
  const actions = mapDispatchToProps(dispatch);
  const getLayers = createLayersSelector(
    dispatch
  );

  return (nextState, nextOwnProps) => {
    const nextProps = mapStateToProps(nextState, nextOwnProps);
    const layers = getLayers(nextState, nextOwnProps);
    return {
      ...actions,
      ...nextProps,
      layers
    };
  };
};

layers selector:

export default dispatch => {
  const getData = (state) => state // here you can prepare selector

  return createSelector(
    [getData],
    (data) => {
      return [new PointsLayer({
        data,
        onClick: bindActionCreators({ someAction }, dispatch) // here you need dispatch 
        // other layer props
      })];
    }
  );
};

Such approach allows you to split layer creation to different files and keep each layer near to it's own selectors. I can't see how presented solution (or similar) may be achieved with mergeProps from connect.

[kogal]

I would suggest that you add a deprecation note in the connectAdvanced's documentation, to prevent people, new to react-redux, from using it.

https://react-redux.js.org/api/connect-advanced

[whykushal93]

If we are deprecating it, could we add ownProps as an argument to the areStatesEqual option please ? I was hoping to use connectAdvanced to get around ownProps not being passed to areStatesEqual.
This was previously asked in this and there was also a PR.