Btw, how would you handle sync/async + composition?
That's a good question. Unfortunately, I don't have a good answer.
Sometimes I just use promises as pseudo-either monads when I have to mix sync and async code and that's good enough.
// Instead of throwing an exception with invalid JSON,// this function will capture it in a promise's rejection branch.constparseJson=data=>Promise.resolve(data).then(JSON.parse)// Another sync function wrapped in a promise.constverifyResponse=({statusCode,body})=>statusCode===200?Promise.resolve(body):Promise.reject({statusCode,body})parseJson(someData)// For some weird reason our data is stringified JSON, very convenient to manipulate..then(postData)// We send our data to a remote host.then(verifyResponse)// We verify that we get 200 back.then(parseJson)// We parse the body of the response// ...
Another option would be to map eithers and maybes to promises when composing sync and async functions.
constLeft=x=>({...toPromise:()=>Promise.reject(x),})constRight=x=>({...toPromise:()=>Promise.resolve(x),})constmap=F=>x=>F.map(x)constchain=F=>x=>F.chain(x)consttoPromise=F=>F.toPromise()constparseJson=data=>tryCatch(JSON.parse,data)constverifyResponse=({statusCode,body})=>statusCode===200?Right(body):Left({statusCode,body})parseJson(someData).toPromise().then(postData)// We send our data to a remote host.then(verifyResponse)// We verify that we get 200 back.then(chain(parseJson))// In case you want to keep the Either inside the promise.then(toPromise)// In case you want to unwrap the Either
Most of the times I think promises as pseudo-eithers is good enough, so I haven't explored how to compose them with proper eithers that much.
I actually used to do what you mention in the first code example, but not in the last example (nice trick to explicitly and descriptively passing from sync to async), at the end of the day when we enter to the async world we cannot exit, even worse, they can be nested, but luckily we have async/await mechanism to flat it.
By the way, I think the operator pipe will fix this.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the comment :)
That's a good question. Unfortunately, I don't have a good answer.
Sometimes I just use promises as pseudo-either monads when I have to mix sync and async code and that's good enough.
Another option would be to map eithers and maybes to promises when composing sync and async functions.
Most of the times I think promises as pseudo-eithers is good enough, so I haven't explored how to compose them with proper eithers that much.
Thanks for reply!
I actually used to do what you mention in the first code example, but not in the last example (nice trick to explicitly and descriptively passing from sync to async), at the end of the day when we enter to the async world we cannot exit, even worse, they can be nested, but luckily we have async/await mechanism to flat it.
By the way, I think the operator pipe will fix this.