Преобразование моего компонента на основе классов в функциональные компоненты с помощью хуков

Я новичок в хуках, мне очень нравится, как хуки дают нам возможность иметь состояние в функциональном компоненте с помощью useState (), useEffects (), useReducer. () и т. д., я также знаю, что всегда полезно использовать функциональный компонент везде, где это возможно, и ограничивать использование компонентов на основе классов на уровне контейнера, чтобы удерживать состояние корня или ветви в дереве компонентов, он гарантирует, что только несколько компонентов управляют нашим состоянием и им легко управлять.

Мой вопрос: Почему я должен предпочесть использовать хуки, а не использовать вместо этого компонент на основе классов, в чем польза от этого?

Я планировал реорганизовать существующую базу кода, преобразовав многие из моих компонентов на основе классов в функциональные компоненты с помощью ловушек, но я хочу знать, стоит так делать? ответы, которые я получаю, помогут мне принять решение.

Я уверен, что в этом есть преимущество, но не уверен, почему бы вместо этого не использовать компонент на основе классов?


person Praveen Rao Chavan.G    schedule 18.02.2019    source источник
comment
Непопулярное мнение: в компонентах класса нет ничего плохого. Компонент и хуки без сохранения состояния прекрасны по всем причинам, описанным Noriste ниже, но вот несколько причин, по которым я предпочитаю использовать классы joshpitzalis.com/defaults < / а>   -  person Josh Pittman    schedule 18.02.2019


Ответы (1)


Мой вопрос: почему я должен предпочесть использовать хуки и вместо этого не использовать компонент на основе классов, в чем польза от этого?

В основном для:

  • читабельность / краткость: в большинстве случаев вы предпочитаете использовать компоненты на основе классов для выполнения простых задач (контролируемые компоненты ввода, простые варианты выбора / параметры пользовательского интерфейса), и для этого вы как правило

    • add some interaction (onCLick, onChange) handlers
    • добавьте конструктор для привязки их к текущему компоненту, и если вы реализуете побочные эффекты, вы начинаете использовать методы жизненного цикла React, такие как componentDidMount, componentDidUnmount и т. д.
      вашего компонента становится все более и более подробным, просто чтобы делать простые вещи.

      Хуки могут помочь вам уменьшить эту многословность с помощью более простого для чтения, более краткого и более читаемого компонента. Строки кода больше не на 20% -50% посвящены структуре классов (определение, методы и т. Д.) Только для того, чтобы обернуть ваш собственный код ... но являются ~ 100% непосредственно вашим кодом.
  • простота: хуки позволяют писать очень простые и атомарные побочные эффекты / логику состояния, которые вы можете подключить к своим компонентам через некоторое время. Чтобы добавить поведения / функции к сверхпростым компонентам, вам не нужно преобразовывать их в классы, «заставляйте» себя использовать один из шаблонов React (компоненты высшего порядка, свойства рендеринга и т. Д.), Который, особенно в начале, сделать React настолько сложным, чтобы попасть на борт

  • повторное использование логики с отслеживанием состояния: хуки настолько просты и подключаемы, что вы смешиваете их и добавляете богатые / сложные функции, не беспокоясь о них (на самом деле хуки могут использоваться только в функциональных компонентах и ​​в ... других самих хуках )

  • тестируемость: это серьезная проблема, но она также может быть важна. В то время как хуки смешивают логику представления с логикой состояния (пользовательский интерфейс и состояние / побочные эффекты больше не разделяются), хуки могут быть разработаны как супер простые для тестирования функции как таковые (независимо от того, считаете ли вы, что модульное тестирование хорошее или плохое) .

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

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

Постарайтесь не добавлять абстракции слишком рано.

и прочтите "useEffect не componentDidMount + componentDidUpdate + componentWillUnmount" в Сообщение Кента. Есть некоторые противопоказания, о которых вы должны знать, прежде чем это делать.
Вместо этого: подумайте об использовании хуков для каждого будущего компонента вместо рефакторинга старых.

Так что сделайте несколько проверок и тестов, прежде чем делать это, и рефакторинг вашего компонента только тогда, когда вы освоите хуки ????

p.s. Я процитировал HOC и т. Д. Шаблоны реакции: они остаются действительными и полезными, и для них достаточно много места, просто вы не обнаружите, что используете их для простых вещей, которые в них не нуждаются.

p.p.s. если вы привыкаете к React Hooks, вам может быть полезен мой меморандум, Я написал его для всех, кто уже прочитал документацию и суммирует наиболее важные материалы о хуках (связанные с документами и т. Д.)

person NoriSte    schedule 18.02.2019
comment
Большое спасибо за такой подробный ответ, это очень полезно :) - person Praveen Rao Chavan.G; 18.02.2019
comment
Пожалуйста, я только что добавил ссылку на свой меморандум , Надеюсь, это может быть полезно ???? - person NoriSte; 18.02.2019