а куда его передавать и зачем? Вот есть центральный объект Pub/Sub через него все общаются. Удобно ведь, а там коллбек в коллбеке, тот же коллбекхелл но я так понял что ради ассинхронности. Так событиями на оборот еще лучше с ассинхронностью работать и нет лапшекода, т.к. по файлам можно разбить код

Забудь про > Так событиями на оборот еще лучше с ассинхронностью работать и нет лапшекода, т.к. по файлам можно разбить код

императивный слой, все дела кто-то должен координировать происходящее

и ты не всегда сможешь (и будет удобно) писать с событиями там, где с промисами все +- хорошо

а зачем тебе промисы с событиями

послал и забыл

это ж событие а не команды какие-нибудь)

а зачем тебе промисы с событиями

так не мне) насколько я понял, @artnv хочет размазать обработку зарезолвившихся промисов по хендлерам событий

Я делаю события только для штук которые попадут в очередь (не всегда) Для остального я делаю сервисы и вызываю в нужных местах, почему бы и нет

я вот не понимаю все это. Если все эти фишки использовать по полной еще хуже можно наворотить

Я делаю события только для штук которые попадут в очередь (не всегда) Для остального я делаю сервисы и вызываю в нужных местах, почему бы и нет

угу, тоже хочу на такое перейти (от command bus) ну и в очередь = асинхронные штуки

я вот не понимаю все это. Если все эти фишки использовать по полной еще хуже можно наворотить

Ну а зачем тебе на каждый ответ создавать событие (просто чтобы обработать)?

То что ты вынесешь код с одного файла в другой ничем особо не поможет

Объясни зачем ты хочешь это сделать, возможно, мы просто не понимаем :)

Ну а зачем тебе на каждый ответ создавать событие (просто чтобы обработать)?

https://github.com/artnv/ecommerce-demo/raw/master/screenshots/app_events_mvc.png?raw=true

Тоже мысль пришла что думаем о разных задачах и отвечаем)

угу, тоже хочу на такое перейти (от command bus) ну и в очередь = асинхронные штуки

Это вроде как по твоей части

тут странное...

ну во-первых имхо спутаны понятия команды и события

хотя...

да нет, не спутаны, тут четко все

меня смущает разделение controller и view в этой ситуации

т.к. это явно не mvc и даже не mvp

меня смущает разделение controller и view в этой ситуации

Да вроде как все логично Роутер -> Контроллер -> поехали дальше

Меня правда смущает то что модель потом в события кидает

просто контроллер потом дергает модель, а ивент от модели ВНЕЗАПНО летит во view

А, он во вьюху полетел, не доглядел.

это вроде бы частично mvc-like типа вью реагирует на событие модели но блин, выборка - это не событие

ну и обратная связь от вью идет через контроллер...

Если убрать контроллер и сделать привязку вьюшки на модель - все будет хорошо

какая-то смесь mvc и mvp имхо

Если убрать контроллер и сделать привязку вьюшки на модель - все будет хорошо

какая-то прослойка между роутером и моделью должна быть

какая-то прослойка между роутером и моделью должна быть

Ну, я когда писал на Qt, все что у меня было - view (QML) + model (прослойки я сам делал, но они не нужны были по факту) Там автоматическая подписка на изменение свойств модели + можно вручную все это делать (уведомить модель например)

Я не знаю применимо ли это к джсу (так как не юзаю его), но на пыху точно не прикрутить

меня смущает разделение controller и view в этой ситуации

тут js тут свои порядки). Можно было бы в контроллере получить данные из модели и передать в представление, но а как быть с ассинхронностью? Если модель запросит данные по аяксу? Когда данные придут пуляется событие на которое подписана представление. Ну как-то так)

@artnv ты из статьи какой-то взял это?

тут js тут свои порядки). Можно было бы в контроллере получить данные из модели и передать в представление, но а как быть с ассинхронностью? Если модель запросит данные по аяксу? Когда данные придут пуляется событие на которое подписана представление. Ну как-то так)

А почему представление? Ответ нужно обработать

@artnv ты из статьи какой-то взял это?

из своей головы

Если там не валидные данные или сервер умер?

тут js тут свои порядки). Можно было бы в контроллере получить данные из модели и передать в представление, но а как быть с ассинхронностью? Если модель запросит данные по аяксу? Когда данные придут пуляется событие на которое подписана представление. Ну как-то так)

а на чем такое написано?

а на чем такое написано?

Вангую - вью

я планирую в отдельный пустой проект вынести все

чтобы юзать можно было

не знаю, зачем такое не вью, если есть vuex ?

аналогично и реакт

я планирую в отдельный пустой проект вынести все

> Когда данные придут пуляется событие на которое подписана представление Я не понимаю почему так

не, роутер от бекбона и события. Но архитектура позваляет их не использовать а исаользовать от других библиотек

я тут проконсультировался в соседнем чате, там вуе тоже можно использовать короче

не, роутер от бекбона и события. Но архитектура позваляет их не использовать а исаользовать от других библиотек

тут хз, я очень давно не писал на подобных фронт-фреймах (был только первый ангулар)

я тут проконсультировался в соседнем чате, там вуе тоже можно использовать короче

Там разбили компоненты и вьюшки в последних версиях

я тут проконсультировался в соседнем чате, там вуе тоже можно использовать короче

хе, сижу пишу тут, а тот чат игнорю)

Там разбили компоненты и вьюшки в последних версиях

мм?

мм?

Там теперь есть вьюшка которую ты собираешь из компонентов

А не компонент - отображение

Там теперь есть вьюшка которую ты собираешь из компонентов

кинь ссыль или запрос в гугл, я гляну

https://github.com/vuejs/vue-hackernews-2.0/tree/master/src

