Реагировать - Внутренние функции внутри функциональных компонентов

ProgramBox

Реагировать — Внутренние функции внутри функциональных компонентов

Post author:admin
Запись опубликована:13 апреля, 2023
Post category:Вопросы по программированию

#reactjs #jestjs #react-hooks

#reactjs #jestjs #реагировать-хуки

Вопрос:

У нас в команде есть обсуждение функциональных компонентов и внутренних методов. Позвольте мне показать вам пример

Это был бы способ, которым одна часть команды хотела бы его использовать:

 const ShowMeComponent = () => {
  const [isVisible, setVisible] = useState(false);
  const onClick = () => setVisible(!isVisible)
  return (
    <div>
      <button onClick={onClick}>Toggle Visibility</button>
      {isVisible amp;amp; <div>I am visible!</div>}
    </div>
  );
};

Именно этого хотела бы другая часть команды:

 const onClick = (isVisible: boolean, setVisible: YouHaveToTypeIt) => (e: ClickEvent) => setVisible(!isVisible)

const ShowMeComponent = () => {
  const [isVisible, setVisible] = useState(false);
  const onClickClosure = onClick(isVisible,setVisible)
  return (
    <div>
      <button onClick={onClickClosure}>Toggle Visibility</button>
      {isVisible amp;amp; <div>I am visible!</div>}
    </div>
  );
};

Итак, на мой взгляд, код становится менее читабельным, и вам предстоит больше работы, потому что вам приходится вводить функции, которые вы перемещаете за пределы компонента.
Я не вижу никаких недостатков в выполнении
const onClick = () => setVisible(!isVisible)

Один из аргументов, которые они используют, заключается в том, что при перемещении функций за пределы компонента вы можете легко их модульно протестировать. Но разве мы не должны рассматривать компонент как единое целое? Также в документации я не вижу ничего плохого, связанного с методами внутри функциональных компонентов.

Пожалуйста, дайте мне знать ваши мысли.

С наилучшими пожеланиями

1. Ну, setVisible(!isVisible) это даже не правильный способ изменить состояние в зависимости от текущего состояния. Вам нужно использовать версию обратного вызова setVisible(visible => !visible) . 🙂 Этот подход позволит вам переместить функцию мутации за пределы компонента const toggle = visible => !visible и выполнить модульное тестирование. В общем, вам не следует изменять свой код для его тестирования. И обычно вы не хотите тестировать детали реализации, такие как внутреннее состояние компонента и обработчики, вы хотите протестировать поведение компонента: т.Е. пользователь щелкает переключателями div.

2. Я полностью согласен, что изменять код для тестирования и делать его менее читаемым глупо. Итак, вы согласны с тем, что мы должны рассматривать компонент как единицу?

3. Полностью. Но в случае, если функция изменения состояния достаточно сложна, чтобы выделить ее в отдельный модуль, вы можете извлечь ее из компонента и протестировать.

Ответ №1:

Я считаю, что первое более подходит, чем второе. Вы правы, компонент должен рассматриваться как единое целое во время тестирования.

Последнее не только менее читаемо, но и неоднозначно и привело бы к проблеме утечки памяти, если бы не было обработано достаточно хорошо. В конце концов, вы используете метод setVisible класса, не создавая его объект.

1. Не могли бы вы рассказать мне больше об утечке памяти?

2. Вы используете setVisible вне компонента, в котором он объявлен. Таким образом, любой может вручную присвоить значение с помощью метода, что приведет к катастрофе. Вот почему, пока метод setVisible не вызывается изнутри самого класса, было бы опасно работать. Это не очень хорошая практика и никогда не рекомендуется из-за этого фактора риска.