You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See the code sandboxes below (all that is needed is the latest versions of react, styled-components, and for the connect() case, redux and react-redux)
In v3, the following general pattern used to work for creating reusable components that rely on withTheme or react-redux connect() and then customizing their styling in specific situations (this is pseudocode, obviously):
// In reusable component file
const LeafComponent = (props) => whatever
const StyledLeafComponent = styled(LeafComponent)` styles which might reference connect props here `
const ReusableComponent = connectOrWithTheme(StyledLeafComponent)
// In some other file where the reusable component is being customized
const CustomizedComponent = styled(ReusableComponent)` additional context-specific styles here `
In v4 and v5, this pattern fails for both connect() and withTheme, with the corresponding props (either store props, or theme), being undefined in the reusable component (props from connect() are also undefined in the leaf component's styles, where we might need to reference them). In fact, mapStateToProps in connect() doesn't seem to even run at all!
The following workaround which just adds a pass-through component in between seems to fix things:
As you can see, the "count" store state is undefined in the leaf component. Rolling back to v3 of styled components fixes it. (Uncommenting the workaround also fixes it)
As you can see, theme is undefined in the leaf component. Rolling back to v3 of styled components fixes it. (Uncommenting the workaround also fixes it)
Expected Behavior
Props from connect() and withTheme would not be undefined in the leaf component (and its styles) as described above just like in v3.
Actual Behavior
Props from connect() and withTheme are undefined in the leaf component (and connect() props are undefined in the leaf component's styles) as described above in v4/v5.
Additional Notes
This seems to be almost identical to the issue reported in #2266 however, that was quite a while ago and the fix suggested there seems to not apply anymore. The issue we are reporting here occurs with the latest version of react-redux and also the value passed to connect() for forwardRef has no effect.
We were hoping to upgrade our production app from v3 to v5 but this issue has us hesitating. For one thing, as soon as we upgrade, we will have runtime errors from this issue scattered around our codebase which we will not know are there until we trigger them. And it will be easy to accidentally introduce new runtime errors from this pattern unless we are very careful.
Can this be fixed (perhaps the workaround can be directly incorporated into the library somehow)? If not, can the situation at least be detected and print a console error? Having no warning that this problem exists and not discovering it until something blows up at runtime seems like a major regression on what was a useful feature in v3.
The text was updated successfully, but these errors were encountered:
stheis2
changed the title
connect() and withTheme don't pass down props when overriding styles with styled() in v4/5, works in v3
connect() and withTheme props are undefined when overriding styles with styled() in v4/5, works in v3
May 7, 2020
Environment
See the code sandboxes below (all that is needed is the latest versions of react, styled-components, and for the connect() case, redux and react-redux)
Reproduction
https://codesandbox.io/s/styled-components-issue-with-connect-p4jks?file=/src/index.js
https://codesandbox.io/s/styled-components-issue-with-withtheme-rgqbx?file=/src/index.js
Steps to Reproduce
In v3, the following general pattern used to work for creating reusable components that rely on withTheme or react-redux connect() and then customizing their styling in specific situations (this is pseudocode, obviously):
In v4 and v5, this pattern fails for both connect() and withTheme, with the corresponding props (either store props, or theme), being undefined in the reusable component (props from connect() are also undefined in the leaf component's styles, where we might need to reference them). In fact, mapStateToProps in connect() doesn't seem to even run at all!
The following workaround which just adds a pass-through component in between seems to fix things:
This is a specific example of this for connect() (same link as in "Reproduction" above): https://codesandbox.io/s/styled-components-issue-with-connect-p4jks?file=/src/index.js
As you can see, the "count" store state is undefined in the leaf component. Rolling back to v3 of styled components fixes it. (Uncommenting the workaround also fixes it)
Similarly, here's an example of this for withTheme (same link as in "Reproduction" above): : https://codesandbox.io/s/styled-components-issue-with-withtheme-rgqbx?file=/src/index.js
As you can see, theme is undefined in the leaf component. Rolling back to v3 of styled components fixes it. (Uncommenting the workaround also fixes it)
Expected Behavior
Props from connect() and withTheme would not be undefined in the leaf component (and its styles) as described above just like in v3.
Actual Behavior
Props from connect() and withTheme are undefined in the leaf component (and connect() props are undefined in the leaf component's styles) as described above in v4/v5.
Additional Notes
This seems to be almost identical to the issue reported in #2266 however, that was quite a while ago and the fix suggested there seems to not apply anymore. The issue we are reporting here occurs with the latest version of react-redux and also the value passed to connect() for forwardRef has no effect.
We were hoping to upgrade our production app from v3 to v5 but this issue has us hesitating. For one thing, as soon as we upgrade, we will have runtime errors from this issue scattered around our codebase which we will not know are there until we trigger them. And it will be easy to accidentally introduce new runtime errors from this pattern unless we are very careful.
Can this be fixed (perhaps the workaround can be directly incorporated into the library somehow)? If not, can the situation at least be detected and print a console error? Having no warning that this problem exists and not discovering it until something blows up at runtime seems like a major regression on what was a useful feature in v3.
The text was updated successfully, but these errors were encountered: