21 ноября 2016 в 17:15

React.js State of the art (интервью с Max Stoiber)



Современная разработка веб-интерфейсов сосредоточена вокруг нескольких больших сообществ. На протяжении последних пяти лет React завоевывал симпатии программистов из самых разных отраслей. React – это одна-единственная библиотека, сделавшая MVC рудиментарным в программировании веб-интерфейсов. Сегодня React используется крупнейшими компаниями для разработки самых разнообразных продуктов — Facebook, Airbnb, BBC, Coursera, eBay, Expedia, IMDB, список можно продолжать.

Одной из уникальных особенностей мира React является крупнейшее и очень активное сообщество опенсорс-разработчиков вокруг него. Max Stoiber — один из людей, благодаря которым React стал тем, чем он является на сегодня как проект. На протяжении последних нескольких лет он работал над популярнейшим boilerplate проектом в сообществе и внедрял новейшие и лучшие технологии в массовое использование.

Мы поговорили с Максом о новых веяниях в сообществе, о статической типизации для разработки с React, о новом подходе стилизации компонентов и о snapshot-тестировании.

К секретам разработки на React можно приобщиться ниже в интервью.

– Привет, Макс! Что интересного происходит сейчас в React Community?

styled-components — новый прекрасный способ стилизовать React-компоненты (разумеется, я сужу пристрастно, так как сам сделал этот проект вместе с Glen Maddern). Но если серьёзно, React VR выглядит очень многообещающе, жду не дождусь хорошего шанса опробовать его в деле.

– Flow и React – разработка Facebook, и кажется, что React-команда более склонна к flow (react-native, например, полностью покрыт flow) react тоже использует flow. Значит ли это, что лучше использовать flow с React, чем TypeScript? Может ли TypeScript быть потенциальной заменой Flow + Babel?

– В своей работе я использовал связку Flow и Babel по той простой причине, что эти два инструмента сделаны разработчиками из Facebook и, следовательно, гарантированно будут совместимы с React. C TypeScript немного другая история. В планах разработчиков Flow есть много интересных идей, от которых TypeScript будет неизбежно отставать ввиду некоторых особенностей своего устройства (например, dead code elimination).

Flow создает так называемый Flowgraph, который представляет собой граф всего приложения — он запоминает, какие модули связаны друг с другом. TypeScript не предлагает ничего подобного, потому что это слишком большая задача, Flow заходит дальше. Flow определяет, отрезаны ли большие части приложения от остальной части кода, и предлагает удалить их! Джефф Моррисон много говорил об этом на ReactEurope.

– React-boilerplate входит в топ-10 самых известных и используемых boilerplate-проектов на всем GitHub! Как ты думаешь, что сделало его столь популярным?

– React-boilerplate входит в Топ-3, если считать create-react-app. Думаю, сообщество очень помогло ему войти в первую тройку. Проект пользуется популярностью из-за активности сообщества вокруг него. Каким-то образом мне удалось обеспечить постоянный приток участников, которые проводят много времени, улучшая его. В отличие от многих других boilerplate, это не проект одного энтузиаста — это работа огромной группы людей!

При помощи react-boilerplate вы можете достаточно быстро развернуть готовую среду для разработки и тестирования вашего будущего React-приложения. Проект содержит в себе инструменты для командной строки, которые помогут вам генерировать новые компоненты для будущего приложения при помощи нескольких коротких команд! Готовая структура папок для ваших компонентов, styled-components, вся необходимая конфигурация для работы с Babel и многое другое в виде скомпилированного проекта здесь и сейчас доступны в этом проекте.

Присоединяйтесь к сообществу, рады отзывам и участию.

– Ты недавно проводил опросы про то, как люди управляют стилями в React-приложениях и css-in-js. Какие выводы ты можешь сделать? Что такое вообще css-in-js (люди понимают под этим разное)? Чем это лучше, чем просто CSS? Как стилизовать React-компоненты? Хороши ли inline-styles? Используются ли ещё BEM/OOCSS?

– Мой вывод — нам нужен более удобный способ стилизовать компоненты, именно поэтому мы и стали работать с Glen Maddern над styled-components, которые, надеемся, решат все проблемы! Используйте styled-components!

