10.03.2017 01:02
dfuse 78 12300 Источник

Каждый раз начиная писать React приложение, вы так или иначе выберите какой-то вариант:


  • копи-паст вашего предыдущего проекта
  • какой-то бойлерплейт или даже генератор (типа Yeoman)
  • готовый фреймворк не требующий конфигурации
  • пишете сами все с нуля

Каждый из способов имеет свои сильные и слабые стороны, как на длинной, так и на короткой дистанции.


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


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


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


Кандидаты



Что нужно помнить разрабатывая современное приложение


Кешируемые части


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


  • Next.js автоматически создает отдельный chunk для каждой страницы
  • Electrode, Create React App и кастом используют React Router. Webpack, в свою очередь, обладает так называемым code-splitting, который прекрасно работает с React Router. Кстати, динамические import() теперь поддерживаются Webpack 2. Для тех, кто до сих пор сидит на Webpack 1.x тоже есть решение. У Electrode в качестве решения есть специальный archetype.

Управление статикой


С одной стороны приложение должно доставить как можно больше сразу, чтоб не ходить лишний раз по сети за ресурсами (картинки, стили, скрипты), например, т.н. vendor-chunk со всеми библиотеками, важные CSS скрипты. Но в то же время мы хотим доставлять как можно меньше, только то, что необходимо на данной странице.


  • Create React App не дает модифицировать конфиг Webpack'а, так что здесь пролет
  • Next.js, Electrode и custom позволяют модифицировать конфиг Webpack'а и таким образом через плагины менять что куда попадает

Server Side Rendering


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


Google ранжирует сайты с помощью времени отклика в том числе. Не смотря на то, что поисковики умеют рендерить AJAX сайты, это плохо влияет на позицию, поэтому сайт обязан предоставлять некую версию, которую смогут переварить поисковики. С этим есть проблема, если мы захотим загрузить все данные, а не только основную контентную область, как дать понять серверному рендеру, что все загрузки закончены? Для этого пока нет сложившегося подхода. В кастомном варианте мы можем распарсить дерево компонентов и выдернуть из каждого, например, статический метод getInitialProps (по аналогии с Next.js), и когда все эти методы вернут свои значения, тогда и можно рендерить.


  • Create React App серверному рендерингу не обучен, и вряд ли когда-нибудь научится
  • У Next.js и Electrode это главная фишка
  • Если мы все строим с нуля (т.е. кастом) то и это придется построить тоже

Для того, чтобы компоненты сами могли сказать, что им нужно из данных, был придуман Relay + GraphQL, но минусы перевешивают его плюсы. Для него надо отдельный сервер. Он дико словоблуден (сама схема + мутации чудовищно громоздки). Сложность кода, который нужно написать для простейших действий практически убивает все бонусы. Объяснить это кому-то из команды с нуля тоже проблематично. К тому же потребуется специальный Babel трансформ, а также утилита для скачивания и компилиции схемы. А в результате все равно получится несовместимое с SEO нечто. Стоит признать, что если вы только потребляете существующий GraphQL API, то ситуация чуть получше. Это довольно многообещающая технология, хочется верить, что у ребят получится сделать ее более дружелюбной. Стоит еще отметить такую штуку как Apollo Framework.


Во время исследования я создал пару библиотек, которые могут помочь с Server Side Rendering:



Производительность Server Side Rendering


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


  • У Electrode есть плагин, а для боевом режиме весь код берется из предварительно скомпилированных файлов
  • Next.js ничего не предоставляет для этого пока что, но код весь компилирует и сохраняет
  • В кастомном решении, как и обычно, все придется делать самому, есть способы процесс упростить, например чере Create React Server, но сохранение компилированного кода для сервера им не контролируется
  • Create React App серверного рендеринга не имеет

CSS preprocessors


Многие пользуются LESS/SASS/Stylus/PostCSS для того, чтобы использовать переменные и микс-ины в своих стилях, так код получается чище и лаконичнее.


  • Electrode и Next.js ничего для этого не предоставляют, вы можете кастомизировать конфиг Webpack, но это крайне не рекомендуется
  • Create React App не поддерживает вовсе, и у них даже есть объяснение (TL;DR используйте композицию)
  • В кастомном проекте можно использовать обычные Webpack Loader'ы

В любом из кандидатов всегда можно создать отдельный процесс сборки/watch'а за стилями SASS/LESS, как например в Create React App, но полученный CSS нужно руками как-то подключать к приложению (в Create React App его можно импортировать напрямую). В этом случае Critical CSS и Hot Module Reloading, а также Server-Side Rendering стилей становится вашей заботой, что нивелирует преимущества не-кастомных решений.


Интеграция со сторонними UI библиотеками


