OR
Это да, в идеале так и должно быть.
Size: a a a
2021 October 25
AC
Я бы чёт вроде ре-фрейма сделал
AC
Чтобы ошибки отдельно эффекты отдельно
AC
Почему так не делают
OR
Ну, не обязательно повторять ре-фрейм, всё-таки он под определённые задачи делался. А вот идей можно оттуда взять.
LL
Ну будет грязный код в другом месте вызываться, где будет та же самая проблема
OR
Вообще вон в Grokking Simplicity нормально Эрик предлагает делать в этом плане, даже не смотря на то, что по поводу разбиения на "маленькие" функции у меня есть сомнения.
AC
Ну ты можешь вызывать его там где есть шанс обработать ошибку
MB
Может в pre засунуть валидацию? Оно ж вроде для этого как раз?
AC
Ну а дальше что?
AC
Если подумать - результат работы рефрейма - это вектор из векторов который потом рендерится в html. Можно то же самое на бэкэнде делать только рендерить в http response
AC
То есть тебе пришёл запрос - это можно воспринимать как как будто пользователь ввёл что-то в input и нажал кнопку
AC
Дальше ты шлешь все нужные эвенты, подписываешься на ответы и ждёшь
AC
А потом рендеришь ответ на запрос
AC
Таким образом ты можешь в условной app db иметь ключ errors куда все могут складывать ошибки а обработчик на них может подписаться
OR
Это да, такие мысли постоянно посещают. Ещё бы так же сделать общение с БД )
AC
Н вообщем я так понимаю в джаве к тому и идёт все
AC
Там вроде завозят грин треды, асинк итд
KC
Лол, на следующей неделе планировал заопенсорсить что-то похожее на это)
AC
Ну вот все в одном направлении думают, востребованная тема /)