Подтвердить что ты не робот

Избегать ошибки тени без тени с помощью mapDispatchToProps

У меня есть следующий компонент, который вызывает ошибку no-shadow ESlint на FilterButton props.

import { setFilter } from '../actions/filter';


function FilterButton({ setFilter }) {
  return (
    <button onClick={setFilter}>Click</button>
  );
}

export default connect(null, { setFilter })(FilterButton);

Как я могу избежать предупреждения, сохраняя как сжатый синтаксис mapDispatchToProps, так и правило ESlint?

Я знаю, что могу добавить комментарий, чтобы подавить предупреждение, но делать это для каждого компонента кажется излишним и утомительным.

4b9b3361

Ответ 1

Здесь есть четыре варианта:

1. Отключите правило.

Почему?

Это самый простой способ избежать ошибки ESLint.

Почему не?

Правило no-shadow помогает предотвратить очень распространенную ошибку при использовании react-redux. То есть, попытка вызвать необработанное, несвязанное действие (которое автоматически не отправляется).

Другими словами, , если вы не были, используя деструктурирование и захват действия из реквизита, setFilter() не отправил действие (потому что вы будете ссылаться на импортированное действие напрямую, в отличие от вызывая подключенное действие через реквизит через props.setFilter(), который react-redux автоматически отправляет вам).

Убрав переменную затенение, вы и/или ваша IDE с большей вероятностью возьмете ошибку.

Как?

Добавление свойства eslintConfig в ваш файл package.json один из способов сделать это.

"eslintConfig": {
    "rules": {
      "no-shadow": "off",
    }
  }

2. Перенесите переменную при передаче ее в connect().

Почему?

Вы пользуетесь безопасностью правила no-shadow, и, если вы решите придерживаться соглашения об именах, оно очень явное.

Почему не?

Он вводит шаблон.

Если вы не используете соглашение об именах, вам нужно придумать альтернативные имена (которые все еще имеют смысл) для каждого действия. И есть вероятность, что одни и те же действия будут именоваться по-разному по компонентам, что затрудняет знакомство с самими действиями.

Если вы используете соглашение об именах, имена становятся длинными и повторяющимися.

Как?

Без соглашения об именах:

import { setFilter } from '../actions/filter';

function FilterButton({ filter }) {
  return (
    <button onClick={filter}>Click</button>
  );
}

export default connect(null, { filter: setFilter })(FilterButton);

С соглашением об именах:

import { setFilter, clearFilter } from '../actions/filter';

function FilterButton({ setFilterConnect, clearFilterConnect }) {
  return (
    <button onClick={setFilterConnect} onBlur={clearFilterConnect}>Click</button>
  );
}

export default connect(null, {
  setFilterConnect: setFilter,
  clearFilterConnect: clearFilter,
})(FilterButton);

3. Не разрушайте действия от реквизита.

Почему?

Явным образом используя метод off объекта реквизита, вам не нужно беспокоиться о затенении для начала.

Почему не?

Превращение всех ваших действий с помощью props/this.props является повторяющимся (и непоследовательным, если вы разрушаете все ваши другие неактивные реквизиты).

Как?

import { setFilter } from '../actions/filter';

function FilterButton(props) {
  return (
    <button onClick={props.setFilter}>Click</button>
  );
}

export default connect(null, { setFilter })(FilterButton);

4. Импортируйте весь модуль.

Почему?

Это краткий.

Почему не?

Другие разработчики (или ваше будущее) могут не понимать, что происходит. И в зависимости от руководства по стилю, за которым вы следуете, вы можете нарушить правило no-wildcard-import.

Как?

Если вы просто передаете создателей действий из одного модуля:

import * as actions from '../actions/filter';

function FilterButton({ setFilter }) {
  return (
    <button onClick={setFilter}>Click</button>
  );
}

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

Если вы передаете несколько модулей, используйте деструктурирование объекта с синтаксисом отдыха:

import * as filterActions from '../actions/filter';
import * as otherActions from '../actions/other';

// all exported actions from the two imported files are now available as props
function FilterButton({ setFilter, clearFilter, setOther, clearOther }) {
  return (
    <button onClick={setFilter}>Click</button>
  );
}

export default connect(null, { ...filterActions, ...otherActions })(FilterButton);

И так как вы упоминали о предпочтении сжатого синтаксиса ES6 в комментариях, могли бы также добавить функцию стрелки с неявным возвратом:

import * as actions from '../actions/filter';

const FilterButton = ({ setFilter }) => <button onClick={setFilter}>Click</button>;

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

Ответ 2

Пятый вариант:

5. Разрешить конкретное исключение через правила eslintrc.

module.exports = {
  rules: {
    'no-shadow': [
      'error',
      {
        allow: ['setFilter'],
      },
    ],
  }
}

Зачем?

Вы не хотите затенения переменных, но не можете обойти это в некоторых случаях.

Почему бы и нет?

Вы действительно не хотите затенения переменных в вашей базе кода. 😝

Ответ 3

Вариант номер шесть.

6. Отключите правило es-lint для определенных строк кода

import { setFilter } from '../actions/filter';


// eslint-disable-next-line no-shadow
function FilterButton({ setFilter }) {
  return (
    <button onClick={setFilter}>Click</button>
  );
}

export default connect(null, { setFilter })(FilterButton);

или же

import { setFilter } from '../actions/filter';


/* eslint-disable no-shadow */
function FilterButton({ setFilter }) {
/* es-lint-enable */
  return (
    <button onClick={setFilter}>Click</button>
  );
}

export default connect(null, { setFilter })(FilterButton);

Второй способ временно отключить правило es-lint можно использовать для нескольких строк кода, в отличие от первого. Это может быть полезно, если вы передадите больше аргументов и разделите их на несколько строк кода.

Зачем?

Это простой и подходящий вариант для некоторых случаев использования (например, ваша команда/организация использует определенные настройки es-lint, и не рекомендуется/запрещено изменять эти настройки). Он отключает ошибку es-lint в строке (строках) кода, но не влияет на синтаксис mapDispatchToProps и правило все еще полностью активно вне строки (строк) кода.

Почему бы и нет?

Вы не хотите или вам запрещено раздувать ваш код с такими комментариями. Вы не хотите или вам запрещено влиять на поведение es-lint.