Когда я пишу свои собственные пользовательские компоненты, мне нужно вызвать один из реквизитов, предоставленных контейнером, чтобы сигнализировать об изменении значения, обрабатываемого компонентом. Но вместо e
мероприятия у меня есть newValue
под рукой. Поэтому я хочу назвать это так:
props.propname(newValue)
Теперь, есть ли соглашение React / лучшая практика для propname
?
Для входных данных DOM свойство onChange
вызывается с параметром события, обычно называемым e
. Как будто это вызывается так:
props.onChange(e)
Нужно ли мне:
onChange
, так как оно принимает параметры, отличные от onChange
событий для элементов DOM. Что-то вроде: props.onMyComponentChange(newValue)
(или что-то другое, имеющее смысл для компонента).props.onChange(newValue)
. Лучшей практикой является то, что реквизит называется onChange
, но он может принимать разные параметры в зависимости от компонента.e
и все равно звоните onChange(e)
(в дикой природе такого не видел)Я быстро проверил компоненты реакции npm и увидел множество 1 и 2. При написании новых пользовательских компонентов существует ли установленная передовая практика для того, как называть такую поддержку?
Думайте о props как об именах переменных... Вы должны быть как можно более явными с ними... Независимо от того, используете ли вы classes
или hooks
под капотом, даже классы по-прежнему являются функциями... Переменные имеют область видимости функции, поэтому вы конфликтов не будет...
Однако по мере роста вашего приложения у вас будет целая куча onSubmits
и handleSubmits
повсюду, и вы потратите кучу времени, пытаясь выяснить, какой из них относится к какому компоненту/контейнеру.
Ваши замечания о том, чтобы быть явным и помогать в обслуживании, упрощая поиск нужной опоры, имеют смысл. Так, например. для выбора даты onDateChange
имеет больше смысла, чем onChange
по нескольким причинам. Я пойду с подходом on${someting}Change
. Спасибо, @SakoBu!
Обновлен ответ, основанный на повторном прочтении вашего вопроса... :) Надеюсь, это поможет...