https://github.com/vuejs/vue-hackernews-2.0/tree/master/src

ItemView их?

или App.vue?

Да, Item

Я ставил полгода назад - были только компоненты ?

дык это тоже компонент

и я на вью уже с полгода точно пишу понемногу

а то и больше

Ну, значит они не закидывали это во vue-cli

Ну, значит они не закидывали это во vue-cli

тут возможно но вот такая идея есть давно

Ибо я поставил позавчера и немного "испугался"

тут возможно но вот такая идея есть давно

Понял, пасиба

> Когда данные придут пуляется событие на которое подписана представление Я не понимаю почему так

Модель ака метод который запрашивает данные допустим о товаре, его описание, отправляет ajax запрос на сервер, как данные приходят срабатывает коллбек по приходу данных, этот же коллбек вызывает событие: app.eventManager.trigger('Models/product/getData', 'данные'); app - единственное глобальное свойство, которое доступно во всех модулях. 1-ый аргумент адрес где оно произошло, чтобы легче искать было если что, можно и краткой записать event_1 но так придется по всем файлам лазить искать откуда оно сработало. Директория Models, product - название модуля, getData - метод модуля 2-ой аргумент данные из ajax запроса. Теперь app.eventManager.trigger будет искать и запускать все методы, с именем события с которым совпадает 'Models/product/getData'. И наше представление подписано на это событие. app.eventManager.on('Models/product/getData', showData); теперь запустится метод showData который получит данные из передаваемых аргументов и отобразит на странице инфу. модели и представления хранятся в разных директориях и друг о друге ничего не знают. Они только реагируют на события и так же отвечают. Гугли короче паттерн наблюдатель и pub/sub вот от бекбона, просто посмотреть что это http://backbonejs.ru/#Events

все, пойду на велике катну пока светло)

расслабиться :D

Мне лень эту простыню читать :(

Мне лень эту простыню читать :(

ну там просто шина событий описана tldr

я не понимаю одного: зачем в 2к18 (тролльфейс.жпг) писать модели на фронте, если есть fluxоподобные штуки?

Хм, новая книга дяди Боба тоже этот момент осветила: фп и =. Совпадение?

отзывы чота неочень

ну это мой велосипед потому-что) А так посмотри тот проект. Код разделен. Есть контроллеры для сайта, для админки, так же можно задать директории для моделей и для представлений, для виджетов и компонентов. Короче можно приложение расширять вдоль и поперек при этом сохранив быстрый доступ к коду. Модули друг о друге ничего не знают, если есть зависимости то они передаютя в DI контейнере и того получается слабосвязанный код. Модули содержат только свои методы. Например корзина только методы корзины, отсюда и единственная ответственность. В ручную подключать файлы не нужно, есть пространства имен и все подключится туда куда нужно а gulp все сам соберет в один файл. Так же можно подключить Vue. Во время инициализации Vue будет в памяти. А события будут вызывать хендлеры которые будут получать данные, а Vue просто отображать на странице. Кстати Vue тоже ничего не будет знать об архитекторуре, он будет только в рамках view просто получать данные и отображать. А в момент вызова хендлера можно так же биндить ко всяким чекбоксам динамически В общем мне нравится) Вот схема https://raw.githubusercontent.com/artnv/ecommerce-demo/master/screenshots/app_architecture.png

я не понимаю одного: зачем в 2к18 (тролльфейс.жпг) писать модели на фронте, если есть fluxоподобные штуки?

про flux слышал но пока не читал)

отзывы чота неочень

Коллеги книга была, я чуть полистал тока ?‍♀️

про flux слышал но пока не читал)

ну это redux/vuex/mobx и прочие

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

тут хорошо типизация легла бы

с событиями очень нравится самому), как-то что-то делал, перекладывал файлы, не помню и все не рушится от отстутсвия какого-то модуля. Можно тупо часть функционала убрать тупо удалением или перемещением но все остально будет так же работать, потому-что все модули не знают ничего друг о друге. И те же ассинхронные запросы от ajax

типизация как в php? на интерфейсах и возвращаемый тип function abc() : className?

flow/typescript имею ввиду)

reactphp еще

amphp "более лучше")

amphp "более лучше")

ты знаешь мое мнение) хоть у меня и лежало немного инфы по асинк пхп в трелло, но читать я ее, конечно, не буду

типизация как в php? на интерфейсах и возвращаемый тип function abc() : className?

Стат типизация

Стат типизация

Ну, в смысле int s(int a, int b) => a + b;

ты знаешь мое мнение) хоть у меня и лежало немного инфы по асинк пхп в трелло, но читать я ее, конечно, не буду

swoole и пхп почти как go)

почти, но зачем?)

интеграция, не спорю

Абы було

почти, но зачем?)

что бы об go руки не пачкать)

что бы об go руки не пачкать)

Лучше уж об go)

почти, но зачем?)

+1, нахуя..

почти, но зачем?)

а вообще почитать стоит хотя бы для общего развития) оно есть и +/- работает)

а вообще почитать стоит хотя бы для общего развития) оно есть и +/- работает)

ну опять-таки, я хочу почитать и пощупать асинхронность и многопоточность в тех языках, которые с этим были написаны - зачем мне для этого php? только впечатление испорчу) p.s. js с async/await неинтересно ;D

ну опять-таки, я хочу почитать и пощупать асинхронность и многопоточность в тех языках, которые с этим были написаны - зачем мне для этого php? только впечатление испорчу) p.s. js с async/await неинтересно ;D

одно другому не мешает от слова совсем)

одно другому не мешает от слова совсем)

не мешает, не спорю но тем не менее прио асинк пхп штук на порядок ниже остальных

не мешает, не спорю но тем не менее прио асинк пхп штук на порядок ниже остальных

приорити зависит от текущего стека)

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