New jsx-no-ref rule

[prometheas]

Implemented rule that flags use of ref attribute in user-defined JSX tags, as this is considered a smell of non-declarative component design.

cc: @mjackson

[mjackson]

Love this, @prometheas! ❤️

I'll definitely be recommending this to everyone.

[gaearon]

Won’t this become the new “setState is bad”?
Refs on components have good use cases, such as focusing a custom input.

There are tricks with passthrough ref props (e.g. <CustomInput inputRef={...} /> and then <input ref={this.props.inputRef} /> inside) but those are less commonly known, and probably trickier to understand than component instances.

[mjackson]

I don't think so. Putting refs on compound elements is pretty much always a bad idea. I think this could actually be a really useful linting rule that helps you write more declarative code.

As for "setState is bad", how did people ever even start down that path? ;)

[ljharb]

Why is it OK to add a ref on DOM elements?

The examples seem to imply that string refs are ok and callback refs are not. Could you make sure the examples for both valid and invalid contain inline callback refs as well as string refs?

[gaearon]

Putting refs on compound elements is pretty much always a bad idea.

How do you solve cases like needing to focus a component that manages text input after a click on its sibling? Or select all text in it.

[gaearon]

If you absolutely think this rule is necessary then it would be good to document good use cases for refs, for example triggering focus, selection, and imperative animations. These are important use cases and can be hard with React declarative model.

[prometheas]

One point I think is worth considering: given that ESLint rules are intended to be ignored, warned about, or report errors by means of .eslintrc files.

In that light, it's worth considering whether part of the feedback might be best considered in the frame of default error levels (perhaps it defaults to ignore or merely warn).

[bvaughn]

I don't think so. Putting refs on compound elements is pretty much always a bad idea. I think this could actually be a really useful linting rule that helps you write more declarative code.

react-virtualized uses this type of ref to enable some really handy composition (eg List and Table decorate Grid). Other decorator-type libs of mine like react-virtualized-select use this kind of ref to managed things like focus and sizing.

I don't think it's a good idea to treat it as always-bad.

[mjackson]

I don't think it's a good idea to treat it as always-bad.

OK, I shouldn't have said it's always a bad idea. I haven't ever needed a ref on a custom component, but apparently you have 😅 I'm not suggesting we put this in the recommended set. But I still believe this rule could go a long way toward helping people write better code, which is partly what a linter is supposed to do.

[bvaughn]

Sure. I agree with that.

We should aim to communicate when it's appropriate though so people don't make tl;dr assumptions and miss out on a useful tool (albeit with limited application).

[prometheas]

Sounds like something that ought to be added to the markdown file. I'm unfortunately quite new to React, however, so I'm not sure I can really nail a solid summary on this one.

Does anyone have some advice for me on language to use for an edit?

[bvaughn]

Does anyone have some advice for me on language to use for an edit?

@prometheas This recent addition to the React docs may be helpful: https://facebook.github.io/react/docs/refs-and-the-dom.html#when-to-use-refs

[prometheas]

Thanks, @bvaughn; on it!

[ljharb]

@prometheas given the updated react docs on refs, do you still think this rule is useful? if so, could you rebase it and mark it as ready for review?

[prometheas]

Oh my goodness, echoes from days of yore 🤣

In the 4 years since I had originally contributed this PR, the only real "must-use" scenario I've frankly encountered (and, for the record, it's hard to describe it as "rarely") is the .focus() and .blur() (I work almost exclusively in react native these days), and the occasional .clear().

Still, I definitely also see plenty of scenarios in which the ref attribute is used to create very imperative component ecosystems (comes up a ton in form UIs).

Let me revisit this PR sometime in the days ahead, as well as get my head around what may have changed in the docs.