Очевидно, что используя лучшие библиотеки для интерфейсов мы улучшаем вид продукта, ускоряем его создание, особенно если мы говорим о таких вещах как Twitter Bootstrap или Material Design. Эти библиотеки обычно идут в комплекте с CSS, который нужно каким-то образом включить в приложение.


  • В Next.js вы можете подключить стили напрямую в _document.js (главный шаблон), но тогда файл со стилями должен лежать в директории static; если же вы используете препроцессоры, то лучше включить CSS из-под ваших других файлов со стилями (ну а уже их подключить через кастомный _document и сборщик или кастомный конфиг Webpack)
  • Electrode позволяет импортировать CSS напрямую; так же можно через кастомный шаблон HTML (но тогда это снова надо включать в билд); или снова кастомный Webpack loader
  • Create React App разрешает импортировать CSS

Critical CSS / Above The Fold CSS


Грубо говоря, определенные стили можно загрузить вместе с HTML, таким образом пользователи никогда не увидят т.н. вспышку нестилизованного контента (FOUC). Полезно, но совершенно не критично, т.к. современные сети достаточно производительны и стилевая таблица весом до 100КБ это вообще ни о чем.


  • У Electrode есть специальный плагин
  • Next.js использует CSS in JSX поэтому CSS всегда включен непосредственно в компонент
  • Для остальных можно слепить что-то свое

Поддержка скинов


Это редкий кейс нужный далеко не всем, но многие приложения поддерживают разные скины для разных брендов или просто для удобства пользователей (ну например темная или светлая цветовая схема).


  • Next.js использует CSS в JS, поэтому можно использовать JS-подход, сделать функцию для CSS и набить стили переменными, а сами переменные получать в виде аргументов
  • Electrode использует CSS модули, которые переменных не имеют
  • Если вы используете CSS препроцессоры с некой билд-процедурой, то базовые стили можно набить переменными, создать несколько входных точек с разными оверрайдами переменных и включать одну из точек в приложение (Twitter Bootstrap так работает, например)

Экосистема и сообщество


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


  • У Electrode ~500 звезд на Github, активное сообщество отвечает на тикеты и вопросы на StackOverflow. Документация сумбурная и не очень понятная, с жутко раздутыми примерами, но если разобраться — жить можно.
  • У Next.js ~9000 звезд на Github, супер быстрый отклик на пулл-реквесты и тикеты. Есть документация для простых и сложных случаев, огромное количество примеров на все случаи жизни.
  • У Create React App ~21.500 звезд на Github, это самое большое сообщество. Сам фреймворк настолько мелкий и примитивный, что там документировать даже особо нечего, однако авторы умудрились написать кучу примеров и рецептов.
  • В кастомном приложении вы сами по себе, все примеры, документация, сообщества раскиданы по всему интернету, все нужно искать, самому выбирать толковые решения, и вы получаетесь единственным носителем знания, что очень плохо для компании. Документацию Вам придется так же писать самому.

Тесты


Думаю уже никто не будет спорить, что в современном мире без тестов вообще никуда.


  • Electrode использует PhantomJS для честных браузерных тестов и отдельные серверные тесты, это лучшее покрытие из возможных
  • Create React App поставляется вместе с Jest, он хорош, но не запускается в браузере, поэтом как бы не совсем честное покрытие
  • Для Next.js и кастома все делаем сами

Boilerplate, конфигурация, начальная стоимость


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


  • Next.js и Create React App идут вообще без конфигурации, просто разложите нужные файлы в соответствии с соглашением и все магически заработает
  • Electrode идет в комплекте с генератором для Yeoman который выдает просто чудовищно огромную гору файлов, придется потратить время на то, чтоб привыкнуть, что где лежит. В этой горе буквально все: конфиги, код сервера, код для серверных страниц, клиентский код, и пока я не нашел способа хоть как то это оптимизировать.
  • Кастом всегда будет иметь некоторое количество кода, от которого не избавиться. Но если вы делаете десятки проектов, то в какой-то момент у вас должны сформироваться некие повторяющиеся паттерны, которые можно переместить в абстракцию. И может даже опен-сорснуть ;). Честно говоря, это же можно сделать и с Electrode, и мне кажется, они и сами к этому придут.

