Deprecate withRef for innerRef

[javivelasco]

Since assigning string refs is going to be deprecated sooner or later, we should provide refs in as callbacks. Also, accessing instances using the imperative method getWrappedInstance goes against React best practices.

For this from now on we are removing the option withRef and instead you can pass an innerRef prop to the decorated component that will pass down a ref to the decorated component. This makes the API way easier.

Since it's a breaking change, it will be released as a major version.

[klimashkin]

Hi!
How does innerRef work if I have component, decorated by more than one hocs?
Like

@themr('Comp', styles)
@anoterhoc()
export default class Comp extends PureComponent {
  ...
}

How can I get instance of Comp using innerRef?

[javivelasco]

Hi @klimashkin !

As you can see here we are just passing the innerRef callback as ref to the component being decorated. In the scenario you are describing, the ref would be assigned to the component generated by anotherhoc and you want to retrieve the most internal reference.

This anotherhoc must keep a way to retrieve the reference of the internal component as well so you should be able to access that reference programmatically. But I've just realized that maybe it makes sense to map the reference not directly to ref but to another innerRef since this is a very common pattern.

In the example you are explaining you would have access to the instance of the component created by anotherhoc like innerRef: instance => { ... }. It may happen, for example with styled-components, that the decorator accepts an innerRef too so the most convenient would be to pass innerRef in an innerRef prop instead of ref, this way you'd get the reference to the component straight.

I'm going to write the change and an example during the afternoon.

[klimashkin]

Thank you for attention, my question was asked to raise the same on your side : )

We need some convention among HOCs about innerRef. And I think simply passing innerRef to the underline hoc is not enough, because hocs don't know whether they decorate another hoc or real component, and in case of real components passing innerRef can be dangerous.

I think hocs should have boolean option, for instance, passInnerRef like most of hocs have withRef nowadays (that is being removed).
And if passInnerRef: true, your hoc just passes innerRef further as prop:
<WrappedComponent innerRef={this.props.innerRef}>
If passInnerRef: false or absent do what has been done in this PR, ref={this.props.innerRef}

How do you think?

[klimashkin]

@javivelasco Do you copy? : ) What do you think?

[javivelasco]

Sorry it took this long @klimashkin. Please check #59 I think it covers all use cases

[HiirenP]

@javivelasco
I used react-css-themr to implement delicious theme into my component(e.g. button) so for component project it works fine (like priority is ---> external theme 1st and if not getting external theme(button.scss from delicious theme folder) it use internal theme (button.scss from component's scss folder)).

this is working fine for this project. but if i deploy this project and use as library into other project (like button component to my main project)then it always loaded default css instead of external css.
can any one please help me in this?

thanks!!!!

[klimashkin]

@HiirenP I created a set of modules, which are faster and don't require ref hustle:
https://github.com/klimashkin/css-modules-theme

[HiirenP]

@klimashkin
Thanks!! for the help i will surely give this a try in demo, but in my regular project i cant because i have reached at peak and from here i cant afford to make global changes.
But do you really think that react-css-themr is having a problem while running on server only, because this works fine locally.?
Thanks again!!