я тебя не понимаю, как ты узнаешь в твоем случае , что запустится анимация?

если метод называется runPressAnimation

По имени метода?

а где ты увидишь имя метода?

В неком компоненте у тебя на клик написано runPressAnimation

ага, т.е. я читаю код компонента?

Да

тогда я вижу код метода onClick

В том то и дело - читая код компонента ты знаешь какие будут сайд-эффекты

и все это занимает 30 строк вместе

То есть перемешка бизнес-логики и отображения?

Процедурный подход?

шта?

я предлагаю отделить

логику работы анимации, от логики обработки события клика

и других событий

Вот конкретный пример - есть конкртеная вью, в ней содержатся кнопки. Что будет лучше - 100500 значений аля onClickMySuperButton или на каждой кнопке имена методов вида submitForm, playMusic, runMyScript и тп?

если у вас там 100500 значений, то вы проиграли

То есть сложные формы это что-то необычное?

декомпозиция, все дела...

компоненты там

если у вас есть что-то большое, то это "скорее всего" проблема

submitForm и playMusic методы рядом простите cohesion тут примерно как у класса Manager или файла utils

То есть 100500 компонентов по одному на каждую кнопку в каждом котором один и тот же метод onClick который делает каждый раз что-то новое о котором ты не узнаешь не открыв каждый этот компонент и не прочитав код?

Но наверное я знаю почему такой тред вообще возник

Есть ещё особый кейс

Когда мы осмысленно пишем имя компонента, а там уже типичные onClick и 100500 подобных методов. И когда ты смотришь на компонент submitButton ты в целом то догадываешься что делает его обработчик onClick

Но про такой кейс я писал выше

Мол можно если скоп исполнения ясен

получается у кого работать после праздников? чет ваще тяжко идет

даже читать вас не могу

То есть 100500 компонентов по одному на каждую кнопку в каждом котором один и тот же метод onClick который делает каждый раз что-то новое о котором ты не узнаешь не открыв каждый этот компонент и не прочитав код?

в компоненте MusicPlayer во внешнем api нет никакого onClick, есть всякие onPause и прочее, внутри всякие onClick как обработчики кликов по кнопкам play/pause

и да, 100500 компонентов с явной зоной ответственности > один god object

Вот мы так сейчас на конкретных примерах то далеко уйдем - потому что конкретные у нас у всех будут разные ?

про music ты сам предложил)

и да, 100500 компонентов с явной зоной ответственности > один god object

О да, оное то понятно что нужно разбивать

Но могут быть ещё такие подходы как MVC с их контроллерами

блин, вас не перебить

Хотя это мы так совсем далеко уйдем

Но могут быть ещё такие подходы как MVC с их контроллерами

давай под mvc подразумевать redux+react, чтобы говорить о чем-то конкретном, потому что о варианте дедушки Тругве сейчас не выйдет

Но могут быть ещё такие подходы как MVC с их контроллерами

и mvc подразумевает разбиение на очень маленькие части

Всем привет, нужна помощь с Яндекс.Картами, не могу понять в чем ошибка самой либы Яндекса. https://jsfiddle.net/frontenddeveloping/936drznz/ Спасибо!

давай под mvc подразумевать redux+react, чтобы говорить о чем-то конкретном, потому что о варианте дедушки Тругве сейчас не выйдет

Да тут даже не в этом дело. Тут всё-таки видимо дело в том что о разных подходах в принципе говорим. В целом если имеется микрокомпонент который в названии имеет исчерпывающее описание а что он делает - да, всякие методы вида onName более-менее, но подходят. Причем он можнет быть микрокомпонентом на своем текущем уровне, при этом наследуя 100500 функциональности. Правда это порождает в некоторых случаях проблему расширяемости, если компонент вдруг начнет делать чуть больше чем простейшие действия и иметь чуть болше логики чем есть в имени этого компонента. Особенно это касается сайд-эффектов.

А если у нас есть некий контроллер, который перехватывает эвенты компонентов и содержит бизнес-логику - вот тут уже просто онклики не подойдут

Да тут даже не в этом дело. Тут всё-таки видимо дело в том что о разных подходах в принципе говорим. В целом если имеется микрокомпонент который в названии имеет исчерпывающее описание а что он делает - да, всякие методы вида onName более-менее, но подходят. Причем он можнет быть микрокомпонентом на своем текущем уровне, при этом наследуя 100500 функциональности. Правда это порождает в некоторых случаях проблему расширяемости, если компонент вдруг начнет делать чуть больше чем простейшие действия и иметь чуть болше логики чем есть в имени этого компонента. Особенно это касается сайд-эффектов.

не люблю слово наследуя и вообще наследование...

А если у нас есть некий контроллер, который перехватывает эвенты компонентов и содержит бизнес-логику - вот тут уже просто онклики не подойдут

у вас год-обжект

я бы сделал картинку с доктором, но мне лень(

у вас год-обжект

И как же оно вдруг стало год-общектом?

может еще не год, но точно с завышенной самооценкой, и перехватывает события, и бизнес-логикой рулит

еще возможно немного вью правит

ляпота

Ну вот у меня есть таблица

С редактированием ячеек

И несколькими кнопками отправки там, отмены данных и всего такого

Вопрос

Как такое адекватно контролить не используя единого контроллера?

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

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

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

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

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

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

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

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

в модель?

ERROR: S client not available

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

в модель?

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

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

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

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

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

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

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

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

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

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

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

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

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

От вью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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