Не знаю как конкуренты, но Wordpress уже довольно давно продвигает версию своего продукта как Headless (или api-first) CMS.
Но вообще в последнее время популярность набирают headless варианты: облачные CMS (SaaS, где панель управления предоставляется сторонней компанией, например Contentful) и SSG-фреймворки типа Gatsby. В обоих случаях хостить нужно только статический сайт - html, картинки и т.п. И работает это конечно существенно быстрее чем любая CMS. Но такого обширного коммьюнити и различных плагинов, конечно, пока нет. Ну и дизайн нужно самому пилить, готового тут тоже мало. В общем не для личного бложика системы.
в монолите получить высокую связность гораздо проще и сложнее отслеживать эти самые связи. Но конечно, следить за связностью нужно и там и там, это скорее вопрос архитектуры, который в данной статье не рассмотрен и к теме монолит/микрофронтенд не совсем относится.
Я бы не стал на микрофронтендовые модули ставить прикоммитный хук с линтером и тестами. У меня в одной либе стоит билд и преттифай и каждый коммит уже занимает в районе минуты. Линтинг и тесты лучше проверять в CI на пулл-реквесте и не давать мержить пока всё не поправят.
Мне тоже кажется, что не нужно всё подряд тянуть в стор. Но в данном случае моё мнение прямо противополжно мнению автора. Я считаю, что данные, которые мы берём с бэкенда - должны быть в сторе. И логика получения этих данных должна быть отделена от компонентов, отвечающих за представление этих данных. Я уже многократно сталкивался с ситуацией, когда данные предназначенные для одного компонента внезапно становятся нужны где-то в другом компоненте. Если данные в сторе - никаких проблем. Если данные грузятся прямо из компонента - нужно прикручивать кэш или переносить всё в стор. Что действительно не нужно тянуть в стор - так это внутреннее состояние компонентов, состояние открытия поповера или текущий слайд в слайдере и т.п.
Ну в отдельных случаях, конечно, имеет смысл так делать. И, в общем-то, если посмотреть на интерфейсы многих библиотек, то можно увидеть в каких. Но я бы не стал этот приём как бест практис рекомендовать и все параметры на объект заменять, как предлагается в этой статье.
неплохие советы за исключением второго. Если пользоваться Typescript или Flow и прописывать JSDoc в особо важных случаях, то никаких проблем с порядком переменных у внимательного разработчика быть не должно. Явная передача параметров делает вызов функции понятнее и чище. К тому же это даёт возможность «каррировать» функцию. А вот подход, описаный тут, может привести к багам в гораздо большем количестве случаев.
Остальные советы вполне полезные, особенно про использование хуков. Хотя про оборачивание часто используемых компонентов в хуки — мне кажется немного бесполезным. Зачем хук если сам компонент может следить за своим состоянием? Зачем плодить сущности и усложнять, если можно просто использовать компонент обёртку с состоянием?
исторически сложилось или просто чтобы стек технологий был как у других, даже когда это не особенно нужно. Но в общем-то это тоже отображает определённую степень популярности библиотеки.
Сравнивать хуки и редакс не совсем корректно. Я, например, использую в своих проектах и хуки и редакс, как это отобразится в статистике? Представить себе большое приложение целиком написанное на хуках и конексте мне сложно. Но и без хуков, на одном редаксе приложение будет перегружено различными пропсами и хэндлерами.
Отчасти я согласен с автором, что набирать в коллектив только «лучших из лучших» — это ущербный подход. И в том, что у любого человека должны быть и другие интересы, часто несвязанные с программированием. Лично я программирую и в свободное от основной работы время, поэтому у меня, наверное, есть что показать. В то же время, я бы не стал это показывать, потому, что когда я делаю что-то для себя, я часто не заморачиваюсь над качеством кода, иногда откладываю это до рефакторинга, который может и не наступить. И показывать такой код потенциальному работодателю стрёмно.
Поэтому я чаще просто прошу дать мне тестовое задание.
Как поступать, когда один GET запрос с динамическим :id в url, используют множество компонентов, на одном экране?
Не совсем понятен вопрос, но я думаю нужно использовать независимое от приложения кэширование по конечному url, что-то вроде ladda.io. и поставить это всё в воркер.
И что, ваш пример у пользователей на винде тоже будет работать?
А веб интерфейс в опен-сорс не пойдёт? Было бы интересно посмотреть как решаются, например, разные слои в коде и т.п.
Не знаю как конкуренты, но Wordpress уже довольно давно продвигает версию своего продукта как Headless (или api-first) CMS.
Но вообще в последнее время популярность набирают headless варианты: облачные CMS (SaaS, где панель управления предоставляется сторонней компанией, например Contentful) и SSG-фреймворки типа Gatsby. В обоих случаях хостить нужно только статический сайт - html, картинки и т.п. И работает это конечно существенно быстрее чем любая CMS. Но такого обширного коммьюнити и различных плагинов, конечно, пока нет. Ну и дизайн нужно самому пилить, готового тут тоже мало. В общем не для личного бложика системы.
В Германии тоже аналогичная система работает. Приложение, правда, не очень удобное, но работает вполне удовлетворительно.
в монолите получить высокую связность гораздо проще и сложнее отслеживать эти самые связи. Но конечно, следить за связностью нужно и там и там, это скорее вопрос архитектуры, который в данной статье не рассмотрен и к теме монолит/микрофронтенд не совсем относится.
ну не обязательно при мерже все коммиты сохранять, есть же squash
Я бы не стал на микрофронтендовые модули ставить прикоммитный хук с линтером и тестами. У меня в одной либе стоит билд и преттифай и каждый коммит уже занимает в районе минуты. Линтинг и тесты лучше проверять в CI на пулл-реквесте и не давать мержить пока всё не поправят.
Мне тоже кажется, что не нужно всё подряд тянуть в стор. Но в данном случае моё мнение прямо противополжно мнению автора. Я считаю, что данные, которые мы берём с бэкенда - должны быть в сторе. И логика получения этих данных должна быть отделена от компонентов, отвечающих за представление этих данных. Я уже многократно сталкивался с ситуацией, когда данные предназначенные для одного компонента внезапно становятся нужны где-то в другом компоненте. Если данные в сторе - никаких проблем. Если данные грузятся прямо из компонента - нужно прикручивать кэш или переносить всё в стор. Что действительно не нужно тянуть в стор - так это внутреннее состояние компонентов, состояние открытия поповера или текущий слайд в слайдере и т.п.
Остальные советы вполне полезные, особенно про использование хуков. Хотя про оборачивание часто используемых компонентов в хуки — мне кажется немного бесполезным. Зачем хук если сам компонент может следить за своим состоянием? Зачем плодить сущности и усложнять, если можно просто использовать компонент обёртку с состоянием?
Поэтому я чаще просто прошу дать мне тестовое задание.
Не совсем понятен вопрос, но я думаю нужно использовать независимое от приложения кэширование по конечному url, что-то вроде ladda.io. и поставить это всё в воркер.