Кривая обучения в начале и в сложных случаях, сложность кастомизации, поддержка в будущем


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


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


  • Create React App самый простой для понимания в начале, но он вообще не дает никаких средств для модификации. Его исходный код довольно суров, поэтому если вы планируете сделать “eject” (то есть вынуть все скрипты для сборки, все конфиги и прочие кишки наружу), то лучше сразу откажитесь от этого направления в пользу кастома. В комплект поставки входит linter. Поскольку API вообще отсутствует, а количество соглашений минимально — апгрейды пройдут безболезненно.
  • Next.js заботится о некоторых аспектах, понимение того, как именно он это делает, потребует немного времени. Большинство простых кейсов имеют примеры, однако когда требуется что-то сложное или нестандартное — проще застрелиться, код превращается в кашу и сдабривается большим количеством шатких сторонних решений. По большому счету любой шаг в сторону грозит болью. Linter в комплект не входит. Схожая картина с апгрейдом, API минимален, соглашения легко соблюдать.
  • Поскольку Electrode сильно базируется на конфигурации и большинство скриптов открыты с самого начала, это вызывает легкий шок в начале, но как только вы со всем разберетесь — жить быстро станет проще. Таким образом для более сложных случаев вы будете лучше подготовлены. К сожалению, под капотом все равно происходит порядочное количество колдунства, поэтому совсем легко не будет никогда. В комплект входит отлично настроенный ESLint. Здесь с апгрейдом все похуже. Поскольку количество кишок, торчащих наружу, довольно велико, то шанс что-то сломать в будущем тоже велик.
  • В кастоме вы сами по себе. Как сделаете, так и будет. Сами ищете лучшие практики, сами подбираете решения, и так с начала и до последнего дня проекта. С агрейдом все вообще совсем плохо, что угодно может сломаться когда угодно.

Интернационализация


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


Ни один из представленных фреймворков не дает никаких средств для перевода. Однако, их несложно добавить. После поисков я выяснил, что централизованный асинхронный загрузчик работает лучше всего, в таком случае каждый язык становится отдельным chunk'ом. Добиться этого можно создав функцию, которая принимает язык как параметр и отдает асинхронно загруженные строки для языка. Что-то типа const loadStrings(lang) => import('./strings/'+lang) (данная конструкция вряд ли сразу заработает, но суть должна быть понятна, перед ней можно еще насоздавать Webpack Context'ов, чтоб гарантировать связку 1 язык = 1 чанк.


Библиотеки: FormatJS и Format Message (и та и та работает с так называемым ICU Format).


Организовывать строки лучше всего по токенам, т.е. {TOKEN: {en: 'English', fr: 'French'}}, так проще для разработчиков и переводчиков. Обратный подход, где "как бы токеном" является английская строка себя не оправдал.


Сравнение


Дисциплина \ Название React App Electrode Next.js Custom
Dynamic Routes да да DIY да
Server rendering нет да да DIY
SSR optimization нет SSR да нет DIY
CSS да да ночной кошмар DIY легко
Preprocessors ночной кошмар ночной кошмар ночной кошмар DIY легко
Critical CSS DIY плагин нет DIY
Сообщество большое есть есть ты сам по себе
Тесты jest phantom DIY DIY
Код основы ноль много ноль очень много
Конфигурация ноль много ноль очень много
Документация хорошая так себе в наличии разрозненная
Обучение простому сел и поехал приемлемо легко ночной кошмар
Дальнейшее обучение проще умереть тяжело тяжело ночной кошмар
Движок сервера nginx node node node
Кастомизация eject и смерть приемлемо ночной кошмар все что угодно
Первоначальная установка легко словоблудно легко ночной кошмар
Предсказуемость хорошая так себе плохая ночной кошмар
Апгрейды шикарно неплохо так себе ночной кошмар

Вердикт


Если вы не собираетесь заниматься серверным рендерингом (вы ничего не продаете, приложение не индексируется гуглом, и вообще приватное), то можете смело смотреть в сторону Create React App, он самый популярный и простой. Его даже можно немножечко кастомизировать. Только eject не делайте, оно того не стоит.


Если серверный рендеринг нужен, и вы готовы смириться с кое-какими ограничениями, то выбирайте Electrode (в качестве условия вас так же не должны пугать большое количество файлов, словоблудность и конфигурации). Это так же хороший выбор, если вас беспокоит производительность.


Если вы готовы мириться с еще большими ограничениями и любите минимализм, то присмотритесь к Next.js.


Ну и наконец, всегда есть кастом. К счастью, библиотеки типа Webpack Blocks, Create React Server, React Router, Redux и прочие делают жизнь сильно проще. Единственная проблема это обмен знаниями и выработка процессов для быстрого создания приложений без повторения одного и того же кода каждый раз.

