"Проброс ошибок является операцией которая должна сообщать о непредвиденной работе приложения. " - Не обязательно, те же самые async await к примеру (можно долго спорить). Это делает валидацию немного удобней (когда начнется валидация сложных объектов, строки дают сбой и просто не поймете где ошибка/ошибки). Можно использовать объекты со статусами, переменные передаваемые по ссылке, использование логера ошибок и прочие подходы. Бытует мнение что try catch медленнее работает (скорее всего так, но тут вопрос объема).
"Почему все проверки синхронные " - хоть про это уже и писали, но лучше заложиться, что проверки могут быть асинхронные (просто перед функцией валидации сделать async и потом надо будет меньше подпрыгивать - хоть это редко встречаемый кейс, но последствия не приятные). Вообще была идея делить такие валидации на синхронные и асинхронные, но такая реализация не прижилась в виду малого выигрыша и усложнения кода.
"Мы просто привыкли к этим инструментам и часто воспринимаем как что-то глобальное и незыблемое." - Хорошие слова, хорошее заключение, жаль что мы катимся в бездну)
Добро пожаловать в мир неописанной боли). Билды я так понял у вас строятся через tsc (я обычно использовал webpack), но в целом есть и другие варианты сборки (правда документации маловато и лучше искать по сторонним схожим пакетам). Возможно стоит посмотреть esbuild (как пример используется в vue/core для билда). Есть так же возможность запустить esm в cjs через esm-to-cjs (вроде был этот пакет и это на всякий случай).
Как по мне Rpc идет своим путем и этот путь менее популярен (пока что). В целом я видел проекты где есть и Rest и Rpc и они живут в одном проекте. А вот углубляться в сеть, когда это вопрос 50 строк кода и в формат данных (пусть еще 50 строк), это не целесообразно (для человека который пишет простой метод). Это вопрос оптимизации. Для браузера, мобильных приложений пока HTTP 1.1 + JSON, реже сокеты. Для общения между сервисами gRpc.
А теперь мы поднимаем образно 4 урла "/rpc" "/rest" "/soket" "/grpc" и один и тот же код работает везде (правда под rest и soket придется по мучаться дольше). Джуны пишут простые методы (getNewsList, getNewsById). Мидлы дописывают дополнительные валидационные штуки и другие более сложные вещи. Сеньеры решают что и как гонять, в каком формате, как настроить права доступа + другие попутные вещи.
А вывод, транспорт влияет на время выполнения, но никак не должен влиять на логику и нужно иметь возможность его поменять.
Я хотел написать чтиво выходного дня (чтоб народ мог подумать и не читать много). По большому счету это описание слоев (которые можно сделать на любом языке для rpc), пример как выглядит метод и немного о том, что не обязательно писать 500+ строк кода, ради одного метода. Про плюсы и минусы для Rpc - их уже озвучили тысячу раз.
Можно было бы углубиться, что схема для валидации это круто, удобно, многофункционально. Не обязательно получать из данных простые типы (например можно сразу получить объект пользователя по полю user_id), но это не изменит точку зрения людей. Пока не напишут свой велосипед, не успокоятся (увы такая реальность и это нормально). Не исключаю и поклонников готовых библиотек.
Говорить что json-rpc 2.0 морально устарел и его не хватает для нормального общения... это не для хабра...
Если про Go, то я столкнулся с проблемой, что первые 3 слоя влияют на слой валидации (если хочется оптимизации), но это детали языка. В целом соглашусь с тем, что генерация кода - это довольно интересная вещь, но это не популярно у простого народа на php и в ряде других языков (если не брать во внимание фреймворки), хотя в далекие времена писал сборщики js файлов и какие то мини генераторы.
статья выглядит неполной какой-то. Идея изложена, но пюсов/минусов не видно, применения тоже. Типа, читайте сорцы
Я хотел дописать какие то главы, но сейчас понимаю, что на это нет смысла тратить время, так же как и писать трехтомный пост. Про плюсы - гибкость (можно заменить слой в ядре, добавить или убрать), минусы - вам захочется или придется писать свой велосипед (для примера можно посмотреть сорцы). А лить воду, кидать кучу года из исходников, говорить "я сделал хранилище запросов" и другие банальные вещи - это не цель этой статьи.
В любом случае спасибо и я рад, что я не один такой)
Увы, но это не протокол, как и REST. Просто набор каких то размытых правил. Дальше есть надстройки как протокол SOAP, спецификация JSON-RPC 2.0 и не будем упускать gRPC. Я так понял народу больше интересно первые три слоя, которые размывают границу, как передается, в каком формате и в какой структуре.
Пример Rpc метода с авторизацией приведен для того чтоб показать как это можно оформить (не авторизацию, а сам метод). А основная суть, что мы его за 20-30 строк кода, оформляем в полноценный метод который можно вызвать клиентом (при чем с валидацией данных), например так:
Я понял что статья не зашла (по крайней мере сообществу), все равно спасибо. Я не хотел писать трехтомный пост и углубляться в каждый уголок. Да автогенерация отсутствует, но по факту, вам нужно писать только 1 отдельный класс для каждого метода. Обработка ошибок - если не усложнять, то блок try catch в котором находиться вызов всех слоев с отдельным классом ошибки. Вот с сериализацией все гораздо интереснее, можно прикрутить json-rpc, а можно общаться xml (мало ли), можно доставать данные из get параметров и тд... По факту за это отвечают первые 3 слоя (откуда достать, как достать и какая структура) и они кладут вам все это в класс запроса метода.
А для чего вы задаете этот вопрос, какая польза от этого вопроса и ответа на него? Я б не стал углубляться в это. Если задача завалить кандидата, то наверно js это самое лучшее, что можно придумать. Я не имею ничего против данной статьи (прочел, классно, через месяц забуду, может быть когда то вспомню), но я против бесполезных вопросов на собесе.
Честно говоря, те кто хотят сделать первый свой сайт не понимают зачем он (есть облачные надежды, что сделав сайт, клиенты потекут рекой...). Это была бы более интересная тема (многим хватает лендинга и многие не готовы поддерживать интернет магазины). Кто то осознано отказывается делать сайт (по общавшись со мной) в сторону готовых площадок (авито, вк, юла и тд...).
Выбор исполнителя - это всегда рулетка (если у вас нет экспертизы). Даже за 3+ млн вам могут сделать плохой сайт (причина может быть даже в непонимании чего хочет заказчик). Тут простой совет, не понимаете что и для чего хотите - начните с малого (обожгитесь) - на рынке есть предложения за 10-15 тысяч. Нет денег (тогда у вас странный бизнес или вы только начинаете) - Tilda, Wix и другие конструкторы (не стоит отбрасывать такой вариант)
Странно что промолчали про SEO... и другие расходы
Посыл статьи для меня похож на: не знаешь что - бери за 50... (следствие - вы работаете в этом ценовом сегменте)
Я не настаиваю использовать $refs (мне так удобно), можно и перенести, ток что делать если вам надо 2 кнопки к примеру или кнопка должна быть за пределами формы.
Холевар про миксины.... давайте не будем использовать ничего и напишем тонну кода) Вы берете тот же форм генератор или vuetify или другое решение и вообще не смотрите что там под капотом - знаете что это работает, примерно как и этого достаточно.
В целом есть жизненный пример "чистой архитектуры" - когда 1 простой метод api пишется часов 8 (без тестов). Нет магии, везде интерфейсы, все по феншую (Только есть одно но, метод нужен для теста и завтра может поменяться). И рядом с магией, но за пол часа. Тут каждый сам выбирает грань магии.
композиция компонентов бы решила проблему намного лучше
Я не против увидеть пример лучшего кода (если это не вкусовщина)...
По последнему пункту, уже давал пояснения в коментах выше "Чтоб всем было понятно по поводу DTO. ..."
Спасибо, выглядит не плохо, возможно кому то пригодиться. По общавшись с народом, я понял что мне не нужен форм генератор (в 99%). Лишь только в одном моем проекте есть реальная нужда в нем. Он самописный и заточен под проект, а количество полей на 1 форму 50+ (и эти поля взаимодействуют между собой, используют данные других полей для ajax, используют фильтрацию и тд). Готовым решением я б не обошелся... Но каждый решает сам, на сколько достаточно того или иного решения.
Я не совсем понял, где вы это увидели, но могу предположить что это адресовано к этой строке
<ClientEditForm
:formData="client"
/>
Отдается formData. работа внутри формы происходит с form. Изменений props нет, ошибок нет. Стоит заметить что в PageClientAdd.vue - formData вообще не передается.
Чтоб всем было понятно по поводу DTO. Бек отдал { first_name : "" , last_name : "" } , фронт это получил и говорит мне так не удобно и конвертирует в { fName : "" , lName : "" } (имеется в виду такой кейс). Я не против преобразования данных полей (было {create_at: "string"} стало {create_at: Date} ) - так стоит делать, но переименовывать по причине того, что так привычнее - это плохо. Рано или поздно вы пойдете к беку и спросите, а что там с полем fName (а бек это делал месяц назад и f_name у него ассоциируется совсем с другим).
Дальше вы хотите отдать { fName : "" , lName : "" } на сервер и преобразуете в { first_name : "" , last_name : "" }. Бек говорит ошибка в поле last_name . Мы идем и конвертируем поле с ошибкой last_name => lName.
Если есть причины, по которым вы готовы это делать - то ок.
Возможно не корректен заголовок про DTO и стоит назвать по мягче - минимизация конвертаций...
и зачастую копипаста из 4-5 пропсов расползается по всему проекту.
Да да, я про эту боль). По поводу форм генераторов у меня двоякое мнение (разработка с ними гораздо быстрее), но как только надо сделать что то за рамками - наступает боль (обычно такое бывает редко, но это очень не приятно).
Отдельно дополню ссылкой на гит для тех кто хочет взглянуть под капот. Develop ветку штормит, но она будет по интереснее. И пока что это наброски, качующие из проекта в проект...
Давайте наверно начнем с того что fvephone это обертка для vue-phone-mask-input. По этому не очень корректно их сравнивать. Корректнее наверно будет ответить на FveText и к примеру FveUrl (FveText + детали по валидации). Собственно приведу как выглядит реализация FveUrl:
import FveText from "./FveText";
export default {
mixins: [ FveText ],
methods: {
validateFunction(str) {
// насчет корректности регулярки не уверен.
const urlRegex = /^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/;
if( !urlRegex.test(str) ){ return 'Не верный формат ссылки'; }
return 'SUCCESS'; // это не круто, но как есть
},
}
};
поля email, password, time, login, number - строятся примерно таким же образом. Тут больше вопрос как это реализовано под капотом. И теперь вы можете спокойно использовать FveUrl где угодно без боязни что надо будет поменять валидацию. Отдельный момент это понимание какой тип ожидает v-model, дебаг + мне удобнее так).
В целом можно указывать дополнительно тип, подтип, передавать настройки, указывать дополнительную валидацию, но на практике мне это не пригождалось.
Наверно дополню примером из реальной жизни. Сделали редизайн главной страницы, а на бек забили. В итоге слалось 1(осн.)+7(доп.) запросов (на старую api). Проект отдали другой команде и они перенесли все в store. В итоге слой данных размазался на 4 части, вместо 1, а кеширование просто уничтожено. Часть данных храниться на странице, часть данных в сторе и третья часть в Менеджере запросов и вишенка на торте axios запрос на странице. Благо они не убили менеджер запросов который делал грязную работу по отправке 8 запросов и не трогали сами компоненты.
Я не кидаю камень в чей то огород, это просто пример бездумного программирования и обида за тот проект. В целом store не при чем, проблема только в том, как им пользуются люди. Store может помочь уменьшить количество запросов на бек (как слой оптимизации), но этот слой становиться сложным (обычно - логика размазывается, а количество запросов не уменьшается - из за банальных ошибок, к примеру отсутствия проверок наличия данных). Как мне кажется, для многих проектов эта экономия на спичках вообще не нужна, а там где надо, достаточно простого кеша, так как поддержка store получается дорогой.
Все это лирика (мой опыт) и каждый сам решает что ему необходимо для счастья.
данные предназначенные для одного компонента внезапно становятся нужны где-то в другом компоненте
У меня такие ситуации возникают очень редко. Опять таки это все связано со спецификой проектов и возможно в вашем случае хорошо именно так (без примера сказать что то очень тяжело).
Повторюсь, мои компоненты (за исключением родительского page) это слой View (там нет логики получения данных - [props + emit] ). Таким образом разрабатывают очень мало людей (хотя это позволяет изолировано разрабатывать/тестировать компоненты). Соответственно поменять слой получения данных для меня это не проблема (на странице вы все равно пишете обращение в store или в другое место). Так же сам Request Manager имеет возможность кешировать (к примеру для главной страницы мне не нужен store).
И да есть исключения - есть компоненты для переключения языка, валюты, темы и тд. Данные компоненты - я называю виджетами и они имеют право доступа в глобальный store на прямую где бы они не находились. Но нужно понимать, что таких компонентов обычно не больше 5 и в этом нет чего то очень плохого...
"Проброс ошибок является операцией которая должна сообщать о непредвиденной работе приложения. " - Не обязательно, те же самые async await к примеру (можно долго спорить). Это делает валидацию немного удобней (когда начнется валидация сложных объектов, строки дают сбой и просто не поймете где ошибка/ошибки). Можно использовать объекты со статусами, переменные передаваемые по ссылке, использование логера ошибок и прочие подходы. Бытует мнение что try catch медленнее работает (скорее всего так, но тут вопрос объема).
"Почему все проверки синхронные " - хоть про это уже и писали, но лучше заложиться, что проверки могут быть асинхронные (просто перед функцией валидации сделать async и потом надо будет меньше подпрыгивать - хоть это редко встречаемый кейс, но последствия не приятные). Вообще была идея делить такие валидации на синхронные и асинхронные, но такая реализация не прижилась в виду малого выигрыша и усложнения кода.
"Мы просто привыкли к этим инструментам и часто воспринимаем как что-то глобальное и незыблемое." - Хорошие слова, хорошее заключение, жаль что мы катимся в бездну)
Добро пожаловать в мир неописанной боли).
Билды я так понял у вас строятся через
tsc(я обычно использовал webpack), но в целом есть и другие варианты сборки (правда документации маловато и лучше искать по сторонним схожим пакетам). Возможно стоит посмотреть esbuild (как пример используется в vue/core для билда). Есть так же возможность запуститьesmвcjsчерез esm-to-cjs (вроде был этот пакет и это на всякий случай).Правильная ключевая фраза "В ИТОГЕ". Rpc проще), но пока писал статью, я понял почему все считают rpc сложнее чем rest...
Как по мне Rpc идет своим путем и этот путь менее популярен (пока что). В целом я видел проекты где есть и Rest и Rpc и они живут в одном проекте. А вот углубляться в сеть, когда это вопрос 50 строк кода и в формат данных (пусть еще 50 строк), это не целесообразно (для человека который пишет простой метод). Это вопрос оптимизации. Для браузера, мобильных приложений пока HTTP 1.1 + JSON, реже сокеты. Для общения между сервисами gRpc.
А теперь мы поднимаем образно 4 урла "/rpc" "/rest" "/soket" "/grpc" и один и тот же код работает везде (правда под rest и soket придется по мучаться дольше). Джуны пишут простые методы (getNewsList, getNewsById). Мидлы дописывают дополнительные валидационные штуки и другие более сложные вещи. Сеньеры решают что и как гонять, в каком формате, как настроить права доступа + другие попутные вещи.
А вывод, транспорт влияет на время выполнения, но никак не должен влиять на логику и нужно иметь возможность его поменять.
Промахнулся, комент ниже.
Я хотел написать чтиво выходного дня (чтоб народ мог подумать и не читать много). По большому счету это описание слоев (которые можно сделать на любом языке для rpc), пример как выглядит метод и немного о том, что не обязательно писать 500+ строк кода, ради одного метода. Про плюсы и минусы для Rpc - их уже озвучили тысячу раз.
Можно было бы углубиться, что схема для валидации это круто, удобно, многофункционально. Не обязательно получать из данных простые типы (например можно сразу получить объект пользователя по полю user_id), но это не изменит точку зрения людей. Пока не напишут свой велосипед, не успокоятся (увы такая реальность и это нормально). Не исключаю и поклонников готовых библиотек.
Говорить что json-rpc 2.0 морально устарел и его не хватает для нормального общения... это не для хабра...
Если про Go, то я столкнулся с проблемой, что первые 3 слоя влияют на слой валидации (если хочется оптимизации), но это детали языка. В целом соглашусь с тем, что генерация кода - это довольно интересная вещь, но это не популярно у простого народа на php и в ряде других языков (если не брать во внимание фреймворки), хотя в далекие времена писал сборщики js файлов и какие то мини генераторы.
Я хотел дописать какие то главы, но сейчас понимаю, что на это нет смысла тратить время, так же как и писать трехтомный пост. Про плюсы - гибкость (можно заменить слой в ядре, добавить или убрать), минусы - вам захочется или придется писать свой велосипед (для примера можно посмотреть сорцы). А лить воду, кидать кучу года из исходников, говорить "я сделал хранилище запросов" и другие банальные вещи - это не цель этой статьи.
В любом случае спасибо и я рад, что я не один такой)
Увы, но это не протокол, как и REST. Просто набор каких то размытых правил. Дальше есть надстройки как протокол SOAP, спецификация JSON-RPC 2.0 и не будем упускать gRPC. Я так понял народу больше интересно первые три слоя, которые размывают границу, как передается, в каком формате и в какой структуре.
Пример Rpc метода с авторизацией приведен для того чтоб показать как это можно оформить (не авторизацию, а сам метод). А основная суть, что мы его за 20-30 строк кода, оформляем в полноценный метод который можно вызвать клиентом (при чем с валидацией данных), например так:
Если так не устраивает пример, можете использовать JSON-RPC 2.0 Specification.
Я понял что статья не зашла (по крайней мере сообществу), все равно спасибо. Я не хотел писать трехтомный пост и углубляться в каждый уголок.
Да автогенерация отсутствует, но по факту, вам нужно писать только 1 отдельный класс для каждого метода. Обработка ошибок - если не усложнять, то блок try catch в котором находиться вызов всех слоев с отдельным классом ошибки.
Вот с сериализацией все гораздо интереснее, можно прикрутить json-rpc, а можно общаться xml (мало ли), можно доставать данные из get параметров и тд... По факту за это отвечают первые 3 слоя (откуда достать, как достать и какая структура) и они кладут вам все это в класс запроса метода.
А для чего вы задаете этот вопрос, какая польза от этого вопроса и ответа на него? Я б не стал углубляться в это. Если задача завалить кандидата, то наверно js это самое лучшее, что можно придумать. Я не имею ничего против данной статьи (прочел, классно, через месяц забуду, может быть когда то вспомню), но я против бесполезных вопросов на собесе.
Честно говоря, те кто хотят сделать первый свой сайт не понимают зачем он (есть облачные надежды, что сделав сайт, клиенты потекут рекой...). Это была бы более интересная тема (многим хватает лендинга и многие не готовы поддерживать интернет магазины). Кто то осознано отказывается делать сайт (по общавшись со мной) в сторону готовых площадок (авито, вк, юла и тд...).
Выбор исполнителя - это всегда рулетка (если у вас нет экспертизы). Даже за 3+ млн вам могут сделать плохой сайт (причина может быть даже в непонимании чего хочет заказчик). Тут простой совет, не понимаете что и для чего хотите - начните с малого (обожгитесь) - на рынке есть предложения за 10-15 тысяч. Нет денег (тогда у вас странный бизнес или вы только начинаете) - Tilda, Wix и другие конструкторы (не стоит отбрасывать такой вариант)
Странно что промолчали про SEO... и другие расходы
Посыл статьи для меня похож на:
не знаешь что - бери за 50... (следствие - вы работаете в этом ценовом сегменте)
Я не настаиваю использовать $refs (мне так удобно), можно и перенести, ток что делать если вам надо 2 кнопки к примеру или кнопка должна быть за пределами формы.
Холевар про миксины.... давайте не будем использовать ничего и напишем тонну кода) Вы берете тот же форм генератор или vuetify или другое решение и вообще не смотрите что там под капотом - знаете что это работает, примерно как и этого достаточно.
В целом есть жизненный пример "чистой архитектуры" - когда 1 простой метод api пишется часов 8 (без тестов). Нет магии, везде интерфейсы, все по феншую (Только есть одно но, метод нужен для теста и завтра может поменяться). И рядом с магией, но за пол часа. Тут каждый сам выбирает грань магии.
Я не против увидеть пример лучшего кода (если это не вкусовщина)...
По последнему пункту, уже давал пояснения в коментах выше "Чтоб всем было понятно по поводу DTO. ..."
Спасибо, выглядит не плохо, возможно кому то пригодиться. По общавшись с народом, я понял что мне не нужен форм генератор (в 99%). Лишь только в одном моем проекте есть реальная нужда в нем. Он самописный и заточен под проект, а количество полей на 1 форму 50+ (и эти поля взаимодействуют между собой, используют данные других полей для ajax, используют фильтрацию и тд). Готовым решением я б не обошелся... Но каждый решает сам, на сколько достаточно того или иного решения.
Я не совсем понял, где вы это увидели, но могу предположить что это адресовано к этой строке
Отдается formData. работа внутри формы происходит с form. Изменений props нет, ошибок нет. Стоит заметить что в PageClientAdd.vue - formData вообще не передается.
Чтоб всем было понятно по поводу DTO.
Бек отдал { first_name : "" , last_name : "" } , фронт это получил и говорит мне так не удобно и конвертирует в { fName : "" , lName : "" } (имеется в виду такой кейс). Я не против преобразования данных полей (было {create_at: "string"} стало {create_at: Date} ) - так стоит делать, но переименовывать по причине того, что так привычнее - это плохо. Рано или поздно вы пойдете к беку и спросите, а что там с полем fName (а бек это делал месяц назад и f_name у него ассоциируется совсем с другим).
Дальше вы хотите отдать { fName : "" , lName : "" } на сервер и преобразуете в { first_name : "" , last_name : "" }. Бек говорит ошибка в поле last_name . Мы идем и конвертируем поле с ошибкой last_name => lName.
Если есть причины, по которым вы готовы это делать - то ок.
Возможно не корректен заголовок про DTO и стоит назвать по мягче - минимизация конвертаций...
Да да, я про эту боль). По поводу форм генераторов у меня двоякое мнение (разработка с ними гораздо быстрее), но как только надо сделать что то за рамками - наступает боль (обычно такое бывает редко, но это очень не приятно).
Отдельно дополню ссылкой на гит для тех кто хочет взглянуть под капот. Develop ветку штормит, но она будет по интереснее. И пока что это наброски, качующие из проекта в проект...
Давайте наверно начнем с того что fvephone это обертка для vue-phone-mask-input. По этому не очень корректно их сравнивать. Корректнее наверно будет ответить на FveText и к примеру FveUrl (FveText + детали по валидации). Собственно приведу как выглядит реализация FveUrl:
поля email, password, time, login, number - строятся примерно таким же образом. Тут больше вопрос как это реализовано под капотом. И теперь вы можете спокойно использовать FveUrl где угодно без боязни что надо будет поменять валидацию. Отдельный момент это понимание какой тип ожидает v-model, дебаг + мне удобнее так).
В целом можно указывать дополнительно тип, подтип, передавать настройки, указывать дополнительную валидацию, но на практике мне это не пригождалось.
Наверно дополню примером из реальной жизни. Сделали редизайн главной страницы, а на бек забили. В итоге слалось 1(осн.)+7(доп.) запросов (на старую api). Проект отдали другой команде и они перенесли все в store. В итоге слой данных размазался на 4 части, вместо 1, а кеширование просто уничтожено. Часть данных храниться на странице, часть данных в сторе и третья часть в Менеджере запросов и вишенка на торте axios запрос на странице. Благо они не убили менеджер запросов который делал грязную работу по отправке 8 запросов и не трогали сами компоненты.
Я не кидаю камень в чей то огород, это просто пример бездумного программирования и обида за тот проект. В целом store не при чем, проблема только в том, как им пользуются люди. Store может помочь уменьшить количество запросов на бек (как слой оптимизации), но этот слой становиться сложным (обычно - логика размазывается, а количество запросов не уменьшается - из за банальных ошибок, к примеру отсутствия проверок наличия данных). Как мне кажется, для многих проектов эта экономия на спичках вообще не нужна, а там где надо, достаточно простого кеша, так как поддержка store получается дорогой.
Все это лирика (мой опыт) и каждый сам решает что ему необходимо для счастья.
У меня такие ситуации возникают очень редко. Опять таки это все связано со спецификой проектов и возможно в вашем случае хорошо именно так (без примера сказать что то очень тяжело).
Повторюсь, мои компоненты (за исключением родительского page) это слой View (там нет логики получения данных - [props + emit] ). Таким образом разрабатывают очень мало людей (хотя это позволяет изолировано разрабатывать/тестировать компоненты). Соответственно поменять слой получения данных для меня это не проблема (на странице вы все равно пишете обращение в store или в другое место). Так же сам Request Manager имеет возможность кешировать (к примеру для главной страницы мне не нужен store).
И да есть исключения - есть компоненты для переключения языка, валюты, темы и тд. Данные компоненты - я называю виджетами и они имеют право доступа в глобальный store на прямую где бы они не находились. Но нужно понимать, что таких компонентов обычно не больше 5 и в этом нет чего то очень плохого...