Пишем API для React компонентов, часть 3: порядок пропсов важен

[kalyukdo]

Даже не знаю что сказать, просто оставлю это здесь

classnames

const Link =({className, ...props}) => {
  return (
    <a {...props} className={className + ' link'} />
  )
}

[IvanGanev]

А можно вообще забыть про className и юзать styled-components.
Статья, все таки, не про стили и классы, а про подходы.

[kalyukdo]

но вы же приводите примеры именно на классах :(

1. Разработчик, использующий наш компонент, должен иметь возможность переопределить значение пропа по умолчанию
3. Разработчик должен иметь возможность добавлять значения, при этом сохраняя значение по умолчанию

для этого можно использовать деструктуризацию из моего кода выше

а вот если

2. Мы не хотим позволять разработчику менять некоторые пропсы

зачем вообще тогда принимать такие пропсы снаружи?
больше смахивает на «Сначала мы производим грабли, а потом бьемся о них головой»

[IvanGanev]

Эм, если что, это перевод.

для этого можно использовать деструктуризацию из моего кода выше

Можно, но смысл примеров в том что бы явно показать разные подходы.

зачем вообще тогда принимать такие пропсы снаружи?

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

[kalyukdo]

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

ну вот допустим вы подписали грабли атрибутом «color» и запретили его переопределять, а разработчик передает пропс «colors» — вы же не будете все гипотетические варианты указывать?

Эм, если что, это перевод.

Неважно Ваша ли это статья или тем более если это перевод, в данной статье нет ничего связанного с подходом, а тем более с «Пишем API для React компонентов», это всего лишь кусок из документации Typechecking With PropTypes

[vit134]

К теме не относится, но в последнем примере неправильно используется setState.В данном случае, было бы правильнее передавать в setState функцию, в которую прокидывается текущее значение state, а вторым параметром передавать callback, который гарантированно выполниться только после изменения state.

this.setState(
  state => {
    const enabled = !state.enabled;

    return { enabled };
  },
  () => console.log(this.state.enabled)
);

В вашем примере на момент выполнения onClick значение state может быть еще не изменено.

Спасибо за статью!