Here's an example of a Result type in Flow.



*Updated* 27 Oct 2017 per [Harish's](https://twitter.com/TrakBit) suggestion for using exact object types.

## Result Type

In functional programming, a Result type can be useful for representing things that might fail.  It becomes a common interface that you can return from these potentially-failed processes.  

A Result type wraps up two things:

1. The value returned in the case of a potential success
2. The error returned in the case of a potential failure

When you use a Result type as a return value on a function, for example, you have a common interface in dealing with the return value whether it succeeded or failed.

Result types are generally nice when writing flow control code (like if, switches, or other pattern matching).  

Result types are nice when built into the language, because then even the standard lib will often use them when describing APIs that can fail.  

Functional languages that enforce total functions make consuming Result types nice as well because it forces you to handle the success _and_ failure branches of a Result type.

## Result in Flowtype

We don't have all the benefits that can come from using Result types in JavaScript.  But we can get some of them.

Let's look at how to represent a Result type in Flowtype.

First, there is a success and a failure potential.  There are a few naming conventions to represent these potentials.  I like `Ok` and `Err`, so let's use those.  We'll make each an object, and we'll put a boolean flag inside that has a literal type that we can use for conditional handling logic, called `ok`:

```js
type Ok = { ok: true }
type Err = { ok: false }
```

Now we need to wrap them up in one type, so we'll create a new union type, `Result`:

```js
type Result = Ok | Err
```

Now if we ran a function that returns a result, we can branch and do different things depending on success or failure:

```js
const someFn = (): Result => { /* ... */ }

const result = someFn()
if (result.ok) /* success... */
else /* failure... */
```

This might be enough in some cases, but not in the general case.  In the general case, we also want to have access to the return value in the success case.  For instance, if I asked an API for something, and now I have it, here's what the value is.  And on the other hand, in the case of the API call failing, we want to know why and have debugging or remediation data.  

So let's add a `value` on the `Ok` side and an `error` member on the `Err` side:

```js
type Ok<T> = {| ok: true, value: T |}
type Err = {| ok: false, error: Error |}
type Result<T> = Ok<T> | Err
```

A couple changes:  Now that we have all object fields in place, I've changed `Ok` and `Err` to exact object types (via `{| |}`), disallowing additional fields from type checking. I've made the value of generic type `T` and have genericized the `Result` and ~`Ok` types to pass that generic type through.  We'll need to adjust our usage of the `Result` type too (We'll pretend that our success value is of type `string` in this case):

```js
const someFn = (): Result<string> => { /* ... */ }

const result = someFn()
if (result.ok) doSuccessWithString(result.value)
else throw result.error
```

Here you can see that we have acceses to the `result.value` in the success branch and the `result.error` in the failure branch. And, of course, it's all type checked!  So you'll only be access `value` or `error` where it's available.

That's our Result type modeled in Flow.  For runnable code, check out this [flowtype-result-demo repo](https://github.com/jaketrent/flowtype-result-demo).

How would you model a Result type in Flow differently?  What great uses for Result types have you found in your JavaScript code?

Result Type in Flow

Here's how to type props for a child component that has props cloned onto it.



This is for you, @nguyenmanh1507! :)

## React Clone Props onto Children

In React, you can [send props to children](/post/send-props-to-children-react/).  This is a way for a parent component to provide a child component with data it didn't already have.  

Many times this is because a parent and a child component work in tandem to create some larger UI.

## A Radio Button Example

An example of this is a radio button group that has many radio buttons.  They are tied together by a `name` field, which allows the browser to know which radios belong to the group in order to cycle through them.

That code might look something like this:

```js
import React from 'react'

const RadioOption = props =>
  <label>
    <input type="radio" value={props.value} name={props.name} />
    {props.label}
  </label>

const RadioGroup = props =>
  <div class="radio-group">
    {React.Children.map(props.children, child =>
      child.type === RadioOption 
        ? React.cloneElement(child, {
            name: props.name
          })
        : child
    )}
  </div>

const WhereImUsingRadioGroups = _ => 
  <RadioGroup name="blizzard-games">
    <RadioOption label="Warcraft 2" value="wc2" />
    <RadioOption label="Warcraft 3" value="wc3" />
    <RadioOption label="Starcraft 1" value="sc1" />
    <RadioOption label="Starcraft 2" value="sc2" />
  </RadioGroup>
```

