Ale
:)
Oleg
Вот, а теперь попробуй догадайся что происходит внутри не читая исходники
Ale
чьи исходники?
Oleg
Метода
Ale
вот сейчас не уловил кейс, ты руками хочешь вызвать onClick?
Ale
зачем тебе знать, как работает onClick у компонента
Ale
в ситуации, когда ты не можешь открыть исходники
Ale
я понимаю про код, который ты хочешь вызвать
Ale
а это то, что вызывает внешняя инфраструктура, это по сути адаптер
Oleg
зачем тебе знать, как работает onClick у компонента
эм... затем чтобы знать что именно он будет делать. Кнопка будет анимироваться нажатием и всё? А может там ещё отправка формы? Или оно только откроет мне окошко?
Ale
ты его открыл и видишь все
Ale
ага, здесь анимация
Oleg
Вот! В этом то и проблема
Oleg
Чтобы понять - нужно код читать
Ale
в каком случае ты видишь метод компонента работы с внешним миром и не видишь его реализации?
Oleg
Это как однобуквенные переменные
Oleg
А что
Oleg
Берешь и читаешь
Oleg
Таааак... тут мы присвоили число
Oleg
Значит q это число
Oleg
Так, а что у нас в z....
Oleg
И тп
Ale
я тебя не понимаю, как ты узнаешь в твоем случае , что запустится анимация?
Ale
если метод называется runPressAnimation
Oleg
По имени метода?
Ale
а где ты увидишь имя метода?
Oleg
В неком компоненте у тебя на клик написано runPressAnimation
Ale
ага, т.е. я читаю код компонента?
Oleg
Да
Ale
тогда я вижу код метода onClick
Oleg
В том то и дело - читая код компонента ты знаешь какие будут сайд-эффекты
Ale
и все это занимает 30 строк вместе
Oleg
То есть перемешка бизнес-логики и отображения?
Oleg
Процедурный подход?
Ale
шта?
Ale
я предлагаю отделить
Ale
логику работы анимации, от логики обработки события клика
Ale
и других событий
Oleg
Вот конкретный пример - есть конкртеная вью, в ней содержатся кнопки. Что будет лучше - 100500 значений аля onClickMySuperButton или на каждой кнопке имена методов вида submitForm, playMusic, runMyScript и тп?
Ale
если у вас там 100500 значений, то вы проиграли
Oleg
То есть сложные формы это что-то необычное?
Ale
декомпозиция, все дела...
Ale
компоненты там
Ale
если у вас есть что-то большое, то это "скорее всего" проблема
Ale
submitForm и playMusic методы рядом простите cohesion тут примерно как у класса Manager или файла utils
Oleg
То есть 100500 компонентов по одному на каждую кнопку в каждом котором один и тот же метод onClick который делает каждый раз что-то новое о котором ты не узнаешь не открыв каждый этот компонент и не прочитав код?
Oleg
Но наверное я знаю почему такой тред вообще возник
Oleg
Есть ещё особый кейс
Oleg
Когда мы осмысленно пишем имя компонента, а там уже типичные onClick и 100500 подобных методов. И когда ты смотришь на компонент submitButton ты в целом то догадываешься что делает его обработчик onClick
Oleg
Но про такой кейс я писал выше
Oleg
Мол можно если скоп исполнения ясен
Gordey
получается у кого работать после праздников? чет ваще тяжко идет
Gordey
даже читать вас не могу
Ale
и да, 100500 компонентов с явной зоной ответственности > один god object
Oleg
Вот мы так сейчас на конкретных примерах то далеко уйдем - потому что конкретные у нас у всех будут разные 😄
Ale
про music ты сам предложил)
Oleg
Но могут быть ещё такие подходы как MVC с их контроллерами
Gordey
блин, вас не перебить
Oleg
Хотя это мы так совсем далеко уйдем
Ale
Но могут быть ещё такие подходы как MVC с их контроллерами
давай под mvc подразумевать redux+react, чтобы говорить о чем-то конкретном, потому что о варианте дедушки Тругве сейчас не выйдет
Eugene
баян?
Ale
Но могут быть ещё такие подходы как MVC с их контроллерами
и mvc подразумевает разбиение на очень маленькие части
Anonymous
Всем привет, нужна помощь с Яндекс.Картами, не могу понять в чем ошибка самой либы Яндекса. https://jsfiddle.net/frontenddeveloping/936drznz/ Спасибо!
Oleg
давай под mvc подразумевать redux+react, чтобы говорить о чем-то конкретном, потому что о варианте дедушки Тругве сейчас не выйдет
Да тут даже не в этом дело. Тут всё-таки видимо дело в том что о разных подходах в принципе говорим. В целом если имеется микрокомпонент который в названии имеет исчерпывающее описание а что он делает - да, всякие методы вида onName более-менее, но подходят. Причем он можнет быть микрокомпонентом на своем текущем уровне, при этом наследуя 100500 функциональности. Правда это порождает в некоторых случаях проблему расширяемости, если компонент вдруг начнет делать чуть больше чем простейшие действия и иметь чуть болше логики чем есть в имени этого компонента. Особенно это касается сайд-эффектов.
Oleg
А если у нас есть некий контроллер, который перехватывает эвенты компонентов и содержит бизнес-логику - вот тут уже просто онклики не подойдут
Ale
я бы сделал картинку с доктором, но мне лень(
Oleg
у вас год-обжект
И как же оно вдруг стало год-общектом?
Ale
может еще не год, но точно с завышенной самооценкой, и перехватывает события, и бизнес-логикой рулит
Ale
еще возможно немного вью правит
Ale
ляпота
Oleg
Ну вот у меня есть таблица
Oleg
С редактированием ячеек
Oleg
И несколькими кнопками отправки там, отмены данных и всего такого
Oleg
Вопрос
Oleg
Как такое адекватно контролить не используя единого контроллера?