Настройка колонок грида

[gsbelarus]

Исходные данные

1. У нас основная единица данных -- это сущность, которая имеет атрибуты. Имена сущностей в рамках одной ER-Model уникальны. В пределах одной сущности имена атрибутов уникальны.
2. Кроме своих имен, сущности и атрибуты имеют еще локализованные названия. Именно их использует система при организации пользовательского интерфейса -- заголовки колонок грида, подписи к полям ввода.
3. Если используется реляционная база данных, то сущность хранится в одной или нескольких таблицах. В зависимости от типа атрибута, ему может соответствовать поле в таблице, другая таблица (атрибут-ссылка), множество записей в другой таблице, подключенной через кросс-таблицу (атрибут-множество).
4. В гриде отображается либо результат выполнения EntityQuery, либо результат выполнения SQL запроса. Причем, такой запрос может содержать данные нескольких сущностей, объединенных по заданным критериям, включая и сущности одного типа. Например, запрос, который выводит накладные может включать сущность Организация один раз для Поставщика, другой раз -- для Покупателя, и третий -- для Грузоперевозчика.
5. Каждая колонка грида имеет свое наименование (это больше внутренняя информация, для программиста) и заголовок, который формируется, как правило, из локализованного названия атрибута, отображаемого в данной колонке.

Настройка колонок грида

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

1. подавляющее большинство настроек и форматов должно приходить с уровней ER Model и дефолтных настроек системы и, таким образом, не нуждаться в настройке пользователем на уровне грида.
2. если же пользователю что-то и надо настроить под себя, то в хранилище должно сохраняться только это, конкретное, отдельное изменение, а не как в Гедымине, где всегда сохраняются все настройки грида. Т.е. мы должны уметь разделять что пришло к нам с уровня ER Model, что с дефолтных настроек системы, а что было настроено пользователем. Причем, у пользователя должна быть возможность отказаться от всех своих сделанных изменений и скинуть настройки для грида в исходное состояние.
3. надо ли нам отдельное окно для настройки форматов и выравнивания полей? например, в электронных таблицах микрософта или гугла форматы чисел, дат, выравнивание колонки настраиваются без отдельного окна. Пользователь устанавливает курсор в интересующую его колонку и на панели инструменов (или из меню) выбирает нужный формат.
4. в таком случае возникает вопрос, что делать со сложным отображением, когда в одной клетке выводится несколько полей одного типа? одно из решений -- в меню (списке) где выбираются доступные форматы, в верхней части предусмотреть выбор поля, для которого будет установлен формат.
5. если мы уберем настройку форматов и выравниваний из окна, то для него у нас останутся следующие функции: а) список всех колонок с возможностью сделать колонку видимой или скрыть ее, б) возможность сменить заголовок колонки, в) посмотреть какой именно атрибут, какой сущности выводится в данной колонке (см. пример выше с накладной, где выводятся атрибуты из трех разных сущностей типа Организация -- покупателя, поставщика и грузоперевозчика). Опять таки платформа должна работать таким образом, чтобы у простого пользователя не возникла потребность опускаться на такой низкий уровень. Т.е. локализованный заголовок колонки должен всегда формироваться понятным образом. Например, Покупатель, Адрес покупателя, Телефон покупателя, Продавец, Адрес продавца, Телефон продавца... А не Наименование, Наименование, Наименование, как у нас часто получается в Гедымине. Формирование таких, корректных заголовков, скорее всего не должно быть частью грида, а частью кода формирования запроса и интерпретации его результата.

Дальнейшее развитие

Пока мы говорим о следующих возможностях:

1. Смена заголовка колонки
2. Видимость
3. Выравнивание
4. Формат для числа
5. Формат для даты/времени

В будущем понадобится настройка:

1. внешнего вида (шрифт, цвет и т.п.). Зависит от механизма визуальных тем, который нам еще стоит применить и механизма настройки внешнего вида окна (дизайнера).
2. Условного форматирования. Зависит от механизма выполнения программного кода.

Где сохранять настройки грида

Временно сохраняем в локал сторадж браузера. Привязываемся к url окна.

[gsbelarus]

1. В грид через props передаем только один исходный набор колонок. Не фильтруем их по видимости.
2. В стэйт грида храним настройки пользователя (их изначально считываем из локал сторадж в конструкторе) и результирующий набор колонок, от которого собственно все и отображается на экране.
3. В getDerivedStateFromProps берем полный набор колонок из props и пользовательские настройки из стэйт и на основе них получаем результирующий набор колонок, который записываем в стэйт.
4. На вход диалогового окна настроек через пропс передаем полный набор колонок и пользовательские настройки.
5. В процессе настройки пользователем внешнего вида в диалоговом окне смотрим что меняет пользователь. Меняем пользовательские настройки и вызываем ивент (передается вместе с пропсами из грида), куда передаем новые пользовательские настройки. Этот ивент записывает их в локал сторадж, сохраняет в стэйт грида, вычисляет новые актуальные колонки на основе полного списка колонок из пропс грида и пользовательских настроек и записывает в стэйт грида, что приводит к перерисовке грида и окна настроек.