Далааадна

Да

Я же описал как и почему

Это же абстракция, как модульность, только для потока эвентов

Паттерн "фасад" же

Вот, да, я про то же

по прежнему ложная абстракция.

Это не прокси, это просто stream.map(transformFn)

Который возвращает новый стрим

Нет, абстракция обусловленная необходимостью

я описал решение без абстракции

Ибо иначе это будет ад

Один метод, одна функция, один новый объект

А у них что?

Не понял про что ты со стримом

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

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

stream — поток эвентов, "прокси" твой — это просто функция, каким либо образом преобразующая этот поток. Возвращает новый экземпляр стрима

нет никакого "наружу", у компонента есть просто объект stream

Что-то мы похоже про сильно разное

Лол, вот самое смешное, что нет

Но то, что в ооп решают чудовищным набором слоев абстракций — делается парой функций

Концепция reactive — это декларативный путь объявления твоих императивных абстракций. Честно, это все правда делается парой функций

В этом трагедия ооп)) Строили-строили, а в результате — пшик, десятилетие заблуждений

Короче, есть компонент "таблица с кнопками", внутри есть компоненты "таблица", "тулбар", в нем кнопки "добавить строку", удалить строку". Компонент "таблица с кнопками" инкапсулирует всё внутри. Он подписан на события нажатия на соответствующие кнопки. По соответствующему эвенту происходят какие-то действия и в зависимости от результата - эвенты с новым именем файрятся от имени компонента "таблица с кнопками". Итого мы имеем единый программный интерфейс к этому компоненту и не лезем в механику внутри. Однако может быть причина просто пробросить эвент изнутри, вообще ничего не меняя, за исключением того что он будет от имени компонента. Допустим есть тулбар, в нем кнопка и поле ввода, мы можем тулбаром читать эвенты кнопки и поля ввода и пробрасывать их от имени толбара. Но не GUI единым - хранилища данных могут файрить эвенты например по факту добавления новых данных или синхронизации с сервером.

Ты описываешь требовния, не реализацию

Реши мне проблему с "таблица с кнопками" по своему

Реализация вроде же не звучит сложной, хранилище подписчиков и всё такое

Тебе сейчас почему то кажется что я тебе рассказываю про клингонский

Я просто сообщаю как факт, что в данном подходе есть некоторые шаблоны, которые люди уже обобщили, и все эти велосипеды из прокси — уже давно solved problem

И как же?

reactive programming тоже под капотом на них основан

Я вот описал задачу и как решается она проксированием эвентов

Проксирования — это метод chain

Блин, я не буду сейчас тебе всё концепцию с нуля объяснять)) Загугли

Так не интересно :D

Ну прост это всё на примерах кода только объясняется, а в чате это как-то ту мач ?

Просто люди как-то посмотрели на концепцию эвентов и подумали, что они могт тут улучшить. Так то ничего нового не будет, просто удобнее)

В принципе прекрасно представляю, почему от ооп без инноваций можно устать и потянуться к простоте))

Ну ты как адепт ФП мне расскажешь, да

Come to the dark side ?

То что я заюзал jQuery - это не значит что уменя там олдскульные функции и процедурный стиль :D Те же классы, только данными я манипулирую руками, без автобиндингов.

Я уже не смогу на темную сторону, у меня бекенд на руби :D

Не, руби это сатанизм)) Это другая шкала: явное vs неявное

Там зато нельзя сложить число со строкой и пострадать

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

Там зато нельзя сложить число со строкой и пострадать

В моём жс тоже)

Чему я очень рад

Переопределил тустринг на вызов ошибки?

Ахах

Мне нравится ход твоих мыслей ?

Просто заюзал flow, он ругается на это и на всю прочую жс вжух-магию

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

Ну это решение частной проблемы, я подумал, что мне нужен более универсальный подход)

Как минимум тот же принцип распространяется на необязательные аргументы, если flow видит, что у тебя тут может быть null/undefined, то будет ргаться на любые попытки заюзать это как объект, пока не сделаешь проверку

В обещем за всё время юзания руби у меня был только вот 1 баг из-за неявности и только потому что я переставил 2 слова местами в ключе хеша, из-за чего оное выдавало нил и зло аффектило. Так что думается мне что проблема про неявное - надуманное. Также как боязнь некоторых юзать JS из-за непонимания асинхронности

В общем мне нравится мой текущий стек :D

Он правда весь сейчас исключительно развлекательный, программирование больше не приносит мне прибылей

Но не навсегда

Однако я могу сказать что есть некоторая усталось и она больше про типизацию. Я ещё на тайпскрипте пишу... ну как пишу, писал. Ангуляр второй на фронте, просто тайпскрипт на беке. И с одной стороны ты как-то увереннее чувствуешь себя от такого кода, есть некоторая приятная сторона описывать каждый параметр, каждый вот метод, вот это всё

Но... не зашло.

Типичная вторая стадия)) За кем не наблдал — у всех так было

Первая стадия — вау, можно щас затипизировать ВСЁ! Вторая стадия: задолбался описывать каждый параметр, а ошибок меньше не стало, я ливаю Третья - хм, а можно ведь не описывать каждый чих ?

Всё-таки философия того что нужно говорить компютеру что нужно делать, а не как это делать - хорошая философия.

Да

Поэтому между заэнтерпрайзить своего торгового бота на тайпскрипте или переписать понятно и читаемо на руби - победил руби

Неа

ERROR: S client not available

Если ts плох — это не значит, что на жс это невохможно

Это значит, что просто можно отказаться от ts

А я и не говорил что JS это плохо

JS между этим всем

Была вторая проблема конечно, которая увы не решается ибо дизайн языка

У flow другой подход к типам, он многое выводит правильно сам

Нужна была строгая синхронность

Это тоже реально (только зачем)

Понятно что async наше всё, но тем не менее

А вот задача такая - именно синхронно

Можно жонглировать nextTick

100500 запросов и синхронно, каждый следующий меняет стейт и зависит от предыдущего

Вот, жанглировать там и прочее

То есть это реально, но, как-то про молоток и микроскоп получилось

100500 запросов и синхронно, каждый следующий меняет стейт и зависит от предыдущего

Не вижу тут требования к синхронности

Внешний мир не статичен

still

Достаточно наложить ограничение на число одновременно выполняемых потоков/запросов

То есть у меня есть что-то, что должно опросить что-то, принять решение, сделать действие, опросить что-то другое и ещё кучу мест и так вот шаг за шагом

По прежнему не вижу синхронности)

Ну не знаю, она есть :D

Только неявное полагание на особенности архитектуры)

Мне нужно узнать что-то во внешнем мире. Я делаю запрос. Получаю ответ, пишу в стейт, делаю нужные мне действия. Потом ещё запрос, основанный на предыдущих данных. Потом всё тоже самое, только запросы в другие места и ответы тоже разные

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

Нельзя сразу всё опросить

У меня просто вообще нет понятия нескольких потоков

Я просто пытаюсь понять, откуда из вышеописанных требований вдруг был сделан переход к "а теперь делаем всё синхронно"

Алгоритм предплагает множество запросов. Но дело в том что каждый следующий зависит от предыдущего.

Пока я первый не получил - я не могу слать остальные

Так что нет необходимости юзать асинхронность когда всё синхронно

Это не синхронно, лол

Это последовательно