## Flow Can't Infer the Cloned Prop

We can start type-checking this code with [Flowtype](https://flow.org) by adding a comment to the top of the file:

```js
// @flow
```

Flow immediately points out a problem to us:

```txt
9: <input type="radio" value={props.value} name={props.name} />
                                                       ^ property `name`. Property not found in
9: <input type="radio" value={props.value} name={props.name} />
                                                 ^ props of React element `RadioOption`
```

Flow can apparently infer that `label` and `value` are strings and passed in when `<RadioOption />` is used.  But it is confused about `name`, which is cloned onto the `<RadioOption />` children inside `RadioGroup`.

## Adding Types to RadioOption

We can provide some help to Flow by adding types to the `props` passed to `RadioOption`.

We can define them as:

```js
type Props = {
  label: string,
  name?: string,
  value: string
}
```

And adjust the `RadioOption` signature to read:

```js
const RadioOption = (props: Props) =>
  // ...
```

Now we have [no Flow errors](https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVBLAtgBzgJwBcwAlAUwEMBjYqfOLMAcn0pqfUIE8cywAFejgDOYALxgA3qjBgYFAEZkYALjDDC+DADsA5gBoZYbRSxkA-Go1a9h2QDcKMAK5krmnbtQBfdFGfaNBhw2qQUACbBAPI4hMHaABQ4QsJqgnAiAJRSRqyEzvihCUayADzySjAAfCWyYKU6OM7E3LxiAET4EcHtYI4uZGKSyRnCAHT9rt7GpoPDKWMmZtPANXV186NjFcq+66XAO9VGmT5+AUEhYZFwAOL0zjhJKdnSsnkFRbWlkfZgVPJhMIOl0bgBaXQPHDtNbrKTkaiEMYAYQAFhgYOFWNoxlgKE8RiIxlR0Zjsfp-qTwuJYXDKRjwmNWnwxKzrtFYvEwLU6eZSGwkQCQmQAKIwMhmbSEBIkhkUt50xVLNxgQnjZU8xXeU6KupqWWYzWZPZ1A6-WGnXyofyBOJXADqqLIrAAklgAKrCTwkbp3KHCBKvXJkfKFMDFfY+m73OCPGZmDoKGAYABeKYo+HCENmwhhmtKUY5dtCRw69ozVC6UGIACZepNBu0EFQ62BVvnC3AYsW5IplGWK1XiABmetOVwdZujtu002d7tc0vtADKhEHFGrYAAjGOBh1hFQdzOO76F1cl6v15vWw39y3eu39sBOzHHhazkA)!

The `name` prop type is specified as `name?` to indicate it's an _optional_ object property. This is required, or we reverse our problem, confusing Flow as to why the `name` is not included when `<RadioOption label="Starcraft 2" value="sc2" />` is called initially.

Are there other ways that you would handle typing cloned props in this case?

How to type props for a child component that has props cloned onto it.

Flowtype Props Passed to Children in React

[Flowtype](https://flow.org/en/docs/types/maybe/) gives type errors to help you consider all function code paths.



## Other Potential Paths 

Often we are only paying attention to the happy path that we're developing in our code.  This may lead to bugs later on that we hadn't anticipated from the other code paths that exists in different branches of logic.

Flow helps us consider all the code paths and handle each of them in the manner that we've indicated is correct in our defined types.

## Code With Two Paths

For instance, we might write a function that has some error handling.  We declare that the return type of this function is `number`:

```js
// @flow
const someFunction = (): number => {
  try {
    // ...something that might throw
    return 123
  } catch (err) {
    console.log('handle error...')
  }
}
```

Do you see the 2nd code path?

## One Path Not Handled

So often we consider what's in the `try` block and forget to deal with the `catch` block.  That is the case in this example.

When we type check this file by running `flow`, we get the error:

```bash
Error: src/somecode.js:44
 44: const someFunction = (): number => {
                              ^^^^^^ number. This type is incompatible with an implicitly-returned undefined.
```

It says "this type", pointing at `number`, is incompatible with the implicit return that happens in the `catch` block path of our function.  It helps us remember to cover all code paths.

## Solution: Change the Code

To make our function do what we said we really wanted -- always return a `number` -- we could make the `catch` path return some error-state value, such as `-1`:

```js
// @flow
const someFunction = (): number => {
  try {
    return 123
  } catch (err) {
    console.log('handle error...')
    return -1
  }
}
```

This would be valid for our existing type, and Flow would be happy.

## Solution: Change the Type

Another solution would be to use the _actual_ type that we coded for in our original code.  The original code returns `123` in the `try` block but nothing if the `catch` block is entered.  

We could express this with a [Maybe](https://flow.org/en/docs/types/maybe/) type, where the `number` could be a number or `null` or `undefined`.  To do this, we put a `?` before the `number` return type.

We would change our type signature to:

```js
const someFunction = (): ?number => {
  try {
    return 123
  } catch (err) {
    console.log('handle error...')
  }
}
```

This would also make Flow happy by changing the type because that's actually what the code does.

What other kinds of code path issues has Flow analyzed that have helped you?

Flowtype gives type errors to help you consider all function code paths.

Flowtype Analyzes All Code Paths

Add typing to your `process.env` access in Node.js.



## process.env Access

`process.env` is a globally-available object on which environment variables are accessible to your Node.js program. 

When you ask for an environment variable, such as `process.env.MY_VAR`, it may or may not be set.  If it's set, it'll be returned as a string.  If it's not set, it'll be returned as `undefined`.

## process.env Original Type

Because of the above behavior, the flowtype definition for `process.env` is a map of nullable strings:

```js
{ [string]: ?string }
```

## process.env Nullable Access

If you're trying to access and use the values of an environment variable, you have to do null-checking before you can be sure when using it.

This code is unsafe:

```js
process.env.MY_CSV.split(',')
```

And provides the following flowtype error:

```txt
call of method `split`. Method cannot be called on possibly null value
```

To make it safe, we have to null-check first:

```js
if (process.env.MY_CSV)
  process.env.MY_CSV.split(',')
```

## Null Checking En-masse

Usually you'll have multiple env vars in your code that you want to use.  Many of these are required for your program to run. And usually you don't want to be checking for nulls on required values in the middle of other logic.  You want a non-nullable type that you can rely on.

There are many ways to accomplish this.  Here is one:

Create a `config.js` abstraction around your `process.env` access.  In the initialization of this abstraction, read from `process.env`, do all the null checking at once, and from then on only use the config abstraction in the rest of your code.

This `config.js` code might resemble:

```js
type Cache = {
  databaseUrl: string,
  // ...
}

let cache: Cache = {
  databaseUrl: '',
  // ...
}

const getVar = name => {
  if (!process.env[name]) throw new Error(`process.env.${name} required`)

  return process.env[name]
}

const load = (seed: ?Cache): Cache => {
  cache = Object.freeze(Object.assign(cache, seed, {
    databaseUrl: getVar('DATABASE_URL'),
    // ...
  }))

  return cache
}

module.exports = load()

```

When you call `load()` in the above code, if there are missing env vars, your program will error out.

The `cache` is initially assigned to an object of empty strings.  This is required to assure flowtype that the value really is always non-null.

There is a lot of type defining that's going on here.  This is all in the name of safety.  It's definitely more of a pain when you write this, but if you could guarantee that you access of env vars is safe, might it not be worth it?

What do you think?  How else have you accomplished this?

Add typing to your process.env access in Node.js.

Flowtype process.env

Here's a way to setup for types on a Node.js backend app.



## Flowtype Requires Transpilation

[Flowtype](https://flow.org/) will provide types for JavaScript, which originally has so little type information that it has essentially none.

You'll need to transpile from flowtyped-javascript into vanilla javascript that Node can run.

My favorite compiler for this is [babel](http://babeljs.io/).

## Lightweight Babel

The great thing about Node these days is that most of the time, you don't need to compile at all.  With flowtype, you will need to compile.  

The most lightweight babel integration we can get is via [`babel-cli`](https://babeljs.io/docs/usage/cli/).

First, install it.  While we're add it, grab the babel preset for flowtype:

```bash
npm install babel-cli babel-preset-flow --save-dev
```

To compile, run the cli in your terminal:

```bash
babel src/ --out-dir dist/ --no-babelrc --presets=flow --ignore spec.js
```

This will take all the Node code in the `src/` directory, compile it, and save it to the `dist/` directory.  Note that the babel preset we're using will remove the flowtype annotations, making our code again runnable in the Node.js runtime.

## Development Build

In your local dev environment, you'll want changes that you make in source code immediately transpiled and run by Node. Let's setup an npm script to help.

We'll first install another couple [useful helper](/post/some-helpful-packages-npm-scripts/)s:

```bash
npm install concurrently nodemon --save-dev
```

`concurrently` helps us run multiple processes at once.  `nodemon` will take care of restarting our Node server when code changes.

And then setup our `package.json` snippet:

```json
"scripts": {
  "build": "babel src/ --out-dir dist/ --no-babelrc --presets=flow --ignore spec.js ",
  "dev": "concurrently \"npm run build -- --watch\" \"nodemon dist/server.js\"",
}
```

Now if we run `npm run dev`, we'll get our compiled code running in Node.  Note that we're passing the extra `--watch` flag to the `build` script to enable this.  Also note that this assumes your app's entry point is `server.js`.

## Production Build

The production build setup is going to be even easier. 

Let's assume that we're deploying to the heroku.  We want to add a script that will run after we push new code to our server.  Heroku's version of this is called `heroku-postbuild`.  Again, in `package.json`:

```json
"scripts": {
  "heroku-postbuild": "npm run build",
  "start": "node server/dist"
},
```

We run the build after the server deploy, and we start our app by pointing to our compiled code.

Now we're set to add types via flow to our backend code.  Does this setup work well for you?  What have you done to make it even more slick?

Here's a way to setup for types on a Node.js backend app.

Setup Flowtype for a Node.js Backend

This is a way to integrate [flow](https://flow.org/) with Spacemacs.



## Install Flow

First, [put flow somewhere](https://flow.org/en/docs/install/) in your PATH so that Spacemacs can find and use the binary no matter what project you're editing.  The best option I've found so far is [flow-bin](https://www.npmjs.com/package/flow-bin), installed globally:

```bash
npm install -g flow-bin
```

## Spacemacs File Watcher

Preinstalled in Spacemacs, you'll find [flycheck](http://www.flycheck.org/en/latest/), which forms the foundation of the [syntax-checking](https://github.com/syl20bnr/spacemacs/tree/master/layers/%2Bcheckers/syntax-checking) Spacemacs layer.  
 
The syntax-checking layer is not installed by default, but you can easily add it to your `.spacemacs` config:

```lisp
(defun dotspacemacs/layers ()
  (setq-default
   dotspacemacs-configuration-layers
   '(
     syntax-checking
     )
  ))
```

syntax-checking allows files that you're editing to be parsed for correctness as you edit, providing realtime feedback of any errors that you've written.

## Flowtype Watcher

Now we need something that can plug into flycheck and do the flowtype checks for us.  That package is [flycheck-flow](https://github.com/lbolla/emacs-flycheck-flow).

Type `SPC :` and run the command `package-install`.  The find and select `flycheck-flow`.

## Flowtype Feedback

Once you're installed, you can get feedback from Flow within Spacemacs.

Some of this will happen inline.  You'll get red dots in the gutter with red underlines in your code.  If you move your cursor to that point, you will get tooltips describing the problem.

There are also a [set of commands](https://github.com/syl20bnr/spacemacs/tree/master/layers/%2Bcheckers/syntax-checking#key-bindings) for opening a list of flycheck errors.

This is the best flowtype integration with Spacemacs that I know of.  What other ways have you found to make this integration better?