fp-ts: Validation is deprecated, but it is not explained why

Well, let’s be a bit more flexible here 🙂 We also don’t have any goals for leaving consumers of this project on their own.

Documentation is hard and pretty often it is incomplete. This project is not an exception. We would like to invest more in documenting more at least the public API. Still, there’s not much resource to do that as the project is OSS. In other words, we’re always open for documentation PRs.

As for now, @adam-arold, feel free to check the Help section of the readme. The discord/slack channels there would be a better place to ask about things like EitherT (monad transformers) and others.

@adam-arold

So it is deprecated because there is a better solution in io-ts?

It was deprecated because it’s a special case of Either. The difference between Validation and Either is that during chain-ing or ap-ping (in other words, combining several things) Validation concats all errors in an instance of Semigroup (the simplest is Array) when Either “fails-fast” discarding the rest of the computation. So the actual difference between them is the difference in the underlying Semigroup for errors.

I was not using fp-ts before v2 so this is just an educated guess based on git history.

• pre v2, fp-ts use class-based data type. There was an Validation data type separated from Either
• from v2, fp-ts changed to pure data type, push the use of pipe function. The Validation data type is no more, instead there was ValidationT (https://github.com/gcanti/fp-ts/blob/2.0.0/src/ValidationT.ts). ValidationT<M, E, A> is just M<Either<E, A>> with an Applicative instance knows how to combine E values.
• In version 2.10 its functioning could be replicated with either.getApplicativeValidation and thus deprecated

Case in point: I still don’t know why Validation is deprecated (what this issue is about) and what does it have to do with me knowing (or now knowing) FP. All I needed was something like “we deprecated it because of X, please use Y instead, here are the docs”

You are right. And I’m waiting for an answer just like you. 😃

What @steida says is not errogant. You surely agree that React doesn’t need to explain HTML concepts. Also Tailwind doesn’t need to explain CSS concepts and lodash assumes their consumers know JavaScript.

fp-ts didn’t invent TypeScript or functional programming. Those two are the only two prerequisites to use the library.

It’s not errogant, it’s efficient. FP is a broad subject, and there are many ways to teach it. There are links to some resources on the web.

That being said, I still think documentation can improve in many aspects.

And yes, I think there should be an explanation for why it’s deprecated with a link to an alternative.