AP
И в update разроутить, само собой
Size: a a a
2018 August 14
AP
А порт дожен быть один, конечно же
A
ну то есть получается мы делаем роутинг в сабе?
A
И более того, сабы должны быть готовы принимать и игнорировать сообщения в которых они не заинтересованы?
AP
Не, роутинг остаётся в update
AP
Sub, это источник сообщений. Чтобы можно было несколько источников соединить, но так, чтобы можно было понять откуда сообщение пришло, подписки тегаются
AP
(если все подписки выдают сообщения одного типа, то такие подписки можно смержить с помощью batch)
AP
Разбор сообщений всё равно остаётся в update, там мы понимаем, откуда пришло сообщение и в какой sub-update его передать
AP
Когда же у нас имеются "два таба и один локал стор", может потребоваться тегирование самих запросов к LS
AP
Чтобы опять же понять, кому отдавать ответы.
A
да, вот именно об этом я и говорю
AP
Можно в запрос к порту класть "обратный адрес" - некое значение, которое JS должен будет приложить к результату
A
я просто представляю как я бы хотел это видеть - условное
get :: Key -> IO[Value], но с портами мне нужно навернуть роутинг поверх этого, ведь ответы все приходят из одной верхнеуровневой трубы.AP
Более того, порядок ответов не гарантируется
AP
get : Sender -> Key -> Sub (Sender, Value)A
get : Sender -> Key -> Sub (Sender, Value)все мы бы хорошо, но тогда я прибиваю гвоздями конкретный
Msg, да?AP
get : sender -> Key -> Sub (sender, Value)AP
Тут sender - произвольный тип
AP
А в сообщение можно дозавернуть через
Sub.map