Блог Сергея Копылова: заметки с тегом архитектура фронтенда

Сотни тысяч элементов на странице

Сергей Копылов — Wed, 01 Apr 2020 09:02:31 +0300

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

Например:

На странице отображены 100 000 товаров и у каждого есть кнопки действий. Как указать обработчик событий для этих кнопок так, чтобы не множить функции? Постраничного листания нет, подгрузки при прокрутке тоже.

или

На странице отображаются 5 000 товаров с партиями, остатками, необходимо изменять эти данные. Что бы вы стали делать, если бы страница стала тормозить? Как бы вы искали источник проблемы?

Да никак бы я не искал источник проблемы. Потому, что источник уже найден — это вывод на экран тысяч экземпляров данных.

В этом нет никакой необходимости. Никакой человек не может управлять данными, когда их тысячи. Нашему мозгу уже и 30 штук — довольно много. Правильное решение: сделать так, чтобы на фронтенде не отображались, не хранились, и не обрабатывались тысячи элементов. Тогда и не нужно будет решать эти надуманные задачи.

Архитектура фронтенда: смена фреймворка

Сергей Копылов — Tue, 25 Feb 2020 13:43:01 +0300

В предыдущей части я рассказал, почему хорошо создавать конфигурации — JSON-описания поведения страниц без программирования.

У этого подхода есть ещё один прекрасный плюс: смена фреймворка перестаёт быть невыполнимой задачей.

Если вы используете конфигурации, то компоненты страницы внутри шаблона могут быть написаны на любом фреймворке: AngualrJS 1.x, Angular, Vue.js, React, Svelte и так далее. Вы даже можете их смешивать, и переписывать пошагово, когда часть компонентов использует один фреймворк, а часть — другой.

Таким образом, продукт и компания перестают быть связаны устаревшими технологиями, и если фреймворк перестанет поддерживаться, работа не остановится. Конечно, переезд не станет лёгким делом и займёт несколько месяцев, но без конфигураций страниц переехать будет просто невозможно без переписывания каждой страницы вручную. Именно так и получаются ситуации, когда в одном проекте есть Бекбон, Джейквери, Реакт разных версий и только избранные разработчики могут без страха менять что-то в легаси-модулях.

Архитектура фронтенда: конфигурации

Сергей Копылов — Mon, 24 Feb 2020 20:24:20 +0300

Я долго работал над большими проектами для администирования, когда в системе есть очень много данных, и много страниц, для управления ими. Много — это, например, 500 страниц. И я использовал довольно естественный подход, когда каждая страница конфигурируется, а не программируется. Что-то вроде такого:

import ...
...

export default {
    url: "orders/:id", // Адрес страницы с подстановкой данных
    template: "formPage", // Какой шаблон страницы использовать
    data: { // Данные и обработчики данных
        value: (id) => Data.get(Orders, {id: id}, // Набор значений полей заказа с сервера
        fields: fields, // Набор полей по порядку с их параметрами, подключаемый из другого файла,
        onSave: (id) => Data.save(Orders,  {id: id})
    }
}

Это, конечно, псевдокод, но он показывает сам принцип:

Существует сервис Data, который умеет получать данные с сервера и отправлять их обратно. Вообще говоря, неважно, хранит ли он их на сервере, или в локалсторадж, к примеру, странице-то это неважно;
Существует Orders — описание того, как именно сохранять или получать заказы, внутри — просто JSON с параметрами, которые переиспользуются на разных страницах;
fields — это JSON-описание набора полей: в каком они порядке, как взаимосвязаны друг с другом, в каком из них какое поле из data отображается, какого они типа и так далее.

Получается, что новому разработчику вообще не нужно уметь программировать, а нужно только описать два JSON-файла:

Набор полей
По какому адресу и с какими дополнительными параметрами можно получить и записать данные о заказе на сервере.

Если к этому есть документация, или, хотя бы много примеров (а когда страниц 500, то и примеров в избытке) — это несложно, и, что важнее, очень быстро для исправления или переработки.

Всё. Как именно сохранять данные и когда отправлять их на сервер и в каком виде знает сервис Data; компоненты на странице знают, как именно отрисовывать поля ввода. Разработчику ненужно парится об отступах и расположении элементов, об отображении индикатора загрузки при сохранении и вообще о том, как устроен конкретный шаблон, достаточно просто его сконфигурировать.

Но оказалось, что этот способ используется очень редко потому, что дизайнеры рисуют разные макеты, потому, что кажется, что существующим шаблоном не решить задачу и так далее. Все эти проблемы надуманы — нужно стараться решить задачу существующими средствами, точечно дорабатывая их, когда не получается. Но это тема другой статьи