Vue шаг за шагом. Разнообразие из кирпичиков. Пример#12

Отдельный роут для редактирования данных

Традиционно для редактирования данных делают отдельный роут. Это удобно особенно если нужно коллегам скинуть ссылку на конкретный товар, карточку клиента и т.п. Согласитесь, проще поделиться ссылкой типа https://myproject.com/#/client/135, нежели глупо рассказывать куда зайти на какой странице куда нажать для просмотра или редактирования.

Для реализации этого функционала сделано два отдельных роута. Для просмотра списка path: '/client' (используется компонент client), и для редактирования path: '/client/:id' (используется компонент client-edit):

  { path: '/client',
    component: { template: '<client v-if="router.app.componentsReady(`client`)" />' },
    beforeEnter (to, from, next) { loadComponents("client.js"); next() }
  },
  { path: '/client/:id',
    component: { template: '<client-edit v-if="router.app.componentsReady(`client-edit`)" />' },
    beforeEnter (to, from, next) { loadComponents("client.js"); next() }
  },

Обратите внимание, оба компонента client, client-edit находятся в одном файле client.js.

Компонент client-edit использует для отображения формы компонент standard-form, а для загрузки и обновления данных методы описанные в миксине crud. В результате применения отдельных блоков программный код компоненты не выглядит зловеще.

Обратите внимание на один из прием, который применен в компоненте client-edit. В нем описано вычисляемое свойство ID:

computed: {
    ID: function () {
      return app.getRouteParam('id')
    }
  },

Также описан наблюдатель за этим свойством:

watch: {
  ID() {
    this.init()
  }
}

Который вызывает метод this.init() при изменении вычисляемого свойства ID. Метод this.init() так же вызывается при создании компоненты.

Зачем это сделано? Если пользователь в адресной строке изменит id (вручную или каким либо иным способом), то watch-ер заметит изменение вычисляемого поля, вызовет this.init(), который загрузит новые данные. Если watch-ра не будет, то изменения id в адресной строке не вызовет перезагрузки данных, на экране останутся старые данные, что не есть хорошо. Например, когда Вам по почте приходит две ссылки от коллег с просьбой посмотреть карточки двух клиентов:

Вы открываете первую и все OK, открываете вторую, а на экране остаются данные первого.

Поэтому я выработал для себя правило- все параметры роута — в вычисляемые свойства, загрузку данных в метод this.init(), watch на все вычисляемые свойства, которые отвечают за параметры роута.

Разнообразие отображения

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

В этот примере каждая запись отображается ка отдельная блок или плитка (называйте как хотите). И наверное только наличие постраничного вывода оставляет намек на то, что здесь применен миксин table. Да, именно этот миксин обеспечивает сортировку, постраничный вывод и т.д. И не важно как выглядят данные в виде таблицы или как то иначе.

Реализована возможность редактирования прямо в таблице, в смысле, прямо в плитке. Ну Вы поняли.

Это все реализовано с ранее созданных миксинов и компонент. Благодаря тому, что компоненты и миксины написаны таким образом, что занимаются только своими делами и не лезут в дела друг друга, стало возможным использовать их комбинируя по своему усмотрению. При этом избегая конфликтов.

Application settings

Еще одним небольшим дополнением стала возможность сохранять настройки пользователя в виде дерева в локальном хранилище с помощью двух основных функций — app.getSettings, app.setSettings. Ничего сверхъестественного в этих функциях нет, кроме одной особенности — здесь не применяется шаблон CRUD.

Как так? Настройки — это те же данные и над ними также можно совершать 4 основные операции Create, Read, Update, Delete. Почему в данном случае есть только две функции get... и set…?

Просто потому что так удобнее. Удобно считать значение настройки а если ее нет, то вернуть значение по умолчанию. Удобно сохранить настройку и не важно существует она (надо делать update) или еще нет (надо делать create). Поэтому не всегда общепринятые шаблоны удобно применять. Это не религия и не присяга родине. Подход в этом вопросе очень прост: удобно — применяем, не удобно — применяем то, что удобно. CRUD – это не панацея от всех проблем, его нужно применять только там, где это удобно и решает Ваши проблемы, а не добавляет их.

Резюме

В этом примере продемонстрированы различные приемы построения интерфейсов на фреймворке Vue. Продемонстрирована сила и мощь компонентного подхода и разделения приложения на функциональные блоки. Что позволяет легко комбинировать ранее созданные модули в новые компоненты избавляя разработчика от лишних трудозатрат.

В следующем примере

Далее последует подборка примеров для построения beckend-a. После того, как у нас будет реальный beckend, будет пример №13, который перестроим для работы с реальным beckend, с реальной базой данных.

Смотри также:

• Vue. Vue-router
• Vue. Свойство data. Основы компонент
• Vue. CRUD. Работа с данными
• Vue. Mixins (Примеси)
• Vue. computed свойства. Постраничный вывод данных
• Vue. Сортировка, поиск данных в таблицах
• Vue. Таблица - трансформер под настольные и мобильные версии
• Vue. Стандартная таблица. Минимизируем код
• Vue. Динамическая загрузка компонент
• Vue. Диалоги и Notifications
• Vue.Стандартный компонент для редактирования данных
• Vue. Разнообразие из кирпичиков
• Flask + Vue. Финальный пример