The Maybe data type in JavaScript

Using Maybe like that has no sense. If you will use nullable (value | null) then withDefault is just x ?? 0 what means if x is null then fallback to 0. There is no value in Maybe here, only additional abstraction instead of idiomatic construct.

Maybe starts to have sense when you totally work with it in functional way. When u use maps, binds and ap.

If you write statements (and if is a statement) then I would say you don't need Maybe, Nullable is idiomatic and fully ok. If you use TS then compiler will inform you when you need to check if value is there, so win win. Additionally you don't loose latest added feature of optional chaining which works with null values.

But if you go fully functional then many things become harder with idiomatic JS, and then such constructs has a sense.

Below using Nullable.

function divide(numerator, denominator) {
    if (denominator === 0) {
        return null
    }
    return numerator / denominator;
}
// using
const x = divide(1,2) ?? 0

If we would type arguments as numbers then TS would automatically say the function returns number | null and dev would be enforce to or check the value or set the fallback

If we want to mix Maybe/Either with asynchronous API fetches, there's a functional data type that's perfect for that, Task (also known as Futures). Tasks are the functional version of Promises, and can be used to wrap Promise-based apis in order to make them functional (which for our purposes in Javascript, means: coherently interoperable with other functional data types).

Here's the simplest implementation of a javascript Task:

const Task = fork => ({fork});

Pretty crazy simple (and let's not talk about why we used the word "fork" just yet)! On the surface, we're literally just setting up a way to call a variable, and then get back an object with that variable stored in a key called "fork". But what we're reaaaaaally doing here is setting up a way to delay the execution of some function (while happening to call that operation "fork"). And here's an example operation where we're fetching a resource at the api endpont, 'some-api.com/'...

Task( ( left, right ) => { fetch('http://some-api.com/').then(right).catch(left) });

Now, we could have called "left" and "right"... "error" and "success" but if we wanted to better understand how Tasks are similar to the Either Type, let's go with this naming convention.

What we get back from the above, isn't a Promise of a result, or even itself an actual call to an api, but rather: a stored proceedure that COULD make a call to that api. And, if that's ever done, this particular construct would not return a result or throw an error directly: it'd instead return the results or an errors to two specific functions: left, and right.

What are those functions? Well, most people would think of them as callbacks. In fact, a lot of imperative programming for asynchronous code used to use some version of this idiom:

makeCall( CALL_FUNCTION, ON_SUCCESS, ON_ERROR ); where all the shouty words are functions, and the last two are "callback" functions (that is, the functions that we'd call once a result or error was returned).

In our "Tasks," Left and Right are basically just ON_ERROR and ON_SUCCESS respectively (in functional programming, the error condition, by convention, is usually specified first, in part to remind us all that the error condition is easily forgotten, but needs to be handled).

Why is this Task pattern superior to the imperative version? Well, some would argue that it's not! But if you're dipping your toes into the world of functional programming, and you've been sold on exploring the Maybe or the Either data type, you might already be sold on why, and so let's assume you're sold, and move forwards:

The Task pattern is pure: it causes no side effects UNTIL it's explictly called, if ever. And that means that, despite tackling messy, potentially error-prone asynchronous operations, Tasks can still live and operate and speak the same language as all the other types that live in a synchronous world: Lists (Arrays), Maybes, Eithers... all the rest. You can .map over a Task in exactly the same way you can .map over an List (Array) or a Maybe or an Either.

The Task pattern is also, unlike its more familiar cousin, Promises, LAZY. In practice, that means that you can reason and plan and speak about Tasks without that very act of reasoning then directly causing the potentially dangerous side-effects that a commitment to purity avoids. And this paragraph is in some ways just restating the previous paragraph: Tasks are pure. It just that, because they deal with operations that are not timeless and unary in their effects, that purity must necessarily also imply laziness.

We're leading up to this: remember that fist Task operation we described? Here it was:

const A_TASK = Task( ( left, right ) => { fetch('http://some-api.com/').then(right).catch(left) });

So, here's how you'd use it:

A_TASK.fork( logError, doSuccess )

Just define whatever logError and doSuccess do to handle api results or errors for yourself: all we care about right now is that they're functions: functions in exactly the same way as are Nothing and Just, Left and Right. They basically only exist in order to continue a functional chain (and indeed, this power of Tasks/Futures is known in computer programming as a "continuation") rolling on along, all potential side-effects carefully bottled and managed. All discrete operations named and broken down in to careful atomic parts that can be then joined up again to build up a complete program that's entirely secured from errors.

But if you feel ridiculous after all of this, all for this seemingly trivial result, don't worry! The proof is in the functional pudding. Here's a glimpse of that pudding:

egghead.io/lessons/javascript-leap...

Isn't Nothing just the concept of undefined? What's stopping me from just comparing to undefined

My Either implementation:

type Either<T> = [Left, Right<T>]

Using it:

/**
   * Finds the first Document that matchs the params
   * @param params.filter Object used to filter Documents
   * @param params.fieldsToShow Object containing the fields to return from the Documents
   * @param params.databaseName Set this to query on another database in the current mongo connection
   * @param params.throwErrors Enable classical try/catch way of handling errors
   * @returns A Promise with a single Document
   */
  findOne(params: IFindOneParams<Interface, false>): Promise<Either<Interface>>;
  findOne(params: IFindOneParams<Interface, true>): Promise<Interface>;
  findOne(params: IFindOneParams<Interface, boolean>): Promise<Either<Interface> | Interface> {
    return new Promise(async (resolve, reject) => {
      try {
        const _model = this.getModel(params.databaseName);
        const result = (await _model.findOne(params.filter, params.fieldsToShow).lean(true)) as any;
        if (params.throwErrors) {
          resolve(result);
        }
        resolve([null, result]);
      } catch (e) {
        const exception = new GenericException({ name: e.name, message: e.message });
        if (params.throwErrors) {
          reject(exception);
        }
        resolve([exception, null]);
      }
    });
  }

In another place using express

/** some code **/
const [insertError, insertSuccess] = await this.promotionService.insert({
      entity: promotion,
      databaseName: validationSuccess._id.toString(),
    });
    res.status(insertError ? insertError.statusCode : CREATED).send(insertError ? insertError.formatError() : insertSuccess);

If you ever use Python, we also have Maybe, Either, and other monads (compatible with mypy and type-hints): github.com/dry-python/returns

pip install returns

# In setup.cfg or mypy.ini:
[mypy]
plugins =
  returns.contrib.mypy.decorator_plugin