предыдущей части<\/a> я рассказал, почему хорошо создавать конфигурации — JSON-описания поведения страниц без программирования.<\/p>\nУ этого подхода есть ещё один прекрасный плюс: смена фреймворка перестаёт быть невыполнимой задачей.<\/p>\n
Если вы используете конфигурации, то компоненты страницы внутри шаблона могут быть написаны на любом фреймворке: AngualrJS 1.x, Angular, Vue.js, React, Svelte и так далее. Вы даже можете их смешивать, и переписывать пошагово, когда часть компонентов использует один фреймворк, а часть — другой.<\/p>\n
Таким образом, продукт и компания перестают быть связаны устаревшими технологиями, и если фреймворк перестанет поддерживаться, работа не остановится. Конечно, переезд не станет лёгким делом и займёт несколько месяцев, но без конфигураций страниц переехать будет просто невозможно без переписывания каждой страницы вручную. Именно так и получаются ситуации, когда в одном проекте есть Бекбон, Джейквери, Реакт разных версий и только избранные разработчики могут без страха менять что-то в легаси-модулях.<\/p>\n",
"date_published": "2020-02-25T13:43:01+03:00",
"date_modified": "2020-02-25T13:42:59+03:00",
"_date_published_rfc2822": "Tue, 25 Feb 2020 13:43:01 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "48",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "44",
"url": "https:\/\/www.blog.sergeykopylov.ru\/all\/arhitektura-frontenda-konfiguracii\/",
"title": "Архитектура фронтенда: конфигурации",
"content_html": "
Я долго работал над большими проектами для администирования, когда в системе есть очень много данных, и много страниц, для управления ими. Много — это, например, 500 страниц. И я использовал довольно естественный подход, когда каждая страница конфигурируется, а не программируется. Что-то вроде такого:<\/p>\n
import ...\r\n...\r\n\r\nexport default {\r\n url: "orders\/:id", \/\/ Адрес страницы с подстановкой данных\r\n template: "formPage", \/\/ Какой шаблон страницы использовать\r\n data: { \/\/ Данные и обработчики данных\r\n value: (id) => Data.get(Orders, {id: id}, \/\/ Набор значений полей заказа с сервера\r\n fields: fields, \/\/ Набор полей по порядку с их параметрами, подключаемый из другого файла,\r\n onSave: (id) => Data.save(Orders, {id: id})\r\n }\r\n}<\/code><\/pre>Это, конечно, псевдокод, но он показывает сам принцип:<\/p>\n
\n- Существует сервис Data<\/b>, который умеет получать данные с сервера и отправлять их обратно. Вообще говоря, неважно, хранит ли он их на сервере, или в локалсторадж, к примеру, странице-то это неважно;<\/li>\n
- Существует Orders<\/b> — описание того, как именно сохранять или получать заказы, внутри — просто JSON с параметрами, которые переиспользуются на разных страницах;<\/li>\n
- fields<\/b> — это JSON-описание набора полей: в каком они порядке, как взаимосвязаны друг с другом, в каком из них какое поле из data отображается, какого они типа и так далее.<\/li>\n<\/ul>\n
Получается, что новому разработчику вообще не нужно уметь программировать, а нужно только описать два JSON-файла:<\/p>\n
\n- Набор полей<\/li>\n
- По какому адресу и с какими дополнительными параметрами можно получить и записать данные о заказе на сервере.<\/li>\n<\/ul>\n
Если к этому есть документация, или, хотя бы много примеров (а когда страниц 500, то и примеров в избытке) — это несложно, и, что важнее, очень быстро для исправления или переработки.<\/p>\n
Всё. Как именно сохранять данные и когда отправлять их на сервер и в каком виде знает сервис Data<\/b>; компоненты на странице знают, как именно отрисовывать поля ввода. Разработчику ненужно парится об отступах и расположении элементов, об отображении индикатора загрузки при сохранении и вообще о том, как устроен конкретный шаблон, достаточно просто его сконфигурировать.<\/p>\n
Но оказалось, что этот способ используется очень редко потому, что дизайнеры рисуют разные макеты, потому, что кажется, что существующим шаблоном не решить задачу и так далее. Все эти проблемы надуманы — нужно стараться решить задачу существующими средствами, точечно дорабатывая их, когда не получается. Но это тема другой статьи<\/p>\n",
"date_published": "2020-02-24T20:24:20+03:00",
"date_modified": "2020-02-24T20:24:14+03:00",
"_date_published_rfc2822": "Mon, 24 Feb 2020 20:24:20 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "44",
"_e2_data": {
"is_favourite": false,
"links_required": [
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css"
],
"og_images": []
}
}
],
"_e2_version": 3559,
"_e2_ua_string": "E2 (v3559; Aegea)"
}