Поделиться с друзьями
-->

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


  1. comerc
    10.03.2017 04:38
    #10110964
    +3

    Create React App — мой выбор! Долго перебирал-сравнивал. Важно, что самый необходимый набор и реализация скрыта. Обновления пройдут безболезненно.


    1. dfuse
      10.03.2017 04:44
      #10110968
      +1

      Вы правы, я к этому же пришел, это мое решение по-умолчанию. Но как же серверный рендеринг? ;)

      В принципе, обновления Next.js будут примерно так же проходить, там довольно минималистичный API.


      1. Ronnie_Gardocki
        10.03.2017 09:17
        #10111074
        +1

        Серверный рендеринг не везде нужен. У изоморфного рендеринга по сути дела 2 преимущества — индексация и снижение нагрузки на клиент, если для рендеринга данных требуются дата-процессинг и подобные вещи (аля всякие мудреные чарты с кучей около-реалтайм данных и прочее).

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


        1. dfuse
          10.03.2017 10:23
          #10111204

          Добавлю еще кейс — логин страница сама по себе вполне может нуждаться в серверном рендеринге, если вы планируете показывать ее в WebView ваших мобильных или десктопных приложений. Там скорость загрузки и отображения критична.

          В остальном согласен.


          1. yhaskell
            10.03.2017 19:55
            #10112186

            В принципе, в данном юзкейсе можно отказаться от заведения сервер-рендеринга: срендерить её один раз и оставить статическим файлом. Заведение SSR для одного маленького кусочка существенно усложняет код без особенной пользы — discuss?


            1. dfuse
              10.03.2017 19:59
              #10112196

              Если на странице есть динамические запросы данных, то один раз через билд процедуру собирать будет мало. В других случаях может сработать.


      1. comerc
        10.03.2017 12:09
        #10111462
        +1

        И вместо того, что вдохновенно кодить, я снова выбираю инструменты. :)


      1. comerc
        10.03.2017 17:25
        #10111968

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


        Положил взгляд на Electrode. Вроде как всё по феншую. Смотрится несравнимо солиднее, чем Next.js Пока можно попробовать без сервера. Но само наличие сервера радует. Я хочу туда PostgreSQL прикрутить, уж очень камрад нахваливает. Не нашел на этот счет примеров. Конкретно — посредством pg-promise. Ещё не разобрался, но могу предположить, что обнаружу дополнительные бонусы от связки родных клиента и сервера.


        Electrode позволяет импортировать CSS напрямую.

        Смущают CSS-модули, можно ли от них отказаться без страданий?


        Что предлагается для сайд-эффектов? redux-saga я тоже не хочу использовать. Мой выбор — thunk.


        Вопросы озвучены. Цели поставлены. За работу!


        1. dfuse
          10.03.2017 19:48
          #10112166
          +1

          Про Postgres тут статья была Uber — причины перехода с Postgres на MySQL.

          Я лично везде использую promise middleware и thunk, хватает для всего. Saga рассматривал, но мне не понравился API, который как-то тяжеловат и словоблуден, а так же генераторы.


          1. comerc
            10.03.2017 22:04
            #10112318

            Про Postgres тут статья была Uber — причины перехода с Postgres на MySQL.

            Я сидел три года на PostgreSQL давным давно. Это еще и вопрос ностальгии. Никакие доводы не помогут. :)


          1. comerc
            10.03.2017 22:06
            #10112322

            везде использую promise middleware

            Вот это redux-promise-middleware?


            1. dfuse
              10.03.2017 22:23
              #10112342
              +1

              Да.


          1. raveclassic
            10.03.2017 22:57
            #10112364

            Любопытства ради, можете рассказать, почему не срослось с генераторами? И еще, если ли большой проект, где promise/thunk покрыты тестами? Удобно ли тестируются? Ну, точнее, так ли удобно, как саги?
            Мне просто в свое время показалось дико неудобным, пришлось «смириться» с сагами, ибо rx-стримы как-то совсем перегружено смотрелись. Сейчас же после некоторого времени использования, саги не кажутся чем-то сверхъестественным.


            1. dfuse
              10.03.2017 23:40
              #10112398

              Генераторы лично мне кажутся менее удобными и понятными, чем промисы. А если использовать async/await то все еще более просто.

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


              1. raveclassic
                10.03.2017 23:58
                #10112406

                Ну, самое основное отличие async/await от генераторов (хотя работает первое почти так же, как второе) в том, что async/await — по сути, генератор, «размотанный» в промис. Ммм… ну я даже, не знаю, как по-другому сказать. Т.е. когда вы await'ите async-функцию, вы явно выполняете все ее await-точки, тогда как генератор дает вам чуть больше гибкости, и позволяет подсмотреть результат каждой этой точки.

                Собственно, идея саг в том, что вы в этих точках не вызываете какие-то функции с сайд эффектами, сервисы и т.п. напрямую, а описываете декларативно «что должно быть выполнено». Это называется декларативными эффектами, которые при прямом вызове генератора не выполняются, их выполняет redux-middleware тогда, когда считает нужным.

                Так вот, описываются эти вызовы с помощью простеньких хелперов из пакета redux-saga. Вызов этого хелпера в yield возвращает просто json-описание, что и как должно быть выполнено. Соответственно, не трудно догадаться, что тестируется это все на ура обычным deepEqual. В отличие от тестирования прямых вызовов сайд-эффектов, когда вам нужно замокать все ваше окружение. Т.е. на уровне юнита, вы раскрываете тесту, что этот юнит использует и вызывает. Или даже хуже, что использует и вызывает тот или иной сервис, который использует этот юнит. Или еще хуже и глубже…

                Можно кстати провести прямую аналогию с Elm, так как там все ровно то же. Вместо middleware там рантайм, а «вместо» декларативных эффектов — обычные ADT.

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


                1. raveclassic
                  11.03.2017 00:06
                  #10112416

                  Кстати, попробуйте затранспайлить бабелем async/await в генераторы — удивитесь, насколько все похоже.


                1. comerc
                  15.03.2017 12:59
                  #10119024

                  А где бы еще почитать про генераторы и redux-saga, посоветуете лучшее?


                  1. raveclassic
                    15.03.2017 13:52
                    #10119174
                    +1

                    По сагам лучшим решением будет почитать офф доки, там достаточно внятные и полезные примеры. А вот специализированной литературы нет, кроме статей на всяких медиумах уровня hello-world, так как техника достаточно нова для js, требует ментального сдвига, да и просто не так раскручена, как остальные решения.

                    А по генераторам, ну… это генераторы, они везде одинаковые, пойдет любая статья. Тут главное уловить концепцию. Функция-генератор при прогоне через .next снаружи «приостанавливается» на каждом своем yield, чтобы через него сначала «выбросить» наружу какое-то значение «справа» от yield, а затем «принять» значение снаружи через .next и отдать «налево». Т.е. у вас появляются новые точки входа вместо обычной схемы «передать аргументы на входе, получить значение на выходе». Функция-генератор может быть представлена в виде «процесса», как конечного, так и бесконечного, если внутри есть while (true). Именно на этих «процессах» и построены саги.


        1. VitalyT
          10.03.2017 21:10
          #10112264
          +1

          С pg-promise все очень просто ;) Если застряните — есть масса саппорта, включая форум: https://gitter.im/vitaly-t/pg-promise

          Можно и на русском тут спросить: https://gitter.im/vitaly-t/russian, или на StackOverflow где я всегда отвечаю.

          Я автор pg-promise ;)


          1. comerc
            10.03.2017 21:49
            #10112294

            Это был ключевой момент выбора, что автор — свой человек. Спасибо!


        1. comerc
          11.03.2017 01:21
          #10112464

          Жир. Архитипы скрывают реализацию, как и в Create React App.


          Только я так не понял, как подключить в WebStorm из архитипа .eslintrc, пока просто копирую в проект.


          1. raveclassic
            11.03.2017 01:25
            #10112472
            +1

            В шторме же можно указать прямой путь до конфига, даже из нод-модулей. И последние eslintrc вроде должны поддерживать extends


          1. dfuse
            11.03.2017 01:35
            #10112480
            +1

            Архетипы, в отличии от CRA, конфигурируемы.
            .eslintrc можно экстендить


            1. comerc
              11.03.2017 01:57
              #10112486

              из архетипа electrode-archetype-react-app-dev выдрал


              .eslintrc-node (для сервера)


              ---
