button-has-type does not allow for dynamic assignment

[pke]

My Button component allows to override the type arg but button-has-type is still complaining about. It seems it does not validate the real AST path of prop assignment

Button = ({ type = "button" }) => <button type={type}/>
Button.propTypes = {
  type: PropTypes.arrayOf(["submit", "button", "reset"]),

Does the plugin have access to the propTypes and can match that the only possible allowed values are within the rules allowed values and that the default type is also set to something specific, like in my example to button?

[ljharb]

Stateless React Components should not use JS default values; that needs to be a defaultProp.

[pke]

When you say "should not" where does this recommendation come from? Is this a lint suggestion or are there language/runtime implications?

[ljharb]

defaultProps are introspectable by React and other tools; default arguments are not. #1184 has more discussion on it.

[lydell]

Regardless of the defaultProps discussion, something’s buggy with this rule.

The following code:

<button type={submit ? "submit" : "button"} onClick={onClick}>
  {children}
</button>

… gives the following lint error:

"null" is an invalid value for button type attribute

Surely it shouldn’t say "null" there?

[ljharb]

@lydell very true! the ternary case would probably have to be explicitly handled; however, I'd say that the rule should be forcing a single, hardcoded type value - and that you should conditionally render two different elements if you want two types.

[mikebarnhardt]

I agree this rule is handled poorly. defaultProps with a type of either button, reset, or submit should not trigger.

A work-around is to just disable the rule temporarily:

/* eslint-disable react/button-has-type */
return <button {...passProps} className={buttonClassNames} type={type}/>;
/* eslint-enable react/button-has-type */

[ljharb]

The type should not be dynamic, full stop.

If you want the type to be one of the 1, 2, or 3 options, use if/else and hardcode those three.

[pke]

Why shouldn't it be dynamic? Can you explain please?

[brandonburkett]

I am also interested in "why" it should be dynamic (because dev typo in props?). Seems weird to duplicate the button three times for a hardcoded value.

htmlType: PropTypes.oneOf(['button', 'submit', 'reset']),
static defaultProps = { htmlType: 'button' }
<button type={htmlType || 'button'} />

[ljharb]

Only twice, since reset buttons are a terrible UX pattern :-)

[ljharb]

It shouldn’t be dynamic because all three button types have wildly different semantics - i can’t conceive of when you’d want a submit button randomly changing to be an entirely different kind of button, or vice versa.

A submit button must be inside a form; a regular button must have some kind of javascript behavior - these are different components/elements, not just two flavors of the same thing.

[brandonburkett]

Isn't that true for input types as a whole? Not just specific button? Why wouldn't this give an error as well?

type: PropTypes.oneOf(['text','email','tel','password','url','search','number','date','range','file']),
static defaultProps { type: 'text' }
<input type={type || 'text'} ... />

[ljharb]

Yes, that is certainly true! However, the primary point of the rule is to ensure that button is used safely.

If we wanted to make a generic rule that governed input types, that would also force them to be static (and I'd encourage you not to make a non-private generic input component that takes "type" as a parameter, for the reasons I mentioned above)

[pke]

In a REST level 3 kind of app where the app state is completely controlled by the server, the server dictates the fields of a form. That's a valid scenario for when the button type needs to be dynamic. Since hardcoding the now known button types defeats the entire reason for going REST level 3, which is to have an evolutionary API, which can change in the future without touching the client but just send a new HTML6 value for button type.

But since REST level 3 apps are such a rare breed as of now I'll just disable this rule that's supposed to make the button type usage "safe".

[ljharb]

I'm not familiar with any HTML 6 nor any plans for it in the near or far future, nor any plans for any new button type ever. When one appears, the server shouldn't be controlling that - it should only be explicitly supported in the UI.