Решил попробовать силы в LWC, и для начала переделать ВФ страницу в LWC компоненты.
Есть ВФ страница и контроллер.
Контроллер работает с замысловатым и ветвистым деревом связанных записей, выполняя логику приложения, выполняет ДМЛ операции и прочее.
ВФ страница имеет боковое меню-список и главную часть, которая ререндерится при клике на элементе бокового меню. Ререндерится она может очень по разному, здесь вовлекаются ВФ компоненты: от простой группы инпутов, до сложных таблиц с фронт-энд калькуляцией и редактируемых списков связанных записей. Есть JS который помогает рендерить и валидировать главную секцию.
Данные из контроллера передаются на ВФ страницу разумеется в виде сложных объектов-wrapper (DTO-объектов или как там они по-научному называется), то есть такой объект собирается в результате сложной логики работы приложения и может включать другие записи и прочее.
Довольно типичная и тяжелая ВФ страница. Взял именно ее, а не что-то простое. Почему?
В многочисленных трейлхед заданиях по LWC создаются компоненты, но они очень просты и наивны: в них нет бизнес-логики, данные просто кверятся и сразу же, как есть выводятся пользователю. Это очень ванильные ситуации, которые наглядно объясняют базовым принципы как работают LWC, но они очень далеки от народа. Реальные ситуации гораздо более сложны, и именно поэтому там нужны разрабы.
Пока не буду вдоваться во все детали "перевода" моей ВФ в LWC компоненты, это еще не начато, вопрос более глобальный, архитектурный: где поместить всю логику приложения?
есть два варианта выполнения задания:
(1) End developer way: LWC компоненты воспринимаются как продвинутая и более интерактивная версия ВФ страницы и ее ВФ компонентов. То есть теперь все оформлено в виде красивых и живых компонентов. Модно, стильно, современно.
А бизнес логика сидит все в том же апекс контроллере, только теперь его методы помечены @AuraEnabled(cacheable=true)
и данные передаются на фронт в виде все тех же объектов-wrapper.
(2) Front developer way: LWC компоненты - это самодостаточная вещь, никаких больше апекс-контроллеров. В этом случае вся логика приложения выполняется на фронте, с бек-эндом компоненты сообщаются только как с БД, т.е. выполняют только ДМЛ операции.
Этот вариант наиболее радикальный и сразу вызывает множество вопросов:
- вся ли логика может быть перенесена на фронт и что-то должно быть оставлено на сервере по соображением безопасности. Это конечно зависит от того, что у нас в контроллере, но тем не менее теперь об нужно более внимательно подумать.
- какое именно АПИ использовать, чтобы сообщаться с сервером?
- как всю эту логику раскидать по компонентам, в каком их них хранить state страницы?
пока я склоняюсь к первому варианту, как более реалистичному, только сама конвертация ВФ страницы и ее ВФ компонентов в LWC компоненты будте очень утомительным, а чтоб еще думать про бизнес -логику, это уже следующий уровень
Вариант №1!
Бизнес логика (подготовка данных, рассчеты и изменения базы данных) ислючительно в бэкенде.
Фронтенд - это подготовка данных для рендеринга, рендеринг и валидация пользовательских данных. На фронте никакой бизнес логики!
Касаемо твоей задачи:
1. никаких сложных DTO для отправки данных на фронт.
Максимум это объект в виде
{
accounts: [],
tasks: [],
...
}то есть данных бэкенд отдает в самом примитивном образе - как достал из базы так и отправил (максимум почистил лишние поля чтобы не светить если такие будут). Как я сказал фронтенд сам подготавливает данные для отображения уже на фронте строятся сложные структуры для вывода инфы на экран. !ВАЖНО: это кстати может быть и не один запрос, а 10! Отдельно достать accounts, отдельно tasks. Так можно будет безболезненно подключаться хоть к AuraEnabled методам, хоть напрямую к SF API, хоть к внешним сервисам. Тут главное помнить что бэкенд не должен заботиться о фронтенде, он только возвращает данные.
2. Валидация уже становится сложнее. Она становится двойной. На фронте валидируется пользовательский ввод на адекватность. На бэкенде валидация, которая посложнее и требует связи с БД. В идеале бэкенд дублирует валидацию фронтенда на адекватность пользовательского ввода (мало ли с какого фронта придут данных).
3. На счет "стейта". Тяжелый фронтенд уже подразумевает что у тебя будет свой стейт на фронтенде. Не знаю что есть в LWC для этого, но на ангуляре я использую один глобальный класс-сервис который тупо шарю между компонентами. Этот принцип у фронтенд гиков называется Redux (можешь почитать на досуге), но его реализация в разных фреймфорках часто вызывает затуп. Поэтому я делаю проще как описал про "класс-сервис".
