Flask & Vue. Frontend - Зручна навігація. Приклад№ 2.2

02.05.2021

У цій статті: Навігація, роути, таблиця. Як робити рівно?

У попередній серії прикладів було зроблено посторінкове відображення даних (пагінація, як кажуть деякі). Покищо вона працює у режимі "завантажили усі дані, розбили по сторінкам і показуємо". Звісно, що у наступних прикладах зробимо щоб дані сторінок завантажувалися з сервера.

Зручна навігація

Але сьогодні я б хотів загострити Вашу увагу на іншому аспекті. Коли Ви переходите, на будь-яку наступну сторінку, то адресний рядок не змінюється. Уявіть, що Ви виявили якусь проблему на сторінці №13 і хочете повідомити про це колегу. Ви вимушені на словах казати, що треба перейти на сторінку №, натиснути туди, і т.п. А якщо Ви спочатку відсортували таблицю по якомусь стовпчику, а якщо ще і фільтрували?.. Це все ускладнює спілкування і породжує неоднозначності. І повірте, у житті таке стається досить часто.

Ще одна фігня трапляється, коли ви переходите з якоїсь сторінки на іншу (мається на увазі rout у тому числі), а потім бажаєте поверутися назад, а номер сторінки не запам'ятали. Якщо тицьнути у браузері "назад", нічого з цього гарного не вийде. Також, коли ви долистали до сторінки №13, знайшли потрібний запис, тицьнули, щоб відредагувати його, а після збереження - вас викине на першу сторінку. А було б логічно повернутися на ту ж саму сторінку, де Ви були до цього. А як що було сортування або пошук, було б гарно, щоб і ці параметри залишилися.

Тому правильно на фронтенді, коли змінюється роут, сортування колонки, пошук або фільтрація, зміна закладки, тощо, - змінювати й адресний рядок. Тоді б була б зручніша і навігація, і обмін посиланнями з колегами виключав би неоднозначності. Тобто, для спрощення навігації ми деякі дані, які стосуються стану, переносимо у параметри адресного рядку. Тут треба не перегнути палку. Бо якщо абсолютно все запхнути у адресний рядок - буде каша.

У цьому прикладі буде продемонстровано - як це виглядає на прикладі посторінкового виводу даних, а у подальшому і сортування і пошук будуть передаватися у параметрах в адресному рядку.

Наприклад:
http://localhost:5000/frontend/#/client/
http://localhost:5000/frontend/#/client/page/2
http://localhost:5000/frontend/#/client/page/3

Ще одна річ, яку я пропоную робити, як стандарт, - це редагуваня даних в окремому роуті, тобто, адресний рядок для форми редагування обов'язково має бути унікальним. У попередніх прикладах компонента stsndart-page містила форму для редагування даних, вона відкривалася при натисканні кноки "Edit". При цьому адресний рядок ніяк не змінюється. Це біда, бо ніяк не можна зберегти/переслати посилання на форму для редагування. Таку форму можна відкрити тільки натиснувши на кнопку. Це нормально для звичайних програм, але ж ми будуємо web-додаток і треба використовувати всі можливості браузера. Наприклад, коли ми натиснемо "Назад", додаток має повернутися до попереднього стану. Таке легко реалізувати, коли деякі дані, які стосуються стану web-додатку, передаються у адресному рядку, як параметри. Отже, редагування даних в окремому роуті - це стандарт, усе решта - крамола, і ми так робити більше не будемо. Маю надію, що я наочно пояснив чому.

Універсальні роути

На фронтенді роути трохи поправили і зробили їх універсальними. Погодьтесь, коли даних стане занадто багато, прописувати сотні однотипних роутів буде не дуже логічним та цікавим заняттям.


/* ROUTES */
const routes = [
  { path: '/',
    component: { template: '' },
    beforeEnter (to, from, next) { loadComponents("default.js"); next() }
  },
  { path: '/:instance', component: { template: '' } },
  { path: '/:instance/page/:page', component: { template: '' } },
  { path: '/:instance/:id', component: { template: '' } },
]

Тепер у параметрі instance вказуеться - які саме дані потрібно відображати. Нагадаю, що у попередньому прикладі роут для нових даних countries ми прописували руками. Тепер, при додаванні нових даних роути дописувати не потрібно, якщо використовуються стандартні компоненти. Якщо потрібна буде екзотика, це можна буде описати окремим роутом.

Засада з табличкою. Чому так робити нізя?

У попередній серії прикладів я розпинався про те, як правильно будувати додаток, як розділяти відповідальність між компонентами. І "закопав" логічну помилку у прикладах. Але, нажаль, досі мені ні хто на це не вказав. Ця структурна помилка стосується таблиці.

Що не так з таблицею standard-table?

У першій серії прикладів було зроблено компонент з назвою standard-table. У цей компонент передавалися завантажені дані і цей компонент сам виводив їх по сторінках, у цьому ж компоненті standard-table використовувалися компоненти table-menu та paginator. Тобто, компонент самостійно розбирав дані на сторінки і сам відображував потрібну. Та це є невірним рішенням.

По-перше: компонент, який відповідає за відображення даних, не має займатися модифікацією цих даних. Про це я казав на самому початку.

По-друге: ми не можемо використати компонент standard-table, скажімо без компонентів table-menu та paginator, бо вони вже вбудовані в standard-table. Якщо нам потрібно буде використати просто табличку, доведеться писати новий компонент таблиці. Це не логічно.

По-третє: стосовно пагінації, у попередніх прикладах standard-table вираховує кількість сторінок, знаючи кількість рядків і скільки рядків показати на одній сторінці. Коли ми перейдемо до серверної пагінації, standard-table не зможе вирахувати кількість сторінок.

Тому треба робити standard-table, який тільки відображає табличку, незалежний table-menu, та незалежний paginator, поєднувати їх в окремій "батьківській" компоненті. Тоді "батьківській" компонент буде виконувати завантаження даних, обчислювати дані для пагінатора, тощо. А standard-table, table-menu та paginator тільки відображати дані, і ні у якому разі не змінювати ці дані. Якщо треба змінити дані, компоненти мають віправити event у "батьківський" компонент, який і виконує всі зміни. Такий підхід надасть можливість у подальшому легко модифікувати web-додаток та без зайвих проблем заміняти одні компоненти на інші. Тому функціонал, який був у міксіні table було перенесено до міксіна paginator_local. Тепер за це відповідає компонент instance-page.

Завантажити приклад #2

P.S. У наступній статті: Посторінковий вивід даних (пагінація), пошук та сортування.

Як запустити приклад?

Завантажити архів з прикладом, розпакувати
Запустити приклад командою:
```
python ./my_app.py
```
або
```
python3 ./my_app.py
```
У браузері відкрити посилання: http://localhost:5000/

Дивись також:

Web-dev склерозник

Коментарі:

Додати коментар

Категорії

Недавні записи

Архіви

оберіть місяць: