Eslint-plugin-react: Rule 'prop-types' incorrectly working with redux's mapping actions to props

[vansosnin]

Hi!
When we use redux's connect, we can add some actions to component's props. But we don't want to define them in component's PropTypes because we don't want to pass these actions from the outside. Furthermore, when we use this component, we don't need to know anything about these functions.
Is it possible to add some validation to ignore mapped actions?

[yannickcr]

Hi, you can use the ignore option to ignore some props during the validation

[vansosnin]

@yannickcr I see, but it doesn't seems to be comfortable to add every action to global ignore list.

[nmaves]

I too feel the pain of this issue. The purpose of this rule to to protect developers as the assign properties to a component. These are never assigned, as they are injected. Not sure how to clean this up.

[yannickcr]

I'm sorry, when inspecting a component we cannot know from where the props comes from, so we cannot ignore all "injected" props at one time.

But I don't really see why you do not want to declare these props inside the component. As I can see the component does not makes any difference between "assigned" and "injected" props, so declaring all of them seems to be the right thing to do. But I am not very experienced with the Redux pattern.

[vansosnin]

Oh, that's sad.

Well, as I said before, injected props are not the thing you want to receive from the outside. Because if you see some prop in component's propTypes without careful exploring of this component, you may want to pass this prop from the outside and this may break the component. This is the only reason.

Actually, this is pretty holywar theme for discuss, and we had one in team :) But we've decided to keep rule prop-types and add injected actions or something to component's propTypes because profit from this rule is much more.

Thank you for you work and reply!

[jnields]

I ran into this issue as well and have been injecting actions into props validation as they are added and removed. It's been helpful to detect accessing actions that aren't actually available (e.g. misspelling).

Here's an example

import React, { Component, PropTypes } from "react";
import { connect } from "react-redux";
import * as actions from "../actions";

class ExampleComponent extends Component {

    static get propTypes() {
        const result = {};
        Object.keys(actions).forEach(action => {
            result[action] = PropTypes.func;
        });
        result.label = PropTypes.string.isRequired;
        return result;
    }

    constructor(props) {
        super(props);
        this.state = {value: ""};
    }

    onChange(e) {
        this.setState({
            value: e.target.value
        });
    }

    submit(e) {
        e.preventDefault();
        this.props.saveValue(this.state.value);
        this.setState({value: ""});
    }

    render() {
        return <form onSubmit={this.submit.bind(this)}>
            <label>{this.props.label}
                <textarea value={this.state.value}
                    onChange={this.onChange.bind(this)}/>
            </label>
            <button action="submit">Submit</button>
        </form>;
    }
}

export default connect(null, actions)(ExampleComponent);

as I see it, it really should be validated. The component _does_ interact with the outside, and this just validates that it's accessing an interface that is available. Some extra typing, sure, and it might be useful to have this plugin support this off-the-shelf, but I think it's still valuable enough to be worth some verboseness.

[jannakha]

just have it as an object of actions, like Cory does https://github.com/coryhouse/react-slingshot/blob/master/src/containers/FuelSavingsPage.js#L31
then you just need to define in props actions: object

[dspacejs]

I figured out a neat workaround.

None of my container components use React's PropTypes; each container's corresponding UI component uses PropTypes validation. If this is the case for your project, you can disable the react/prop-types rule for your containers specifically, thus bypassing the 'propName' is missing in props validation (react/prop-types) error.

Since all of my container components use Container.jsx as a suffix, I was easily able to disable react/prop-types for all my container files with the following configuration:

{
  "overrides": [
    {
      "files": ["*Container.jsx"],
      "rules": {
        "react/prop-types": false
      }
    }
  ]
}

[kpace]

@de-spajic

I am still not able to turn off react/prop-types. I tried for specific file loginContainer.jsx with no success. :(

Below is my .neutrinorc file.
The project structure is:

    .neutrinorc
    src/
        containers/
            loginContainer.jsx

Any help is appreciated. Thanks!

```
module.exports = {
use: [
[
'@neutrinojs/airbnb',
{
eslint: {
rules: {
'prefer-template': 'off',
'no-console': 'off',
},
overrides: [
{

          'files': ['src/containers/loginContainer.jsx'],
          'rules': {
            'react/prop-types': false,
          }
        }
      ]
    }
  }
],
[
  '@neutrinojs/react',
  {
    html: {
      title: 'My project'
    }
  }
],
'@neutrinojs/karma',
'neutrino-middleware-sass',

]
};```

[dspacejs]

@kpace I just checked my configuration and it's different to what I commented, sorry. Instead of 'react/prop-types': false, try using 'react/prop-types': 0.

If it's applicable for your use case, I also recommend using a glob to match all containers instead of that specific container, such as *Container.jsx.

[rafaelgrilli92]

@de-spajic worked like a charm. Cheers!

[ammaraskar]

Hey could the people wanting this feature post some varied examples of properties being injected into components? I'm trying to create a version of this rule that ignores injected properties that can be statically determined. Currently it can handle really simple snippets like these:

https://github.com/ammaraskar/eslint-injected-proptypes/blob/master/tests/lib/rules/non-injected-prop-types.js#L50-L77

But I'm not familiar with all the different patterns there are for this. If it seems like its doable, I'll see if it can be merged back into the parent project.