Особенность styled-components в том, что они обеспечивают использование передовых методик в ваших компонентно-ориентированных системах. Мое выступление на ReactiveConf рассказывает об этом в деталях. В двух словах, суть в том, что, избавляясь от связи между компонентами и стилями (названия классов), вы создаете целую систему небольших компонентов, которые полностью сосредоточены на выполнении одной задачи, также это помогает разграничить компоненты-контейнеры и презентационные компоненты.

Примечание автора: на сегодня styled-components не поддерживают возможности подсветки синтаксиса во всех популярных редакторах и IDE, но Макс заверил в своей презентации на ReactiveConf 2016, что в скором времени эта жизненно необходимая функциональность будет доступна в Atom, WebStorm и прочем.


– Какие инструменты для разработки c React ты можешь порекомендовать?

Redux DevTools отличный инструмент, потому что позволяют мне очень легко отслеживать все изменения, которые произошли в моем приложении, пока оно работает. В отличие от работы с другими фреймворками, например, Angular, который использует двустороннюю привязку данных, я знаю совершенно точно, что и почему происходит в моем приложении.

React и Redux DevTools просто прекрасны, очень жаль, что не все их до сих пор используют.

Примечание автора: React Developer Tools, в свою очередь, являются незаменимым инструментом для визуализации иерархии компонентов в приложении. Вы можете анализировать State, Props компонентов, не прибегая к дебаггеру и не модифицируя код.

– Если посмотреть, чем тестируют js и React в частности, голова немного идет кругом. Mocha, ava, jest, enzyme… Способов тоже несколько, shallow testing, можно использовать jsdom, недавно появились еще snapshot'ы в jest. Что нам со всем этим делать? Нет ли тут React testing fatigue?

– Не думаю, более того, большинство этих инструментов не используются исключительно для React. Инструменты для тестирования существуют уже многие годы. Я большой поклонник Jest, не только из-за того, что он сделан австрийцем (Christoph Pojer), но также и потому, что snapshot-тестирование — это настоящая революция в том, как люди тестируют React-компоненты и в тестировании вообще!

Snapshot-тесты упрощают юнит тестирование. По сути, они автоматизирует всю работу, которую раньше приходилось выполнять вручную – вы просто делаете снимок, и когда вы что-то меняете, вы можете сообщить Jest: «Да, это правильное изменение» (что будет подтверждено в ходе code review) или «Нет, все поломалось, верните как было!». Все происходит автоматически, так что делать юнит-тестирование теперь легко и быстро!

– Redux все ещё на коне? Стоит ли использовать MobX?

– Я использую в моих приложениях Redux вместе с redux-saga и очень доволен этой комбинацией.

Можно представить Saga в виде отдельного потока в приложении (JavaScript, конечно, остается по-прежнему однопоточным). Сага коммуницирует с главным потоком при помощи Action (Redux Actions) асинхронно. Для приложения неважно, что происходит после того, как кнопка нажата, оно просто запускает Action. Поток Saga может подождать, пока действие дойдет, сделать что-то, а затем отправить Action обратно — все это время наше основное приложение не подозревает, что вообще выполняется какой-то Action. Потому что, когда Saga возвращает Action, оно просто повторно рендерится, и все!

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

– Что ни возьми: CSS, тестирование, типизацию, bundling — у React куча решений. Как ты считаешь, это проблема? Все React-приложения разные, как снежинки, может, нам нужны стандарты?

– Нет, я совсем не считаю, что нам необходимы стандарты. React используется для создания сложных интерактивных приложений (по крайней мере, это его предназначение). Каждое такое приложение, ввиду своей естественной сложности, выдвигает совершенно разные требования.




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

Возможно, styled-components немного сыроваты для использования в серьезных приложениях сегодня, однако все зависит только от приложенных усилий контрибьюторов React-сообщества, которые работают над ним прямо сейчас. Дайте им полгода – или внесите собственный вклад в разработку одной из самых популярных и современных библиотек на сегодня. После разговора с Максом можно прийти к выводу, что сила React не столько в производительности или паттернах, сколько в дружном сообществе людей, открытых к новым идеям и преданных общей цели делать разработку веб-интерфейсов все лучше и эффективнее.



Если вы стараетесь следить за миром JavaScript, то ближайшее профессиональное мероприятие для вас – технологическая конференция HolyJS 2016 Moscow. На конференции будет 20 докладов, посвященных JavaScript-разработке для фронтенда, бэкенда, десктопа и даже VR.
Автор: @m1skam
JUG.ru Group
рейтинг 908,64
Конференции для программистов и сочувствующих. 18+

