Перепиливаем ВФ страницу в LWC компоненты: где логика?

Перепиливаем ВФ страницу в LWC компоненты: где логика?

Решил попробовать силы в 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 (можешь почитать на досуге), но его реализация в разных фреймфорках часто вызывает затуп. Поэтому я делаю проще как описал про "класс-сервис".

Interesting information? Help us, post link to social media..