Есть ли рекомендуемый API приложения VueJS и шаблон проектирования Vuex?

Я думаю, что изображение это из веб-сайт vuex очень хорошо объясняет важность каждого элемента vuex. Действия вызывают API, а затем мутацию для фиксации ответов, полученных для обновления состояния приложения. Компоненты Vue считывают состояние через геттеры. Когда действие фиксирует обновление статуса, геттеры обновляют свои значения, и ваш компонент отображает обновленные данные. Если у вас есть компонент vue, которому требуются некоторые данные из вашего API для рендеринга, вы можете отправить одно или несколько действий из средства навигации, например beforeEnter или beforeRouteEnter, для загрузки или обновления состояния приложения.

TL;DR: You need mix of multiple things when building large-scale Vue.js application (or SPA application) in general.

Для этого не существует фиксированного рекомендованного шаблона. Правильный ответ всегда - По-разному.

Ниже приведены несколько рекомендаций, которые помогут:

Слой

В общем, есть два способа - горизонтальное наслоение и вертикальное наслоение. При горизонтальном наслоении система делится на слои, например

App Level Component
  <-- Multiple Views (pages)
        <-- Business Logic Components
           <-- Re-usable lower order components
           and API (Fetch/XHR/Websockets)

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

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

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

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

Состояние приложения

Здесь все усложняется. Это непрерывный процесс по мере развития приложения. Здесь нужно потренироваться, что делает Глобальное состояние и Местное государство. Представьте себе приложение со значком Bell, указывающим на непрочитанные сообщения, и на той же странице где-то внизу есть способ чтения сообщений (например, Facebook / LinkedIn), состояние которого необходимо синхронизировать и поддерживать.

Это пример глобального состояния, и как таковой он может поддерживаться в некотором общем предке верхнего уровня или даже в лучшем внешнем хранилище данных, таком как Redux или Vuex. Оба одинаково хороши. Только такое глобальное и совместно используемое состояние обычно должно быть смоделировано в явное хранилище состояний.. Другой пример - данные авторизованного пользователя, которые можно использовать повторно.

Еще один критерий для внесения определенного состояния в хранилище - это когда вам нужны такие вещи, как функция Time Travel (отменить и повторить) или вы хотите сохранить локальное постоянство для приложений, таких как приложения для рисования, игры и т.

Маршрутизация и управление состоянием

Наряду с глобальным состоянием, маршрутизация - еще одна проблема верхнего уровня приложения. Первым всегда является глобальное хранилище, потому что решения о маршрутизации (защита, предварительная выборка и т. д.) Могут использовать глобальные данные из хранилища. Таким образом, вы всегда сначала инициализируете хранилище, а затем при необходимости используете его с маршрутизатором.

Уровень API

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

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

Компонентный дизайн

Сохраняйте четкое различие между компонентами более высокого и более низкого порядка. Компоненты более низкого порядка можно использовать повторно, например Button, Calendar, DatePicker, Dropdown и т. д. Они не должны знать о приложении и его бизнес-логике. Это похоже на то, что у вас есть мини-библиотека компонентов, которую можно использовать в любом приложении Vue.js.

В компонентах более высокого порядка происходит основная магия вашего приложения. Это компоненты, которые будут получать данные из нескольких источников, таких как router / vuex / api и т. д. Эти компоненты снова не являются плоскими и обычно разделены на отдельные уровни.

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

Есть несколько ссылок, которые могут помочь вам в дальнейшем:

Как лучше всего использовать Vue-Router для очень больших веб-приложений?

Современные интерфейсные архитектуры