То есть не воспринимая редактируемый грид как единый компонент?

А чем в этом случае плохо использование единого контроллера? Так с ходу ничего в голову не приходит

То есть не воспринимая редактируемый грид как единый компонент?

есть единый компонент SpecificGridForSomeScreen, который в себе рендерит грид со строками, есть эти самые строки, в которых всякие onFirstAction onOtherAction. SpecificGridForSomeScreen мапит формат onFirstAction для строки в someApplicationLayerAction из приложения

итого вся задача единого контроллера простой мапинг, никакой логики в нем нет

Ну то есть единый контроллер таки есть

а бизнес-логики в нем нет

А куда же её положить то?

в модель?

То есть делегируем бизнес-логику в модель

в модель?

И в чем толк от такого перемещения?

Ну тоже самое, только вызовы будут пробегать через контроллер в модель

Разве модель не должна отвечать только за данные

И в чем толк от такого перемещения?

в том, что бизнес-логика может быть протестирована и использована отдельно от view?

Да и с контроллером также

Если логика будет там

Но а на сколько хорошо, что мы в модель перенесли логику?

он привязан к структуре ивентов от view

Но а на сколько хорошо, что мы в модель перенесли логику?

модель только для логики и нужна

А если селекторами привязана?

Или эвенты слушает?

От вью

Ну и в целом таки получается просто перепасовка

А если селекторами привязана?

а кто привязал?)

Вью оповестила всех, кто знал как - тот подключился к прослушке

Но это уже могут быть нюансы всяких там фреймворков и прочего

ну вот, контроллеру нужно знать про шину или еще какой-то интерфейс общения с view

Т.е. у нас толстые модели, тонкие контроллеры?

и передавать это в модель

Т.е. у нас толстые модели, тонкие контроллеры?

вообще у нас не должно быть ничего толстого)

и передавать это в модель

с нужными преобразованиями

вообще у нас не должно быть ничего толстого)

Тогда нужно разбивать толстые модели на более мелкие и атомарные?

Как избежать этих толстяков?)

декомпозицией

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

Подход с делением на 5 частей.

тонкие модели/толстые контроллеры это процедурщина

да, так тоже делают

Где-то даже в википедии есть шутка про PHP и толстые модели

Но суть сводится к тому что всякие onName методы стоит делать только если компонент на столько мал что по его названию уже понятно что будет происходить и мы точно уверены что компонент не разрастется

Во всех остальных случаях лучше воспользоваться более подробным неймингом методов

лучше избегать остальных случаев

Невозможно

Утопия

Я привел пример с гридом

так мы ж легко с ним справились?

Нет

а в чем проблема, чет непонятно

Там есть несколько кнопок

onFirstAction, onSecondAction

onEdit

onRemove

ну и че там

А

Ну так вот

так это вверху

внизу-то onClick

Ну по сути и тоже самое

😄

Ну и в целом конечно можно, но странно делать у компонента onClick и в нем писать controller.onEdit или типа того когда можно сразу onEdit

Или просто edit

А также firstAction, secondAction и remove

Потому что зачем нам on когда мы действие конкретное делаем

А то что оное на клик по кнопке вызывается - это дело самой кнопки, а не нашей бизнес-логики

Ну и в целом конечно можно, но странно делать у компонента onClick и в нем писать controller.onEdit или типа того когда можно сразу onEdit

нельзя, форматы разные

onClick возвращает ClickEvent какой-нибудь dom-node, а onEdit ивент с редактируемой сущностью

Вот оно что

Про разное чуть-чуть поговорили

А хотя нет

Зависит от уровня абстракции

У нас есть кнопка удаления, мы жмем на неё, мы хотим получить удаление, допустим, строки, около которой находится эта кнопка. Кнопка может сама поймать эвент клика и сообщить другим что её нажали, а можем мы и сами ловить контроллером клик на компоненте и словить собственно объект эвента.

От реализации зависит в общем-то

можем мы, но тогда нам нужен индекс строки или еще какой-то указатель в ивенте. Получать результат голого onClick чет как-то не очень

Если кнопка как компонент сама может оповещать нашу эвент-систему о том что на неё кликнули - нам уже нужен конкретный нейминг

Затянулся спор то 😄

Надеюсь те 1549 человек что его читали - смогут найти в нем для себя что-то полезное

хыхы

Надеюсь те 1549 человек что его читали - смогут найти в нем для себя что-то полезное

нет (

ETOOMUCH

😄

ребят, всем привет, я из криокамеры