EFS_programm Jan 23 2018 at 12:59

Советы по стилю. Как написать читаемый React-код

5 min

9.1K

Сбер corporate blogJavaScript*Programming*ReactJS*

Comments 10

Mihail72 Jan 24 2018 at 09:29

При реализации stateless components рекомендую использоать storybook, для описания возможных состояний.
Разработчик видит возможности использования и узкие места
UX Дизайнер может спрогнозировать поведение

Luanre Jan 24 2018 at 11:10

Верное замечание, storybook отлично подходит для проектов на начальном этапе. По мере развития проекта, функциональности может не хватать. В ЕФС мы используем собственное решение для генерации гайдлайнов на базе Confluence: текст стягивается из Conflunce, в специальных вставки отрисовываются React-компоненты. Такой подход позволяет разнообразить гайдлайны, даже если человек никогда в своей жизни не видел исходный код.

vtvz_ru Jan 24 2018 at 10:51

Может быть я что-то упустил, но в мобильном хабра-приложении «приведенного выше примера» я не вижу.

Кстати о тестировании. Работаю совсем один над крупным проектом (бывает и такое). Тесты пишу не всегда, но иногда они (те, что есть) просто спасают. Бывает что-то отваливается или просто что-то забываю вернуть, это сразу отображается в результатах тестов. Особенно вдохновляют acceptance тесты, где можно посмотреть на живой браузер и скриншот с ошибкой.

Ещё момент: некоторые плагины под eslint для ReactJS (по крайней мере тот, которым пользуюсь я) буквально заставляют добавлять displayName компонентам-функциям. С одной стороны это удобно при отладке. Но с другой стороны `export default () => Hi!` смотрится лаконичнее.

Также использую подход с декораторами: некоторые компоненты являются обертками для других, используются как декораторы (`@something`) и в displayName указывается `DecoratorsName(ChildComponentName)`. Идея не нова: уже давно используется в react-redux и react-form. Я использую данный подход для bem классов. Можно использовать для темизации. Очень удобно.

SPAHI4 Jan 30 2018 at 01:50

зачем bem, когда есть css modules?

vtvz_ru Jan 30 2018 at 12:55

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

SergeyGalanin Jan 24 2018 at 12:32

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

Luanre Jan 25 2018 at 14:57

У нас используется собственная разработка, которая складирует все ошибки в БД для последующего анализа. Сам сервис доступен всегда по определенному URL'у.

shura-sparrow Jan 25 2018 at 14:55

В статье упомянут Typescript. Пробовала пользоваться им в своем проекте, возникло непонимание, а нужен ли он. Типизация — это здорово, но если есть тип any, типизация заканчивается. Кроме того, время разработки увеличивается со всеми описаниями типов и установкой тайпингов. В целом, на мой взгляд, получается небольшая польза.

taliban Jan 26 2018 at 15:59

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

UFO just landed and posted this here