Новичок В: Есть ли наилучшая практика для настраиваемых параметров имени свойства и обратного вызова onChange?

Когда я пишу свои собственные пользовательские компоненты, мне нужно вызвать один из реквизитов, предоставленных контейнером, чтобы сигнализировать об изменении значения, обрабатываемого компонентом. Но вместо e мероприятия у меня есть newValue под рукой. Поэтому я хочу назвать это так:

props.propname(newValue)

Теперь, есть ли соглашение React / лучшая практика для propname?

Для входных данных DOM свойство onChange вызывается с параметром события, обычно называемым e. Как будто это вызывается так:

props.onChange(e)

Нужно ли мне:

  1. Назовите свойство чем-то другим, кроме onChange, так как оно принимает параметры, отличные от onChange событий для элементов DOM. Что-то вроде: props.onMyComponentChange(newValue) (или что-то другое, имеющее смысл для компонента).
  2. Используйте то же имя и вызовите: props.onChange(newValue). Лучшей практикой является то, что реквизит называется onChange, но он может принимать разные параметры в зависимости от компонента.
  3. Создайте как-нибудь событие e и все равно звоните onChange(e) (в дикой природе такого не видел)

Я быстро проверил компоненты реакции npm и увидел множество 1 и 2. При написании новых пользовательских компонентов существует ли установленная передовая практика для того, как называть такую ​​поддержку?

Обновлен ответ, основанный на повторном прочтении вашего вопроса... :) Надеюсь, это поможет...

SakoBu 27.05.2019 13:39
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Навигация по приложениям React: Исчерпывающее руководство по React Router
Навигация по приложениям React: Исчерпывающее руководство по React Router
React Router стала незаменимой библиотекой для создания одностраничных приложений с навигацией в React. В этой статье блога мы подробно рассмотрим...
Массив зависимостей в React
Массив зависимостей в React
Все о массиве Dependency и его связи с useEffect.
0
1
62
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Думайте о props как об именах переменных... Вы должны быть как можно более явными с ними... Независимо от того, используете ли вы classes или hooks под капотом, даже классы по-прежнему являются функциями... Переменные имеют область видимости функции, поэтому вы конфликтов не будет...

Однако по мере роста вашего приложения у вас будет целая куча onSubmits и handleSubmits повсюду, и вы потратите кучу времени, пытаясь выяснить, какой из них относится к какому компоненту/контейнеру.

Ваши замечания о том, чтобы быть явным и помогать в обслуживании, упрощая поиск нужной опоры, имеют смысл. Так, например. для выбора даты onDateChange имеет больше смысла, чем onChange по нескольким причинам. Я пойду с подходом on${someting}Change. Спасибо, @SakoBu!

Peter V. Mørch 28.05.2019 09:03

Другие вопросы по теме