Replies: 2 comments
-
Thanks to the pipeline operator, it is possible to erase the line between "function" and "operator". There will be no need for operators like source$.pipe(zipWith(foo$, bar$));
// turn into
source$ |> zip(%, foo$, bar$); It also allows you to choose the order of the arguments yourself. sample(source$, notifier$);
source$ |> sample(%, notifier$);
notifier$ |> sample(source$, %); I also don't like the naming idea ( |
Beta Was this translation helpful? Give feedback.
0 replies
-
CORE TEAM: Proposal 3 or 4 for now. Do nothing. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Goals
The current pipeline proposal isn’t compatible with “pipelining” existing pipeable functions
The current TC39 proposal for pipelines is at stage 2, and unfortunately it doesn’t support “pipeable functions”. It looks something like this if used with our current operators:
Where
%
(or maybe some other character like^
) conveys where the result of the left hand side is used in the right hand side.If we support this, it might be pretty nice that people can do quick and easy calls like
concatMap(source, fn)
and thatconcat
andmerge
would “just work” as operators as well.Proposal 1: Automatically curry if called with fewer values
source
observable.So in this world, something like
concatMap
would look like this:Issues
fn(a: any, rest: …args: any[])
, but this isn’t ergonomic because we’ll have to train people how to properly make operators for use here. It’s quirky.Impl Notes
We could use a simple function like this to convert what are basically “observable creation” functions — where the source is the first argument — into functions that if they’re called with one fewer argument than is expected returns a function that accepts the first argument:
Proposal 2: Export a “standalone” and “pipeable” version of every operator
In this proposal, there would be one “standalone” implementation of everything, but we’d export a curried version of it alongside.
Basically:
Issues
fromConcatMap
above.Proposal 3: Ignore
|>
until it lands, then pivotHere we just wait until
|>
lands in most environments, then pivot our library to work with pipelining — and only pipelining — in a major version as a breaking change.Proposal 4: We ignore
|>
and stick with what we’re doingIn this scenario, we just accept that the TC39 has failed to deliver a useful feature and we continue doing what we’ve been doing until hopefully something else lands that helps us.
Beta Was this translation helpful? Give feedback.
All reactions