Idiomatic way to use Option and flow

[andreavaccari]

Say I have defined a Optional type without an explicit name for the contained type:

type MyOption = O.Option<{ foo: string; bar: number }>

And say I want to define a flow that takes MyOption and does something with it:

const myFunc = flow(
  O.map((s: MyOptionType) => s.bar + 1),  // --> I don't have MyOptionType
  O.map((n) => n * 2),
  O.getOrElse(() => 0),
)

I can solve this easily by defining a utility type GetOptionType:

type GetOptionType<O> = O extends O.Some<infer T> ? T : never

const myFunc = flow(
  O.map((s: GetOptionType<MyOption>) => s.bar + 1), // --> Problem solved
  O.map((n) => n * 2),
  O.getOrElse(() => 0),
)

Is this the idiomatic way to do things? Thank you in advance for your help!

EDIT: Corrected a mistake in my example code.

[DenisFrezzato]

I'm a bit confused by your example, since myFunc doesn't consume MyOption, rather some Option<number>.

Anyway, TypeScript's infer is failing in this case, so you have to help it by annotating the signature of myFunc:

const myFunc: (o: O.Option<number>) => number = flow(
  O.map((n) => n + 1),  
  O.map((n) => n * 2),
  O.getOrElse(() => 0),
)

I hope this answers your question.

[samhh]

Worth noting that if the first map function is named and typed already then it will infer correctly e.g.:

declare const f: (x: number) => number

flow(O.map(f), etc) // infers correctly

[andreavaccari]

Hi, thank you for your answers. I commented separately on a mistake I made in my code example. Wrt samhh's comment, is it correct to say that the minimal amount of annotation required for type inference to work is to only annotate the inputs of the first function in the flow?

[samhh]

That's my understanding having used it for a while, yes. Everything infers from the first input.

Edit: Unless you're providing it as a callback, then it infers from the argument.

[samhh]

Something I'd like to add, somewhat orthogonal to the question asked, is that in my view it's generally bad practice to define functions that take monads as their "data" input. You can't do anything with a None, so why accept it as input?

Your function is currently Option<number> -> Option<number>. What if I have a number and want to run this operation? I can't, I have to lift it first. (Admittedly this is less egregious given it's also returning a monad - this criticism is more important when the function is (underneath) something simpler like number -> number.)

On the other hand, if you change the signature to number -> Option<number>, I can use it regardless of whether I currently have a number or an Option<number>; in the latter case, where you might have been using it directly in a pipeline, you now simply wrap it in O.chain.

[andreavaccari]

Thank you for this comment, it's the type of guidance I need. I commented separately with more context on what I'm trying to accomplish. Based on what you said, I can think of two "approaches" to write my redux state and my selectors. Would you comment on what you think is best?

Option 1

type MySliceState = { foo: string;  bar: number }

const slice = createSlice({
  initialState: O.none as O.Option(MySliceState),
  ...
})

const selectMySliceState = (state: MyAppState) => state.mySlice

const someCombiner = (slice: MySlice) => slice.bar > 0

const selectIsBarPositive = createSelector<MyAppState, O.Option<MySliceState>, boolean>(
    selectMySliceState,
    flow(
      O.chain(someCombiner),
      O.getOrElse(() => false as boolean),
    ),
  ),
)

Option 2

type MySliceState = O.Option<{ foo: string; bar: number }>

const slice = createSlice({
  initialState: O.none as MySliceState,
  ...
})

const selectMySliceState = (state: MyAppState) => state.mySlice

const selectIsBarPositive = createSelector<MyAppState, O.Option<MySliceState>, boolean>(
    selectMySliceState,
    flow(
      O.map(slice => slice.bar > 0),
      O.getOrElse(() => false as boolean),
    ),
  ),
)

Thank you!

[samhh]

I'd consider it idiomatic to define the type outside of any monadic context as in example one.

Defining a named function in the selector isn't necessary here for type inferrence and really just comes down to the subjective notion of readability more broadly.

Your top example is incorrect; you're chaining someCombiner but it doesn't return an Option.

You can optionally use constant in your getOrElse to denote that the fallback is unconditionally "constant". That also makes it a tad easier to help the type system, where you could do constant<boolean>(false) instead of () => false as boolean.

[andreavaccari]

Thank you, Sam. I'll play more with Option 1. I also learned about constFalse after your suggestion of using constant.

[andreavaccari]

I'm sorry for the confusion, there's a mistake in my example. I tweaked MyOption to make it more representative of a real-world situation right before submitting my question but forgot to update myFunc. I fixed the type problem in my question, and annotated that the question was edited.

As I'm inexperienced with FP and fp-ts, it is possible my approach is incorrect. What I'm attempting to do is to use redux-toolkit, reselect, and fp-ts together. I have a slice to manage the sign-in/up form, its state is an Option of the form fields, and it's set to O.none when the user is authenticated.

Here is how I'm trying to set up a selector:

const selectWelcome = (state: MyAppState) => state.welcome

export const selectIsSignInEmailValid = createSelector<
  MyAppState,
  O.Option<WelcomeState>,
  boolean
>(
  selectWelcome,
  flow(
    O.map((w) => w.email),
    O.map(E.isRight),
    O.getOrElse(() => false as boolean),
  ),
)

• Could you comment on this approach? What would you do differently?
• Here the inputs to flow(...) are inferred correctly. How would you define it outside the createSelector call?