Комментарии (25)

  • +3
    Очевидно все идёт к переносу разметки и стилей в JS. JSX — был первым шагом, теперь styled-components. Теперь весь его boilerplate — одни сплошные js файлы. Что то в этом есть.
    • +1
      Кому очевидно и зачем так делать? А потом к тебе приходят и говорят, нужен лендинг, 1 страница, 1 форма, на бэке видео во весь экран. И ты такой, устанавливаешь реакт, тянешь всяческие styled-components. Параллельно разбираешься с очередным «left-pad». И через час ты ещё не собрал рабочую апку, да и видео на беке работает через раз. Оппа, трафик лить нельзя, деньги просраны. Не надо, никогда впадать в крайность! Вот правильно ниже про DDOS написал prostofilya
      • +3

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


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

        • +4
          Под каждым словом подпишусь. У вас как раз взвешенная точка зрения. А вот мысли вроде «Очевидно все идёт к переносу разметки и стилей в JS.» попахивают подростковым максимализмом.
  • +6
    Прям какой-то ддос хабра реактом
  • +3

    Не понимаю я этого переноса стилей в js-код. Ну понятно, что мол простые компоненты таким образом оказываются более цельными. Может оказаться, что со временем будет меньше мусора в стилях. Хотя с текущими темпами развития/изменения этого всего, стили едва ли успеют сильно "испортиться", прежде чем народ побежит всё переписывать на %newSuperWebTechnology%.


    Но ведь есть всевозможные :hover, :link/:visited, media queries, разные там переменные, общие стили и прочее. Оно ведь довольно плохо (во всяком случае на первый взгляд) с этим дружит. А с этим приходится сталкиваться в больших приложениях. И что в итоге? Превращаем наши js-файлы в большие трудно-читаемые мусорки? Или держим часть стилей в js, а часть в scss/stylus/css/less/etc?

    • 0

      Мой react ментор мне показал применение стилей в директивах import, require в jsx. никаких проблем с их применением не вижу. У него в проекте полностью самописная верстка и стили, без фреймворков, код вполне читаем.

      • 0

        Не совсем понятно, что именно вы имеете ввиду. Какую именно из модных технологий по привнесению стилей в js? Отдельные CSS файлы подключаемые webpack-ом через AMD-webpack?

  • +2
    Одной из уникальных особенностей мира React является крупнейшее и очень активное сообщество опенсорс-разработчиков вокруг него.


    Одной из уникальных особенностей мира Реакт является то, что Фейсбук имеет возможность вбухивать огромные денььги в раскрутку и пиар и таким образом задавать и контролировать вектор развития веб-разработки.
    • 0
      Так одно другому не противоречит (одно следует из другого). Ну и потом, мне никогда не нравилась ситуация «у нас четырнадцать конфликтующих стандартов, нужно сделать новый, который учтёт все-все особенности — у нас пятнадцать конфликтующих стандартов».
      • 0
        Мне тоже не нравится такая ситуация, но я не хочу чтобы Фейсбук решал как будет развиваться веб.
        • 0

          Скорее как будет развиваться веб решают те, кто решает, что использовать как на бекенде, так и на фронтенде. У меня, например, это rails + reactjs/webpack, на дружественых проектах это perl/python + angular и ember.

          • 0
            У меня другой опыт. Приходится работать с очень энергичными и продуктивными программистами, которые начинают свой день с переписывания вчерашнего «устаревшего» кода на самые новые технологии.
            • 0

              Не не не, спасибо, пусть программируют где-то в более других коворкингах под эти хипстерские смузи.
              Я считаю, что для нового проекта автор(ы) имеют прав выбирать любой стек, но здравого смысла "вот это совсем свежак, может через месяц загнуться, так что лучше остановиться на проверенном реакте/эмбере/ангуляре", это не отменяет. А так — на переправе коней не меняют.

              • 0
                >А так — на переправе коней не меняют.

                Коней не меняют. Девелоперов меняют.
  • +6
    styled-components — новый прекрасный способ стилизовать React-компоненты…
    Передовые методики...

    Серьёзно?


    Для начала, самое вкусное. В двух словах, библиотека генерит некий случайный класс, добавляет его к элементу, формирует style-тэг и добавляет в него контент вида .%имякласса% { тут из template-строки }. Идея не новая, но реализация…
    Так как стили описываются в виде строк в js-файлах, то можно использовать интерполяцию и другие фишки. Вот к чему это приводит: http://www.webpackbin.com/E1Ow20nZM


    В файле HelloWorld.js я объявляю 2 компонента, один из которых имеет кривые стили. Такое вполне может случиться с каждым, и такие кривые стили не применятся к этому компоненту, и мы, наверное, сможем найти где проблема?


    Теперь смотрим в инспектор:


    тут картинка

    image


    Круто! Косяк стилей в одном компоненте сломал стили другого.


    Представьте, что у вас большое приложение и в одном компоненте строки-стили формируются динамически. И при одном состоянии приложения всё работает нормально, а при другом стили одного компонента где-то поломались, и часть компонентов (чьи стили будут ниже или сразу за поломанным) тоже сломаются, но другая их часть будет отображаться нормально.


    Про source-map для стилей наверное даже спрашивать не стоит… Так что счастливого дебага! Искать какому из компонентов какой случайный класс соответствует будет увлекательно, особенно если компонентов за сотню.


    Использовать эту либу с обычными готовыми компонентами тоже не так просто: если компонент не был создан через эту либу, в него нужно прокинуть класс (className={this.props.className}). Если простого доступа к исходнику компонента нет (например, импортим из библиотеки), придётся писать обёртку.


    Ещё пример костылей прямо в документации: https://github.com/styled-components/styled-components/blob/master/docs/existing-css.md


    Библиотека добавляет стили в конец head, так что если вы используете внешние стили и там в качестве селектора используется один класс, то скорее всего библиотека перебьёт правила из css (т.к. скорее всего её тэг будет ниже чем стили из css-файла). Выход? Автор предлагает просто продублировать селектор в css-файле:


    /* my-component.css */
    .red-bg.red-bg {
      background-color: red;
    }

    Вот они, передовые методики! Особенно это удобно, если вы подключаете внешнюю css-либу и править стили там лучше не стоит. Но самый интересный вопрос: вес селектора .cls не очень большой, перебить его извне достаточно просто. Но как с помощью styled-components перебить вышеуказанный селектор я так и не понял.
    Ну и ещё по-мелочи. Библиотека использует простые имена классов, без префикса. Если у вас много внешних стилей, то вероятность, что styled-components сгенерит класс, имя которого уже есть в какой-то библиотеки далеко не нулевой. Забавно будет, если раз в год или месяц приложение будет спонтанно ломаться, так как имя класса совпало с селектором извне.


    Для сравнения: в ангуляре стиль каждого компонента находится в отдельном style-тэге (один компонент не сломает стили других), по-умолчанию уникальные имена имеют префикс ng и используются в качестве атрибутов (у них вес больше, так что в случае необходимости перебить внешние стили намного легче). Однако, при необходимости это поведение можно изменить как для отдельного компонента, так и для всех разом.

    • +1

      Отличный комментарий, жаль Max Stoiber его не увидит потому что Хабр не читает.


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

    • 0

      Вот то как это сделано в реакте, мне очень понравилось, поломать стили сильно сложнее

      • 0
        Вот то как это сделано в реакте

        А там как? Насколько я знаю там Inline-стили. И судя по количеству вопросов на эту тему в сети, это устраивает далеко не всех. Библиотека, упомянутая в статье, ещё одно тому подтверждение.

        • 0

          вот же описание, т.е там генерится свой особый хешик к названию класса и стилю для связки, чтобы как раз не поломать остальное — получается что если я правильно понимаю, компонент имеет свой кусок своего стиля и никак не должен мешать остальным, но варианта сломать все, это, конечно не отменяет. https://habrahabr.ru/company/jugru/blog/315772/#comment_9923636

          • 0

            Я что-то вас не понял. Вам нравится реализация стилей в реакте или в библиотеке styled-components?
            Если первое, то поломать инлайн-стили сложно, но и писать их не очень удобно. Да и правильность подхода под вопросом.
            Если второе, то поломать стили в styled-components очень легко, о чём я и написал. В ангуляре при похожем подходе гораздо сложнее.

            • 0

              В реакте.

          • 0

            Насколько я понимаю, это third-party library, а вовсе не React. В React же для стилей из своего только объекты в style-аттрибуте, как краткий синтаксис к domEl.style.

  • 0
    Стоит ли использовать MobX?

    Так стоит или нет?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка