В данной статье речь не про бойлерплейт, потому что create-react-app создает совершенно минимальный каркас, который бойлерплейтом с натяжкой можно назвать, все пишется с нуля руками за 5 минут, а про работу одним скриптом почти без настроек, по аналогии с react-scripts.
Я тут сравнивал в статье разные фреймворки, и на мой взгляд, чем меньше бойлерплейта — тем лучше. В случае с Next.js или Create React App сама экосистема вообще не заметна, ноль конфигурации (в Next.js можно ее вытащить, если сильно надо), для Electrode надо некоторое кол-во конфигов и бойлерплейта, и это уже вызывает вопросы, как это поддерживать. Но и гибкости в тех, где нет конфигов — поменьше. Но иногда и это на пользу идет, меньше ненужных телодвижений, когда все нельзя. Бойлерплейты все имеют неустранимый недостаток — после инициализации проект уходит своим путем, а бойлерплейт — своим. Нельзя просто взять и синхронизировать проект с последними наработками автора бойлерплейта. А CRA и Next с Electrode — можно, любые оптимизации, которые вносят авторы, будут Вам доступны.
Apollo и GraphQL для потребления прекрасны, для написания своего сервера — тоже хороши, но есть нюансы, особенно если клиент не только вы сами, т.е. нужен еще и REST ;). Ссылку Вашу посмотрю, спасибо.
По логике — ядро = нечто неделимое, некая базовая единица функциональности (ядерную физику в расчет не берем). Роутер, по-идее — это уже не совсем ядро, приложение же может выжить без него, если оно консольное. А вот обработка ошибок — вполне.
В любом случае тут стоит подойти творчески и сбалансировать гранулярность, например, по принципам high cohesion и single responsibility (и другим подобным), чтобы вещи одной предметной области были в одном модуле, но без фанатизма, чтоб не пихать все подряд.
Если гранулярность довести до абсолюта, то получаются NPM пакеты isNumber и так далее ;) а если наоборот — то Yii Framework.
Независимые компоненты — штука хорошая, но у независимости есть цена. Приходится отказываться от переиспользования кода из ядра фреймворка, что выливается в довольно большой объём кода как такового и, зачастую, переабстрагированные решения.
А кто мешает ядро сделать тоже независимым компонентом? И переиспользовать его как угодно. В итоге получится эдакий шаг в сторону Zend Framework или Symfony.
Я ни в коем случае не агитирую немедленно так и поступить, Yii его монолитность даже на пользу, просто изначальное утверждение довольно спорное.
На днях разбирался с Relay — это чудовищная мерзость. Но я нашел прекрасное решение Apollo: https://github.com/kirill-konshin/react-ssr-playground/tree/master/graphql, вот моя демка, я скрестил демо-блог для GraphQL с сервером и клиентом на Apollo.
Смотря как прикручивать. Для него есть react snapshot пакет, который делает статический сайт, обходя все ссылки. Но оно не работает с Redux. Есть моя миддлвара для Router + Redux, с ней хлопот не очень много, но продукт относительно свежий, хоть и крутящийся на продакшене. Next/Electrode более матерые, но и ограничений там порядком. Попробуйте сами разные варианты, быстро станет очевидно, какой Вам больше подходит.
Слабо распространен, миддлвары не поддерживает, производительность плохая, плюсов как-то не видно. Я как-то к Hapi прикручивал Webpack Dev Server, в итоге просто забил после двух дней беспросветных поисков и прикрутил через proxy, т.е. стало два сервера на разных портах. Но это давно было, сейчас может быть проще уже.
Все к нему прикручивается, только не в 2 строчки, вот пример, как на моей же миддлваре это можно сделать. Сайты делают разные люди, а не только Вы или я, не все хотят знать, как оно работает изнутри.
Ладно. Create React App — генератор приложения на фреймворке React Scripts :) но поскольку никаких других приложений, кроме как на React Scripts, он не умеет генерировать, то вся эта связка условно названа фреймворком.
Я лично везде использую promise middleware и thunk, хватает для всего. Saga рассматривал, но мне не понравился API, который как-то тяжеловат и словоблуден, а так же генераторы.
В данной статье речь не про бойлерплейт, потому что
create-react-appсоздает совершенно минимальный каркас, который бойлерплейтом с натяжкой можно назвать, все пишется с нуля руками за 5 минут, а про работу одним скриптом почти без настроек, по аналогии сreact-scripts.Я тут сравнивал в статье разные фреймворки, и на мой взгляд, чем меньше бойлерплейта — тем лучше. В случае с Next.js или Create React App сама экосистема вообще не заметна, ноль конфигурации (в Next.js можно ее вытащить, если сильно надо), для Electrode надо некоторое кол-во конфигов и бойлерплейта, и это уже вызывает вопросы, как это поддерживать. Но и гибкости в тех, где нет конфигов — поменьше. Но иногда и это на пользу идет, меньше ненужных телодвижений, когда все нельзя. Бойлерплейты все имеют неустранимый недостаток — после инициализации проект уходит своим путем, а бойлерплейт — своим. Нельзя просто взять и синхронизировать проект с последними наработками автора бойлерплейта. А CRA и Next с Electrode — можно, любые оптимизации, которые вносят авторы, будут Вам доступны.
Apollo и GraphQL для потребления прекрасны, для написания своего сервера — тоже хороши, но есть нюансы, особенно если клиент не только вы сами, т.е. нужен еще и REST ;). Ссылку Вашу посмотрю, спасибо.
По логике — ядро = нечто неделимое, некая базовая единица функциональности (ядерную физику в расчет не берем). Роутер, по-идее — это уже не совсем ядро, приложение же может выжить без него, если оно консольное. А вот обработка ошибок — вполне.
В любом случае тут стоит подойти творчески и сбалансировать гранулярность, например, по принципам high cohesion и single responsibility (и другим подобным), чтобы вещи одной предметной области были в одном модуле, но без фанатизма, чтоб не пихать все подряд.
Если гранулярность довести до абсолюта, то получаются NPM пакеты
isNumberи так далее ;) а если наоборот — то Yii Framework.А кто мешает ядро сделать тоже независимым компонентом? И переиспользовать его как угодно. В итоге получится эдакий шаг в сторону Zend Framework или Symfony.
Я ни в коем случае не агитирую немедленно так и поступить, Yii его монолитность даже на пользу, просто изначальное утверждение довольно спорное.
.eslintrc можно экстендить
С тестами никаких проблем, это же просто промисы, из них можно выстроить любую цепочку диспатчей, параллельных, последовательных, любых.
Я лично везде использую promise middleware и thunk, хватает для всего. Saga рассматривал, но мне не понравился API, который как-то тяжеловат и словоблуден, а так же генераторы.