Identical styled generating different classnames

Version

2.2.1

Hi! I’m writing a HOC for wrapping and enhancing my styled component. I know this kind of pattern has been frowned upon in previous issues (#316), and without going into the details of what my HOC is doing, just trust me when I say I have a valid use case.

To enhance my wrapped component I’m parsing it’s props and generate some styles which I then pass to the styled method of styled-components, passing in my WrappedComponent to be used as a base. My only problem with this approach is that even though I generate the exact same styles a unique class name is created for every component. I’m concerned that this might turn into a performance hog in the long run and would like to know if there’s a better way to “inject” styles into an existing component.

[kitten]

My only problem with this approach is that even though I generate the exact same styles a unique class name is created for every component.

That sounds either like you’re confusing the static and dynamic class we create, or it sounds like you’re recreating the styled component on every render.

I’m writing a HOC for wrapping and enhancing my styled component. I know this kind of pattern has been frowned upon in previous issues (#316), and without going into the details of what my HOC is doing, just trust me when I say I have a valid use case.

It’s not encouraged for a reason, and I don’t think there is any valid use case to be honest. Sorry, if that comes across as harsh, but HOCs for styling do not scale, and we do not want to recommend them, or be associated with the pattern 😄

[johnnyBira]

I totally see your arguments agains doing this, personally I think the pros overweight the cons in this particular case.

Another reason for this approach in my option is portabilty. Imagine you’ve defined media querie with their responsive styles, encapsulated inside each styled component. Now you want to reuse the component in another project with different breakpoints. This logic could of course be tailor for every individual component, but I still prefer not having to repeat that logic and also have a common API for responsive props.

Thank you @philpl you’ve been very helpful.