Синтаксис класса ES2015 для компонентов React ухудшает удобство разработки и упрощает обслуживание с небольшой выгодой взамен.

В React 15.5.0 React.createClass официально устарел. К сожалению, его объявление заменяющего компонента - и новый стандарт сообщества - имеет значительно худший опыт разработки, создает сложность в использовании и сопровождении кода, а взамен получает лишь незаметно-небольшой прирост производительности в большинстве случаев.

Каждый инженер идет на компромисс. Мы могли бы написать веб-интерфейс Netflix на чистом, чистом, оригинальном JS, но мы выбрали React, потому что накладные расходы на фреймворк стоили простоты использования и безопасности, которые были с ним связаны.

Ключ к написанию хорошего кода - это правильные компромиссы, и переключение синтаксиса класса ES2015 для компонентов React просто не работает.

В ES2015 с React.createClass

Давайте посмотрим на пример компонента, начиная с React.createClass.

Первое, что вы читаете после имени компонента, это propTypes, значения по умолчанию, любой требуемый контекст и состояние компонента - по сути, все, что вам нужно знать о входных данных и значениях по умолчанию, находится прямо впереди.

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

Еще одно преимущество этого объявления состоит в том, что все, что касается компонента, содержится в вызове createClass. Если вы нажмете последнюю закрывающую скобку, вы все это увидите.

В ES2015 с родными классами

Вот тот же компонент, написанный с синтаксисом класса ES2015 - как указано в документации React.

Вы заметите, что длина компонента увеличилась, но что мы получили за эти дополнительные строки?

  • PropTypes, значения по умолчанию и контекст должны быть присоединены после того, как компонент определен, похоронив большинство самодокументируемых аспектов компонента в конце файла, при этом начальное состояние отделено где-то еще.
  • Теперь необходимо помнить о вызове super (), иначе мы получим синтаксическую ошибку.
  • handleClick должен быть вручную привязан в конструкторе или привязан во время использования, иначе мы получим неправильное «this» и ошибку времени выполнения.
  • S« немного лучшая производительность в больших приложениях », которая, по-видимому, во многом зависит от того, как ваше приложение использует компоненты. Если вы переходите на ES5, вы уже запускаете намного кода больше, чем вы, вероятно, ожидаете…

Немного лучшее будущее с предложенными полями классов

В настоящее время существует предложение этапа 2 с TC-39 для добавления множества классных функций. Что наиболее важно для React, это касается инициализаторов свойств, которые дают нам гораздо более сжатое объявление, возвращая некоторые преимущества удобочитаемости React.createClass.

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

Мы можем использовать толстую стрелку ES2015, чтобы пропустить внутреннюю привязку «this» и вместо этого обратиться к экземпляру.

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

Так что лучше, но мы все еще боремся, чтобы вернуться туда, где мы были с простым createClass.

Но в конце…

Почему мы, как сообщество, вносим это изменение? Что мы, разработчики или наши пользователи, получаем от перехода на классы ES2015 для компонентов React?

Это производительность?

  • Да, удаление React.createClass уменьшает размер библиотеки React на 2–3 КБ, но перенесенный код класса в средних и крупных проектах может быстро это преодолеть.
  • Пропуск автосвязывания может в некоторых случаях привести к незначительному увеличению производительности, но опять-таки результат перфоманса для транспилированного кода часто добавляется обратно.

Легко ли это для разработчика?

Читая приведенные выше примеры кода, нет никаких оснований для повышения удобства использования или поддержки или более четкого разделения между специфичными для React свойствами определения компонента.

Так почему мы это делаем?

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

Последующие действия и обновления

Я получил некоторые отзывы и вопросы по этой статье, которые я хотел бы обсудить в теле, так как мудрые люди, как правило, пропускают комментарии.

«Он ближе к нативному JS, так что так лучше»

Я не совсем уверен; это уже не очевидно для того, чтобы быть родным JS, и вводит значительный шаблонный код, умственные издержки и второстепенные случаи. Такие вещи, как state, propTypes и context по-прежнему являются магическими и необходимыми, поэтому, во всяком случае, разделение некоторых из них на встроенную статику JS устраняет их явную связь и важность для библиотеки.

«Почему это важно? Люди просто запомнят нужные фрагменты и двинутся вперед ».

В какой-то степени я согласен. Мы все можем адаптироваться, и если синтаксис класса ES2015 - лучший выбор для вашей группы или он заставляет вас чувствовать себя более комфортным языком, полностью дерзайте! Больше всего я хотел сказать, что, как мне кажется, сообщество пришло к решению, которое казалось лучше и новее, но было чистым отрицательным из-за общего опыта разработчиков и аспектов ремонтопригодности.

Часть моей работы в Netflix связана с производительностью разработчиков, поэтому я заинтересован в создании библиотек и фреймворков, которые были бы наиболее простыми в использовании и обслуживании для самой большой группы людей, но при этом оставались открытыми для расширения в более сложный для написания / сопровождения код, когда производительность или ограничения требуют этого. Я думаю, что сохранение React.createClass в качестве стандарта сообщества по умолчанию при открытии синтаксиса класса ES2015 в качестве дополнительной надстройки при необходимости было бы лучшим выбором для сообщества и кодовых баз, с которыми они работают. По крайней мере, я думаю, что им следовало подождать до тех пор, пока предложение по полям классов не появится или не войдет в более позднюю стадию с TC-39.

«Netflix ненавидит синтаксис класса?»

Я видел пару мест, где этот пост был озаглавлен что-то вроде «Netflix обнаружил, что синтаксис класса - отстой». Нет, не знали. Я сделал.

Одна из главных сильных сторон инженеров Netflix - это разнообразие наших взглядов. Я не мог возможно выступать от имени всех инженеров в Netflix - или даже всей команды веб-сайтов, в которой я работаю.

Часть нашей культуры устанавливает контекст, а не требует контроля, и причина, по которой я написал этот пост, заключалась в том, чтобы распространить часть контекста, как я это вижу, на более широкое сообщество. Мы можем пережить это конкретное решение, но одни и те же типы решений и предложений будут возникать снова и снова в наших собственных проектах или в библиотеках и фреймворках, которые нам небезразличны; вдумчивое обсуждение того, чем мы торгуем в UX и DX, всегда приведет к лучшему.