1) Vue дает много свободы и возможность формировать свою архитектуру. На вкус разработчика, тут views = pages, главное чтоб логика разделения сохранялась и там хранились именно страницы.
2) В небольшом/среднем проекте сразу папка api.
В проектах побольше services, внутри уже папка api + дополнительные папки (helpers, generators и т.д), где можем хранить функции сериализации, слипы и др
2) Для простоты расписывала плоскую структуру, папки можно менять или вкладывать. Да, можно выделять интерфейсы по месту хранения, если это удобно. Иногда их вообще не выделяют, как итог - несколько одинаковых интерфейсов разбросаны по проекту в разных папках на больших проектах.
Мне удобнее видеть все в одном месте. Файл с типами тоже можно сделать композитным.
3) Здесь просто пример выделения, можно использовать, как классы, так и функции. В зависимости от проекта. Можно сделать объект product и внутри него методы get, post, patch.
На сколько знаю, в ангуляре просто вместо стора используются сервисы. Могу ошибаться, +- та же штука, где данные доступны глобально. Во вью просто нет DI движка из под коробки и зависимости явно импортируются.
На тех же объектах можно построить реактивность с помощью Composition API и отказаться от стор в принципе. Но, для меня большой плюс стор - это выделенное под хранилище представление во вьюшных девтулзах, можно сразу видеть все объекты, а не только через компоненты смотреть. На больших проектах это помогает.
provide/inject подойдет, если у компонентов общий родитель, но мы не сможем делиться данными с соседями, + жирный минус, что при использовании TS теряем типизацию
5) Согласна, что typescript очень удобен и мне лично упрощает жизнь его использование. Линтеры и прекоммиты маст хев
Можно выбрать любое хранилище, в статье про стор в принципе. Моя ошибка, что не упомянула про pinia. Vuex или Pinia в данном случае не играет роли, для pinia +- те же принципы работают
сomposables здесь лежат в папке hooks (тут так назвала, но сomposables даже более очевидно +)
Про использование обертки - отличное замечание, это как раз выйдет во второй части статьи
1) Vue дает много свободы и возможность формировать свою архитектуру. На вкус разработчика, тут views = pages, главное чтоб логика разделения сохранялась и там хранились именно страницы.
2) В небольшом/среднем проекте сразу папка api.
В проектах побольше services, внутри уже папка api + дополнительные папки (helpers, generators и т.д), где можем хранить функции сериализации, слипы и др
2) Для простоты расписывала плоскую структуру, папки можно менять или вкладывать. Да, можно выделять интерфейсы по месту хранения, если это удобно. Иногда их вообще не выделяют, как итог - несколько одинаковых интерфейсов разбросаны по проекту в разных папках на больших проектах.
Мне удобнее видеть все в одном месте. Файл с типами тоже можно сделать композитным.
3) Здесь просто пример выделения, можно использовать, как классы, так и функции. В зависимости от проекта. Можно сделать объект product и внутри него методы get, post, patch.
4) Про стор, как раз пишу, что он не везде необходим и можно обойтись без него. (https://github.com/vuejs/vuex/issues/236#issuecomment-231754241)
На сколько знаю, в ангуляре просто вместо стора используются сервисы. Могу ошибаться, +- та же штука, где данные доступны глобально. Во вью просто нет DI движка из под коробки и зависимости явно импортируются.
На тех же объектах можно построить реактивность с помощью Composition API и отказаться от стор в принципе. Но, для меня большой плюс стор - это выделенное под хранилище представление во вьюшных девтулзах, можно сразу видеть все объекты, а не только через компоненты смотреть. На больших проектах это помогает.
provide/inject подойдет, если у компонентов общий родитель, но мы не сможем делиться данными с соседями, + жирный минус, что при использовании TS теряем типизацию
5) Согласна, что typescript очень удобен и мне лично упрощает жизнь его использование. Линтеры и прекоммиты маст хев
Можно выбрать любое хранилище, в статье про стор в принципе. Моя ошибка, что не упомянула про pinia. Vuex или Pinia в данном случае не играет роли, для pinia +- те же принципы работают
сomposables здесь лежат в папке hooks (тут так назвала, но сomposables даже более очевидно +)
Про использование обертки - отличное замечание, это как раз выйдет во второй части статьи