Pipe-API and thoughts about signals

[GregOnNet]

Warning

Disclaimer this issue exists to dump an idea, I know @seangwright already have experminented with. This issue is not planned to be implemented by us. However, I want to share this ideas. If there is a hero who want to take responsibility: You are kindly invited to work with us!

Type-System Rework

Currently, we have Result. A Result can be a success or a failure.
If a result is a success, it has a value, but no error.
If a result is a failure, it has an error, but no value.
For now, we cannot reflect this in our API.
It would be great to have a save access to the properties that exist.

if (result.isSucess) {
  console.log(result.value)
  console.log(result.error) // 💥 error does not exist on a succesful result
} else {
  handleError(result.error)
  console.log(result.value) // 💥 value does not exist on a failure-result
}

Pipe-API

I am a big fan of the API-Design of https://valibot.dev/guides/introduction/.
It has the most type-safe API I am aware of.
It composes functions with each other, making the library tree-shakable.
Adopting this approach would allow splitting Result & ResultAsync.

import * as r from 'typescript-functional-extensions'

r.from(...).pipe(
  r.mapError(...),
  r.bind(...),
  r.compensate(...)
)

The world of Signal-APIs

I am wondering, how typescript-functional-extensions fit in frontend frameworks. The last years each framework has its own mechanism (Observables, References, effects, “compiler-magic”).
With signals, a lot of Frameworks kinds of agree on a standard.
We could think about how typescript-functional-extensions can be easily used with signal-APIs and provide either utility-functions or at least a guide how code quality and safety can be improved with typescript-functional-extensions.

[DerStimmler]

I recently explored Effect for error handling and noticed that it also uses pipelines to chain operations by applying different functions within a pipe function.

Their documentation highlights tree shakability and extensibility as key advantages of using functions over methods.

I really like the idea of a Pipe-API, but it's important to remember that this library aims to bring CSharpFunctionalExtensions to the TypeScript ecosystem (as far as I understand). Adopting this change would shift the programming style away from method chaining, which is a core aspect of CSharpFunctionalExtensions. However, I think both approaches are similar enough and easy to understand, making the benefits of a pipeline-based style a reasonable trade-off.

[seangwright]

Is there a benefit to make this project yet-another-functional monad library if we take the pipeline approach?

Like you mentioned, the value of this library is the similarity with CSharpFunctionalExtensions and its focus on Maybe/Result. It's simple and familiar.

[DerStimmler]

I guess, objectively, there are some benefits to the pipeline approach like the ones @GregOnNet and me mentioned.

However, I also fully appreciate that the goal of this library is to mirror CSharpFunctionalExtensions, and as such, it makes sense to keep the current method-chaining API. I can also completely support this direction, as it aligns with the library’s intended purpose.

[GregOnNet]

Hey together,

wow, @DerStimmler, nice to see you here! :-) (@seangwright Tim and me are former colleagues).

To the comments

Is there a benefit to make this project yet-another-functional monad library if we take the pipeline approach?

Sean, can you elaborate a bit more on this sentence? I am not aware of another Monad-Library that provides Result and its operators to bring functional programming as near as possible to the OOP-world. Maybe I am sitting in my bubble here.

Like you mentioned, the value of this library is the similarity with CSharpFunctionalExtensions and its focus on Maybe/Result. It's simple and familiar.

I get the point. In my view, using the pipeline-API does not change this ambition. The operators remain the same, as they correspond to CSharpFunctionalExtensions.
To me, pipe-APIs are frequently used in libraries and should be a known pattern to developers:

• Ramda
• Remeda
• RxJS
• valibot

In my eyes, using pipe seems simple, too. :-)

I guess, objectively, there are some benefits to the pipeline approach like the ones @GregOnNet and me mentioned.

Tree-Shakability, is one reason, correct. Another reason is code-maintainability. At the moment, we need to extend result.ts and result-async.ts. These files get longer and longer. Pipes allow us to split the code in small files.

C# vs. TypeScript

We are having two different platforms:

• TypeScript can type more specifically than C#.
• C# allows writing extension methods, which is not possible in Typescript.
• The async/await in ECMAScript is different to C#'s async/await.

We have platform indicated differences, which is why, we never can align the implementations 100% to each other.
To me, a pipe is the nearest thing to an extension method. :-)

Tree-Shakability

Tree-Shakability plays a bigger role in Front-End-Frameworks, I guess.
When JS, needs to be shipped to the client, and we are splitting JavaScript into lazy-loaded chunks, the pipe-API can improve Web-Vitals.

Note

I am happy to hear, your thoughts on this. 🤗