Fp-ts: Should be Option persisted?

[steida]

📖 Documentation

One thing is not clear to me. I understand why Option is better than null/undefined. But should we persist (save to db etc.) our model as serialized Option or with elvis operator and restore it to Option later on load? What fp-ts people do?

Maybe related: https://github.com/gcanti/io-ts#mixing-required-and-optional-props

[mlegenhausen]

I normally use the optionFromNullable type for serialization but note it does not come for free. You loose the ability to store constructs like Option<Option<unknown>>. The benefit of going for a null is that your data can be queried natively by most of the database engines out there.

[steida]

This is a good answer, thank you. Just curious, when it can happen Option<Option<unknown>>? It looks like a bug to me, but I am still a beginner.

[mlegenhausen]

I use this construct when I want to build a datastructure like in remote-data-ts but don't want to include an addtional library

type RemoteData<E, A> = Option<Option<Either<E, A>>

const init: Option<Option<never>> = none
const pending: Option<Option<never>> = some(none)
const success<A>(a: A): Option<Option<Either<never, A>>> = some(some(right(a)))
const failure<E>(e: E): Option<Option<Either<E, never>>> = some(some(left(e)))

const remoteData = getEitherM(getOptionM(option))

Coming from an OOP perspective this seems odd but when diving deeper in FP it is just again composition of stuff that is already there.

[steida]

Thank you!