например, что значит PartialObserver с таким странным определением: export type PartialObserver<T> = NextObserver<T> | ErrorObserver<T> | CompletionObserver<T>; где все эти 3 типа одинаковые ?

Означает что PartialObserver может быть равна одному из этих трех типов

например, что значит PartialObserver с таким странным определением: export type PartialObserver<T> = NextObserver<T> | ErrorObserver<T> | CompletionObserver<T>; где все эти 3 типа одинаковые ?

декларация типа данных

они одинаковые, все 3, я именно про это спрашиваю

они одинаковые, все 3, я именно про это спрашиваю

В смысле одинаковые?

ну в прямом

они одинаковые, все 3, я именно про это спрашиваю

нет, это как перечисление. у них разные идентификаторы

export interface NextObserver<T> { isUnsubscribed?: boolean; next: (value: T) => void; error?: (err: any) => void; complete?: () => void; } export interface ErrorObserver<T> { isUnsubscribed?: boolean; next?: (value: T) => void; error: (err: any) => void; complete?: () => void; } export interface CompletionObserver<T> { isUnsubscribed?: boolean; next?: (value: T) => void; error?: (err: any) => void; complete: () => void; }

это интерфейс

интерфейс определяет соглашение о наименовании методов

я знаю)

но не об их реализации

3 одинаковых интерфейса

зачем?

и что?

export interface NextObserver<T> { isUnsubscribed?: boolean; next: (value: T) => void; error?: (err: any) => void; complete?: () => void; } export interface ErrorObserver<T> { isUnsubscribed?: boolean; next?: (value: T) => void; error: (err: any) => void; complete?: () => void; } export interface CompletionObserver<T> { isUnsubscribed?: boolean; next?: (value: T) => void; error?: (err: any) => void; complete: () => void; }

Бывает так пишут интерфейсы "на вырост". Пока они имеют одинаковую структуру, но возможно предполагается что это не всегда будет так

за тем, чтобы сделать typeof

а наследовать интерфейсы нельзя?

за тем, чтобы сделать typeof

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

Бывает так пишут интерфейсы "на вырост". Пока они имеют одинаковую структуру, но возможно предполагается что это не всегда будет так

как вариант, да

за тем, чтобы сделать typeof

херню спорол, извиняйте

а наследовать интерфейсы нельзя?

можно конечно. Но видимо пока не известно что будет какая-то иерархия. Как я и говорю, сделали "на будущее".

можно конечно. Но видимо пока не известно что будет какая-то иерархия. Как я и говорю, сделали "на будущее".

поддерживаю

нуок Хотя выглядит монструозно

if (nextOrObserver[$$rxSubscriber]) { return nextOrObserver[$$rxSubscriber](); } Тут вообще все просто. Проверяется, если у объекта есть поле с именем равным содержащемуся в переменной $$rxSubscriber, то выдывается это поле как метод

3 одинаковых интерфейса

они не одинаковые

это как картинка с "найди 10 отличий"

if (nextOrObserver[$$rxSubscriber]) { return nextOrObserver[$$rxSubscriber](); } Тут вообще все просто. Проверяется, если у объекта есть поле с именем равным содержащемуся в переменной $$rxSubscriber, то выдывается это поле как метод

что делается я понимаю, но зачем – нет

они не одинаковые

Да, точно! )))

эмм, а в чем отиличие? кроме имени

что делается я понимаю, но зачем – нет

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

так я сверху вниз иду

так я сверху вниз иду

нужно сходить туда и обратно

эмм, а в чем отиличие? кроме имени

в каждом обязателен только тот обработчик, который в названии интерфейса

остальные опциональные

и посмотреть как данные бегают )

остальные опциональные

точно, спасибо

теперь все понятно)

subscribe({next: e => console.log(e)}) .subscribe({error: err => console.log(err)}) .subscribe({next: e => console.log(e), error: err => console.log(err)}) .subscribe({complete: () => console.log("done")})

то есть общая идея в том, что обязательно должен быть хотя бы один из трёх

для этого ^

ага

