Overall experience with the library about io-ts HOT 12 CLOSED

Sorry for quite a long read. This is quite rough summary of my thoughts. Feel free to suggest/disagree/correct.

from io-ts.

@gyzerok first of all thanks for the great write up

Validation vs Decoding

decode is nice. Honestly I have no strong opinion on this, I'm fine with both validate and decode.

Either vs Promise

On the contrary here I have a clear preference: I need a synchronous API. There are other use cases for IO validation I'm interested in other than endpoints, for example validating forms or (sync) APIs of "untrusted" libraries, or even for something like prop types.

Make reporting nicer and part of core

This is the reason why reporters are not part of the core :)

I learned from the past (issues on tcomb and flow-io) that how users want errors being displayed is somehow a matter of taste, no matter how good you define the default reporter. For example some.nested.[0].field is expected to be string, but is given number: 123 is nice, but this would be even nicer for some users (a kind of super reporter!) gcanti/flow-io#14 (comment).

Validator could be chainable

Either is already chainable (is a fantasy-land compliant monad instance)

const DateFromString = new t.Type<Date>(
  'Date',
  (v, c) => t.string.validate(v, c).chain(s => {
    const d = new Date(v)
    return isNaN(d.getTime()) ? t.failure<Date>(v, c) : t.success(d)
  })
)

Overall for now I consider io-ts a low level library you can build upon and/or customize in userland, but I'm open to discussions.

from io-ts.

FYI just published a trial version on the next channel (is not an official release, just a way to try the new version and iron out possible bugs)

npm install io-ts@next

from io-ts.

@gcanti thanks! And sorry for silence, just have not had enough time to respond yet.

from io-ts.

FYI just released the new version ([email protected])

EDIT: change log https://github.com/gcanti/io-ts/releases/tag/0.1.1

from io-ts.

I guess your point is pretty clear, so let's close issue for now and come back if there are more things to discuss in the future

from io-ts.

Hi @gyzerok, in order to apply some of my last libraries to real world problems, I'm working on a porting of Elm to TypeScript featuring

• fp-ts as functional library
• monocle-ts for functional optics
• io-ts for decoders
• rxjs 5 as reactive engine
• React as (pluggable) vdom library

As an Elm user I'd love to hear your feedback

from io-ts.

@gcanti thanks for mentioning me! I will definitely take a look when have some time. You also might want to consider redux-loop library and my work towards new API for it. Maybe we can achieve some kind of synergy between efforts :)

P.S.: I guess that io-ts would be a bit nicer to have Decoder instead of Validator.

from io-ts.

@gyzerok

Make reporting nicer and part of core

I feel you on this one. I started a repository to share the reporter(s) I've been using: https://github.com/OliverJAsh/io-ts-reporters

I'm currently aiming to have some parity with the error messages returned by Elm decoders: gillchristian/io-ts-reporters#3

I would love your help on this.

from io-ts.

@OliverJAsh yeah, I implemented something like this.

Maybe it would make sense to run some poll around that in Twitter @gcanti? I hardly can imagine why would people need reporting not in that way.

from io-ts.

Make reporting nicer and part of core

Does "core" mean the index.ts module? What do you propose? Or are you talking about adding @OliverJAsh 's reporter (or/and other variations) to the default ones? If that's the case, I'm fine with that.

from io-ts.

I don't mind where the reporters live—here or elsewhere—but it would be good to combine efforts.

from io-ts.