Conflict with passing a "context" prop

[jmakGH]

Upon upgrading React and React Redux to the latest versions, an app I am working on started crashing on render.

After some debugging I traced the issue to a connected component being passed a "context" prop that was being used to control some of the app's features and completely unrelated to React's Context API.

I couldn't find any notes about that being a protected prop anywhere in the docs or online and thought it might be a good idea to post this here in case anyone else happened to stumble across this issue.

The biggest takeaway was that the only error message came from React, which made debugging the issue kind of a hassle -- especially because everything was working prior to upgrading to the latest version (which makes sense since the version of React we were using was before their Context update).

Perhaps a note under the Troubleshooting section of the website could document this issue as a potential pitfall.

Issue is recreated at this CodeSandbox. The app crashes whenever a context prop is passed to ConnectedChild.

Which versions of React, ReactDOM/React Native, Redux, and React Redux are you using? Which browser and OS are affected by this issue? Did this work in previous versions of React Redux?
React 16.8.1
ReactDOM 16.8.1
React Redux 6.0.0

This issue wasn't happening with React v15 and React Redux v4

[markerikson]

It is mentioned in the docs a couple times, but not particularly highlighted:

https://react-redux.js.org/api/connect#context-object

https://react-redux.js.org/using-react-redux/accessing-store#providing-custom-context

Up through 5.x, store was effectively a "reserved" prop, allowing users to pass a specific store instance directly to a connected component.

In 6.0, store is no longer meaningful as a prop, but we throw errors to let users know they probably made a mistake when upgrading and should change their code (because it won't do what they expected it to do). We also added context as a "reserved prop", because we allow users to pass a custom context instance to a connected component.

Given that we're considering having our next version be a major version change anyway, perhaps we could consider renaming that prop to be something like customContext instead of just context.

[jmakGH]

My mistake, I had overlooked that in the docs. I'm perhaps at fault for using your comment on #1104 as a reference guide for the migration without completely reading the updated docs.

I think you guys should be fine leaving it as context seeing as how I had a difficult time finding any discussion from others facing this issue. I'd assume most people now generally reserve context for React in general to avoid conflicts in semantics/code. We just had just been using it as a prop for a long time before they updated their Context API.

Thank you for your response! I'll go ahead and close this issue.

[sakulstra]

not sure if it's to late to alter the breaking changes 🤷‍♂️ but would have been great to have this noted somewhere :D debugged this for more than an hour till i found the problem. context as a component prop is sth we appearently use relatively often so the update broke our app at multiple places with no obvious relation to each other.

[tlginn]

I ran into this issue as well. I'm glad I found this thread!

[TheMoonDawg]

@markerikson Did y'all decided against renaming the prop to something like customContext? We also just ran into this same issue after upgrading.

Just curious. Thanks!

[strongui]

@markerikson @jmakGH What is the resolution to this? Can we change the name of the redux context prop? We use context all over our app, and it's not practical to rename it everywhere.

[markerikson]

Nope, there are not going to be any changes here. For one thing, we recommend using the hooks API instead of connect. Second, we just had a major version release (v8). No one brought this up during the extensive alpha/beta cycle, so it wasn't even a thing we could consider as a possible breaking change.

[strongui]

@markerikson With connect I was able to connect the same component with two different connect functions based on need. export fullComp = connect() vs export baseComp = connectBase(). Can something like this be replicated with the hooks?

[phryneas]

@strongui you will probably have to give more of an example what that was actually doing.

[strongui]

@phryneas I basically have a component that can be a top level Component, that gets all data/methods from redux. But it can also be used as a "sub" component, where it gets methods from redux, but data from the parent. So I was able to export the same component but with two separate connect methods.

I would just like to know if this can be replicated. Otherwise I have rename a prop across thousands of files because of this :/

[markerikson]

I'm sorry, but this is a public API and we can't / won't change it at this point. It's also been the same for several years now. Is there a specific reason why this is suddenly a problem?

Like Lenz said, if you can provide some actual example code demonstrating what you're doing, we may be able to offer other suggestions.

[strongui]

@markerikson we have a huge app, we haven't had time to update until recently.

const connector = connect(mapStateToProps, mapDispatchToProps);

const connectorCore = connect(null, mapDispatchToPropsCoreMethods);


const BaseComp = (props) => {
  return <div></div>
}

// This COMP will get all it's data from the redux store
export const FullComponent = connector(BaseComp);
// This COMP will demand data from the parent
export const NonDataComponent = connectorCore(BaseComp);

Basically this. Same component, but one gets data form redux, the other will get data from parent.

[phryneas]

@strongui something like this?

function NonDataComponent({ data }) {
  const dispatch = useDispatch()

  // just use dispatch here to dispatch your actions
}

function FullComponent (){
  const dataFromStore = useSelector(selectDataFromStore)
  return <NonDataComponent data={dataFromStore} />
}

[strongui]

@phryneas Nevermind I misread! I think that will work