extends:
  - "walmart/configurations/es6-node"
parserOptions:
  # this is not in the Walmart default configuration, for fairly good reason:
  # V8 (and thus Node) does not support ES6 import syntax. Server-side code
  # is transpiled, but this is not reflected in tests.
  sourceType: "module"
rules:
  "strict": ["off", "global"]
  "no-process-exit": ["off"]
  "func-style": ["off"]

              .eslintrc-react (для клиента)


              ---
extends:
  - "walmart/configurations/es6-react"
globals:
  window: false
  document: false
  ReactElement: false
rules:
  "react/jsx-boolean-value": "off"
  "react/jsx-closing-bracket-location": "off"
  "react/no-string-refs": "off"
  # disable invalid rules from walmart default configs:
  "react/wrap-multilines": "off"
  "react/jsx-wrap-multilines": "error"


  1. x07
    10.03.2017 09:32
    #10111088

    Create React App это не фреймворк, а обычный генератор кода. И вообще термин фреймворк в отношении реакта неуместен.


    1. VolCh
      10.03.2017 09:40
      #10111102

      И вообще термин фреймворк в отношении реакта неуместен.

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


      1. x07
        10.03.2017 13:09
        #10111572
        -1

        А что у термина фреймворк множество определений?


        1. VolCh
          10.03.2017 14:00
          #10111664
          +1

          Да. Даже в русской вики минимум два.


    1. dfuse
      10.03.2017 10:20
      #10111198

      Create React App это как раз вполне фреймворк, т.к. по определению это каркас или структура, облегчающая разработку. В более широком смысле — набор разноплановых библиотек особым образом связанных вместе. Уж точно не генератор кода, Yeoman — вот генератор. Реакт — не фреймворк, в этом Вы правы.


      1. x07
        10.03.2017 12:57
        #10111550
        +1

        А Yeoman разве на выходе не дает вам каркас и структуру облегчающую разработку?
        Как создается проект с помощью create-react-app?

        create-react-app my-app

        Читаем что написано в readme.md на github
        It will create a directory called my-app inside the current folder.
        Inside that directory, it will generate the initial project structure and install the transitive dependencies:

        А тут написано что это утилита которая генерирует структуру проекта.

        Как создается проект с помощью Yeoman?
        yo шаблон-реакт-вебпак-и-все-что-необходимо

        На выходе имеем так же организованную структуру проекта, где так же достаточно набрать npm start и все взлетит.
        В чем отличия? Следуя вашей логике Yeoman это тоже фреймворк всех фреймворков.


        1. dfuse
          10.03.2017 19:54
          #10112178
          +1

          Ладно. Create React App — генератор приложения на фреймворке React Scripts :) но поскольку никаких других приложений, кроме как на React Scripts, он не умеет генерировать, то вся эта связка условно названа фреймворком.


  1. VolCh
    10.03.2017 09:37
    #10111098

    Create React App самый простой для понимания в начале, но он вообще не дает никаких средств для модификации.

    Всё же даёт. create-rect-app состоит по сути из двух частей: собственно утилита создания приложения и react-scripts. И во время создания, и позже можно изменить "коробочный" набор на любой сторонний или свой форк, включив всё что нужно и исключив ненужное, прежде всего в конфиги вебпака и бабеля. Если речь о разработке "на потоке", когда приложения создаются часто, но целевые конфиги одинаковы, то очень удобно, стандартизирует процессы разработки и инструментарий в команде.


    1. dfuse
      10.03.2017 10:17
      #10111194

      В сравнении с остальными — не дает. Конфиг вебпака же нельзя менять без eject, следовательно способов модификации довольно мало. Про форки и тд речь специально не идет, иначе бы пост раздулся раз так в 100. Так что упрощение сделано сознательно.


      1. VolCh
        10.03.2017 11:26
        #10111332

        Всё же это штатная возможность указать конкретный набор скриптов


  1. http3
    10.03.2017 10:24
    #10111208

    За статьи по React-у платят деньги? :)


    1. dfuse
      10.03.2017 10:28
      #10111218

      Если бы ))) я проводил исследование в рамках проектной деятельности и решил поделиться результатами.


    1. bjornd
      10.03.2017 11:39
      #10111358

      За программирование на не-React'е не платят деньги?


      1. http3
        10.03.2017 16:00
        #10111854

        Эээ, статья != программирование :)


  1. renya
    10.03.2017 11:20
    #10111312

    > Create React App не дает модифицировать конфиг Webpack'а, так что здесь пролет

    А как же eject? :)


    1. dfuse
      10.03.2017 11:24
      #10111324

      А зачем тогда Create React App, если делать eject? Проще уж с нуля самому все писать или пользоваться другим фреймворком. В статье об этом было замечание.


      1. VolCh
        10.03.2017 11:27
        #10111336

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


        1. dfuse
          10.03.2017 11:41
          #10111364

          Это будет довольно мало что могущая структура, вы не находите? А ещё ее надо будет потом поддерживать, обновления накатывать. Оно того не стоит, вся прелесть CRA в режиме без конфига.


          1. VolCh
            10.03.2017 12:00
            #10111434

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


            1. dfuse
              10.03.2017 12:04
              #10111444

              Eject? Вы шутите. Он же ничего не умеет особого, вам придётся кучу всего добавлять руками, причём в каждом новом проекте. Возьмите лучше тогда NextJS если нравится без конфигурации, или Electrode, там есть генератор, чтоб руками не писать и не копи-пастить. Статья же ведь именно об этом. Нельзя замыкаться на одном решении.


              1. VolCh
                10.03.2017 12:13
                #10111472

                Создаешь приложение с create-react-app, разрабатываешь его пока не уткнёшься в ограничения, а дальше решаешь или делать свою ветку скриптов, или использовать стороннюю (например есть готовые с поддержкой stage-0 и less/sass, постоянно синхронизирующиеся с оригиналом), или сделать eject.


                Тот же кодогенератор по сути, набрасывающий основу проекта.


                1. aon24
                  14.03.2017 13:49
                  #10116894
                  +1

                  Самый разумный подход (не только в программировании).


                1. comerc
                  14.03.2017 14:07
                  #10116946

                  Меня вдохновил Electrode на пару дней. Но вернулся обратно на CRA. И продолжаю фигачить на скорость. Ограничение инструментария повышает продуктивность. Парадокс.


      1. renya
        10.03.2017 11:28
        #10111338

        Но всё равно нет «пролета», как вы написали.


        1. dfuse
          10.03.2017 11:53
          #10111414

          Без eject пролёт, редактировать же нельзя, как в Next или Electrode. А после Eject жизни нет ;)


  1. MrCheater
    10.03.2017 11:39
    #10111360

    Зря вы наговариваете на Next.js, что там роутинг плохой.
    Там же на серверной стороне можно юзать express https://github.com/zeit/next.js/blob/master/examples/custom-server-express/server.js
    И с помощью него парсить такие пути /items/:id и всё прекрасно.


    Препроцессоры для CSS там тоже есть https://github.com/zeit/next.js/tree/master/examples/with-styled-jsx-postcss — подключайте PostCSS плагины, какие хотите


    1. dfuse
      10.03.2017 11:50
      #10111408
      +1

      Этот пример не работает в случае с подстановками, я проверил первым делом. Next первый раз страницу загружает, а потом у него что то сбивается и вместо новых чанков будут приходить 404 ошибки. И текущую ссылку не подсветить, у них на это баг есть открытый. Для этого есть отдельные решения.

      PostCSS плагины это все же не полная поддержка любых препроцессоров.


    1. ainu
      10.03.2017 13:07
      #10111566
      +1

      PostCSS это не препроцессор.


      1. bjornd
        10.03.2017 13:50
        #10111650

        JFYI:

        PostCSS is a tool for transforming styles with JS plugins. These plugins can lint your CSS, support variables and mixins, transpile future CSS syntax, inline images, and more.
        …
        Plugins
        …
        Better CSS Readability
        — precss contains plugins for Sass-like features, like variables, nesting, and mixins.


  1. 6095959
    10.03.2017 19:54
    #10112180

    А что с кроссплатформенностью?
    Есть возможность собирать «из коробки» электрон — кордову?


    1. dfuse
      10.03.2017 19:54
      #10112182

      Одно другому вроде как не помеха.


    1. comerc
      11.03.2017 21:08
      #10112946

      *электрод


      Только зачем, когда есть React Native?


      1. 6095959
        12.03.2017 11:48
        #10113430

        Разумеется, есть много чего кроме реакта.

        Но вопрос был по статье «Что взять за основу React приложения», чтобы собирать приложения также и для мобильников и для десктопа.


        1. comerc
          12.03.2017 12:04
          #10113448
          +1

          Один мальчик хотел написать мобильное приложение на Cordova. Потратил $130 долларов, и получил тормознутый прототип из трех функций через полгода. Показывать такое потенциальным инвесторам просто стыдно.


          React Native — это лучшая основа React-приложения для мобилок.


          1. 6095959
            12.03.2017 13:47
            #10113612

            А другой мальчик просто набрав npm run build:cordova через пару минут получил готовую мобильную версию своего реакт приложения, которая сейчас успешно функционирует.

            Интересно, а на что конкретно полгода то ушло ?)


            1. comerc
              12.03.2017 14:00
              #10113632

              На офис в Черногории, зарплата: PM, аналитик, дизайнер, два разработчика и два тестировщика.


              1. 6095959
                12.03.2017 14:07
                #10113638

                Взял бы сразу React Native, и ничего бы этого не потребовалось?

                Кстати, на нем десктоп приложения под винду делать можно? Нативно, или с электроном подружить как-то?


                1. comerc
                  12.03.2017 15:04
                  #10113736

                  React + Electron


  1. inickua
    11.03.2017 19:35
    #10112898

    Что лучше всего подойдет для проектов на основе Django/Python/REST/I18N — Next.js, Electrode или свой кастом лучше собирать. Сделал свой выбор в пользу ReactJS и теперь стоит задача в ближайшем будущем переписывать интернет-магазин с поддержкой мультиязычности и с полным использованием REST (Django REST framework, GraphQL и т.д), изоморфизмом и для дальнейших проектов. Теперь вопрос в том как это все связать, что взять за основу, чтобы в дальнейшем было как можно меньше головняков в ходе разработки и поддержки. В общем практики нет, поделитесь своим опытом с сочетанием Django/I18N/REST/ReactJS и т.д., какие инструменты выбрать?


    1. dfuse
      11.03.2017 19:36
      #10112900

      Решать Вам на основе Ваших требований, серебряной пули не существует.


      1. inickua
        11.03.2017 20:45
        #10112932

        А какой лучше и проще вообще как для новичка по Вашему опыту выбрать — Next.js, Electrode. Я застопорился на том что инструментов и библиотек много, в статьях и гайдах больше пишут про одно и тоже абсолютно по своему и по разному, из-за чего мало что понимаешь и в голове плохо укладывается как это объединить и подружить. Но с другой стороны хочется инструментария из коробки, единой архитектуры пускай и с ограничениями, теперь только остается сделать выбор Electrode или Next.js, чтобы в этом случае посоветовали как для начинающего?


    1. comerc
      11.03.2017 21:05
      #10112942

      Create React App, прекрасен тем, что нет ничего лишнего — сел и поехал.


      Когда в Create React App станет тесно, перенести в Electrode — никаких проблем, реализация окружения скрыта точно так же, как и в Create React App. Но добавятся: SSR, изоморфность, утилиты.


      I18N — мне нравится такое.


      GraphQL (Relay) попробовал, это кошмар. Redux — окончательный правильный выбор! :)


      Остальное из моего набора: Redux-Form, Redux-Auth, Axios, Redux-Promise-Middleware, Redux-Thunk, Reselect, Redux-Act, Immutable-JS, Material-UI, React-Select.


      1. inickua
        11.03.2017 21:28
        #10112968

        Спасибо! Теперь я так понимаю что по своей структуре Electrode больше совместим с Create React App, а на Next.js сложней будет перенести, но по нему больше документации. Я думаю может быть начать для практики с Create React App а дальше перенести если мало функционала будет на Electrode или Next.js. Или в принципе можно начать сразу с Electrode или Next.js если с нуля все изучаю. Для меня сейчас главное определиться с чего начинать или попробовать и то и другое, а затем уже определиться что больше по душе. Но в Electrode получается что в начале кошмар с первоначальной настройкой, зато больше свободы и возможностей по кастомизации и расширению, в Next.js легкий старт, меньше головняка в настройках, больше автоматизации но за это расплата — ограничения.


        1. comerc
          11.03.2017 21:36
          #10112976

          Вы пытаетесь судить по фотокарточке, начните с малого.


          1. inickua
            11.03.2017 21:48
            #10112986

            Ну да как-то получается :), самое главное что теперь знаю с чего вообще можно начинать, т.к. основная проблема была — это изоморфизм и способы его отдельной реализации, ну и советы знакомых которые пишут на React по кастому (бойлерплейты + webpack) ни к чему не приводили, один совет и ответ что можно только часть сделать, например поиск и какие-то фильтры, но полностью писать — это бредовое дело и самоубийство.


            1. comerc
              11.03.2017 21:56
              #10112990

              Я тоже сначала пробовал взлететь со всем вот этим. Никак!


            1. inickua
              11.03.2017 22:00
              #10112992

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


        1. comerc
          11.03.2017 21:42
          #10112982

          Быстрое погружение в React и Redux.


        1. comerc
          11.03.2017 21:46
          #10112984

          Вот это самая лучшая статья по React+Redux из тех, что я перелопатил.


          1. inickua
            11.03.2017 22:40
            #10113020
            +1

            Огромное спасибо, будем учить и разбираться :)


      1. dfuse
        12.03.2017 07:14
        #10113184

        На днях разбирался с Relay — это чудовищная мерзость. Но я нашел прекрасное решение Apollo: https://github.com/kirill-konshin/react-ssr-playground/tree/master/graphql, вот моя демка, я скрестил демо-блог для GraphQL с сервером и клиентом на Apollo.


  1. inickua
    12.03.2017 01:02
    #10113096

    А какие еще существуют известные и стабильные решения кроме Electrode и Next.js для основы React приложений?


    1. raveclassic
      12.03.2017 01:17
      #10113100

      Как показывает практика, лучшее решение — понимание принципов работы стэка на реакте и вебпаке на низком уровне. Чем глубже это понимание, тем лучше, так как рано или поздно вы 100% столкнетесь с ситуацией, когда коробочное решение будет вам жать. И гнуться оно будет очень с трудом.

      Для старта и CRA, и Next.js, и Electrode, и <все, что угодно> — хороший выбор, но я бы все-таки рекомендовал инвестировать время, чтобы разобраться, как работают эти инструменты на низком уровне. После этого у вас не возникнет проблем ни с в выбором технологии обработки сайд-эффектов, ни с SSR, ни с менеджментом стейта, ни с настройкой HMR, ни с ручным развертыванием удобного инструмента для разработки компонентов а-ля react-storybook, ни с чем-либо еще.

      Да, это требует времени, но, да, это того стоит.


      1. inickua
        12.03.2017 01:35
        #10113110

        Да, Вы правы, я похожий путь проходил когда работал HTML/JS верстальщиком, понадобилось время чтобы осознать как обрабатывает браузер внешние/внутренние отступы и прочее, или как было тяжело когда привык только к Twitter Bootstrap (собственно говоря меня сразу за него посадили и сказали что тебе больше не надо знать), а когда понадобилось написать проект на фрилансе чисто в ручную, я понял что ничего не знаю, было и смешно и обидно.