Вы не найдете такую информацию, потому что она не Vue связана. Vue не волнует, для чего вы его используете и как вы структурируете свои данные. Он направлен на то, чтобы позволить вам делать все, что вы хотите.
Точно так же, как его не волнует, как выглядит структура вашей папки (потому что, по сути, все, что ему нужно для визуализации - это отдельный элемент DOM), его также не волнует, как вы организуете свою структуру. API, как вы структурируете свое приложение, ваши страницы или даже ваши компоненты.
Очевидно, что обладать таким количеством свободы не всегда хорошо. Если вы посмотрите вокруг, вы заметите, что люди, которые профессионально используют Vue, используют определенные шаблоны / структуры, которые обеспечивают лучшее повторное использование кода и большую гибкость. Nuxt является одним из таких хороших примеров.
Всем, кто только начинает с Vue, я рекомендую попытаться использовать Nuxt как можно скорее, даже если это излишне для их небольшого проекта, потому что они, вероятно, подберут несколько хороших шаблонов.
Переходя к конкретному c вопросу, с точки зрения архитектуры API данных, вы всегда должны спросить себя: каков основной принцип?
Основной принцип - сделать ваше приложение максимально быстрым , Для этого, в идеале, вы хотите точно определить, сколько данных вы хотите отобразить, но не больше. Поэтому:
- при получении тех же данных, если у вас есть выбор, всегда старайтесь уменьшить количество запросов. Вы не хотите, чтобы каждый элемент в списке инициировал вызов серверу при его отображении. Сделайте один вызов для всего списка (только выбирая то, что вы отображаете в представлении списка) и запросите сведения, если пользователь запрашивает его (нажимает кнопку сведений).
- отрегулируйте нумерацию страниц, чтобы обслуживать, сколько элементов вы может отображаться на экране, а также в зависимости от того, сколько времени требуется для загрузки страницы. Если это занимает слишком много времени, уменьшите размер страницы и добавьте больше элементов. Если вы подумаете об этом, большинство людей предпочитают быстрое приложение с меньшим количеством элементов на странице (и щедро заполненными элементами), а не одно, которое занимает секунды, чтобы загрузить каждую страницу и отображает элементы настолько разбитые, что на них трудно нажимать / нажимать или на них трудно следить в списке, не теряя строки.
Тем не менее, вы должны принять эти рекомендации с долей соли. В подавляющем большинстве случаев выборка полных данных за один вызов практически не влияет на работу пользователей. Во многих случаях задержки связаны с холодным запуском сервера (первый вызов к серверу занимает больше времени, так как ему нужно «разбудить его» - но все последующие вызовы того же типа выполняются быстрее), с неоптимизированными изображениями или с плохим rnet подключения (как, например, он работает плохо, независимо от того, получаете ли вы только имена или полный список деталей).
Еще один аспект, который следует иметь в виду, заключается в том, что получение всех данных за раз является торговлей -off. Вы получаете более медленный начальный вызов, но после этого вы можете выполнять плавную анимацию между представлением списка и подробным представлением, поскольку данные уже получены, больше не требуется загрузка. Если вы любезно справляетесь с состоянием загрузки, во многих сценариях это жизнеспособный вариант ios.
Последний, но не менее важный недостаток вашей второй точки не существует. Вы всегда можете связать все детали в одном go:
<user-details v-bind="user" />
эквивалентно
<user-details :id="user.id" :name="user.name" :age="user.age" ... />
Чтобы дать вам очень простой c пример, типичный Разметка для вашего варианта использования будет выглядеть следующим образом:
<div v-if="isLoadingUsers" />
<user-list v-else :users="users">
<user-list-item v-for="(user, key) in users"
:key="key"
v-bind="user"
@click="selectedUser = user" />
</user-list>
<user-details-modal v-bind="selectedUser" />
Это, очевидно, упрощение, вы можете выбрать не модальную информацию о пользователе, а прохладный transform в элементе списка, что позволит ему расти и отображать больше детали, и т. д. c ...
Если есть сомнения, упростите. Например, только показ подробностей для одного выбранного элемента (и закрытие его при выборе другого) сразу решит множество проблем с пользовательским интерфейсом.
Что касается последнего вопроса: будут ли иметь разные компоненты для разных состояний, ответ должен прийти от ответа на другой вопрос: насколько велик должен быть размер вашего компонента? Верхний предел обычно составляет около 300 строк, хотя я знаю разработчиков, у которых go не выше 200, и других, у которых нет проблем с 500+ строками в компоненте).
Когда он становится слишком большим, вы должны извлечь его часть (скажем, функциональность, не подтвержденную пользователем, в подкомпонент) и в итоге получить это внутри компонента <user-detail>:
<user-detail>
... common details (title, description, etc...)
<div v-if="user.isValidated">
...normal case
</div>
<user-not-validated v-bind="user" v-else />
... common functionality (action bar, etc...)
</user-detail>
Но это подкомпоненты вашего <user-detail> компонента, которые извлекаются, чтобы помочь вам сохранить код организованным. Они не должны заменять <user-detail> полностью. Точно так же вы можете извлечь детали верхнего или нижнего колонтитула, которые имеют смысл. Ваша цель должна состоять в том, чтобы ваш код был аккуратным и организованным. Следуйте принципам, которые имеют для вас больше смысла.
Наконец, если бы мне пришлось выделить одно полезное руководство при принятии решений по архитектуре кода, это определенно был бы принцип DRY. Если вам не нужно писать один и тот же код в нескольких местах одного и того же приложения, вы делаете это правильно.
Надеюсь, вы найдете некоторые из перечисленных выше полезными.