на самом деле такое тоже сработало бы export interface NextObserver<T> { isUnsubscribed?: boolean; next: (value: T) => void; error?: (err: any) => void; complete?: () => void; } export interface ErrorObserver<T> { isUnsubscribed?: boolean; error: (err: any) => void; complete?: () => void; } export interface CompletionObserver<T> { isUnsubscribed?: boolean; complete: () => void; }

и возможно было бы даже понятнее

но видимо авторы больше любят симметрию, чем понятность)

Или копи-пейст )

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

+ вот этот момент не очень понятен в Observable.ts: if (sink.syncErrorThrowable) { sink.syncErrorThrowable = false; if (sink.syncErrorThrown) { throw sink.syncErrorValue; } }

последнее понял

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

Символ наверно для полноты по спеке Observable

https://github.com/tc39/proposal-observable

да, нашел, спасибо

https://github.com/davidkpiano/RxCSS

https://youtu.be/lTCukb6Zn3g

https://github.com/davidkpiano/RxCSS

ох...

https://github.com/davidkpiano/RxCSS

А в чем тут новшество? Манипулировать css при помощи js всегда же было можно.

css переменные это сильно упрощают

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

да не, это прикольный эксперимент, я ваще не знал что их из js можно менять, например)

плюс они (RxCSS), я так понял, добавляют неймспейсы, что тоже может быть довольно удобно

сейчас попробую объяснить (: у меня есть: Rx.Observable.timer(timeout, interval).mergeMap(async () => { ... await upload(entries); ... }); ^ как тут сделать await?

как заставить код в upload выполняться последовательно?

async function upload(entries: UploadEntry[]) { for (let { media, source } of entries) { try { const entry = await restoreEntry<DirectoryEntry>(source.name); ... } catch (e) { ... } } }

async function upload(entries: UploadEntry[]) { for (let { media, source } of entries) { try { const entry = await restoreEntry<DirectoryEntry>(source.name); ... } catch (e) { ... } } }

pipeP в ramda не подойдет?

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

concatMap?

сейчас попробую объяснить (: у меня есть: Rx.Observable.timer(timeout, interval).mergeMap(async () => { ... await upload(entries); ... }); ^ как тут сделать await?

как заставить код в upload выполняться последовательно?

async function upload(entries: UploadEntry[]) { for (let { media, source } of entries) { try { const entry = await restoreEntry<DirectoryEntry>(source.name); ... } catch (e) { ... } } }

Реактивы, поясните на пальцах, почему у Штальца так бомбит от cancellation token?

https://gist.github.com/danharper/ad6ca574184589dea28d да тот-же вопрос мучает. Что с ним не так?

а можно ссылочку где он высказывался про cancellation token?

а можно ссылочку где он высказывался про cancellation token?

вот последнее по этому поводу: https://twitter.com/andrestaltz/status/788343867531730945

"There is no need for Cancel Tokens. They are an alternative, non-popular, weird way of replacing unsubscribe()." я пока не понял в чем суть противоречия (: но я нуб в этих делах

https://twitter.com/andrestaltz/status/779036880386060288

вот тут еще инфа https://github.com/tc39/proposal-observable/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20cancellable

Ну это типа проактивно, если я правильно понимаю

Яннп.

Штольцу много от чего рвет, он вообще по жизни порванный.

Просто ему не нравится, когда "обещания не выполняются")

это все последствия морально-нравственного разложения запада

Народ я тут подумал - что если смешать csp со стримами вроде rxjs получится некая новая концепция императивных стримов: while (true){ var countClicks = 0; var click = yield take(buttonClick); countClicks++; yield take(secondButtonClick); someApi.send(countClicks) } В этом примере мы подсчитываем количество кликов по одной кнопке и отправляем на сервер только при клике по другой кнопке. Правда с текущими генераторами такое сложно провернуть потому что их нельзя склонировать

Народ я тут подумал - что если смешать csp со стримами вроде rxjs получится некая новая концепция императивных стримов: while (true){ var countClicks = 0; var click = yield take(buttonClick); countClicks++; yield take(secondButtonClick); someApi.send(countClicks) } В этом примере мы подсчитываем количество кликов по одной кнопке и отправляем на сервер только при клике по другой кнопке. Правда с текущими генераторами такое сложно провернуть потому что их нельзя склонировать

Очень напоминает подход из koa. Генераторы они прошли в первой версии, сейчас же вместо них async await функции