
# Quick look at new :gen_server handle_continue callback

19 June 2018. Erlang OTP 21.0 has been released today and I’m going to
describe how new **:gen_server** `handle_continue` callback works.

## Setup

Erlang `21.0` and Elixir `1.6.6-otp-21` installed using [asdf version manager](https://github.com/asdf-vm/asdf)

## Let’s write something basic

<script src="https://gist.github.com/amatalai/eaa5976c6a10cf6de7f4e2c5131bb148.js"></script>

Initial state of our **GenServer** is 0 and it implements single `handle_info` that
increments state by 1 and logs new value.

Inside init callback we are sending three `:inc_and_log` messages to
**GenServer** itself and logging additional message, so when we start it we can
see following logs:

<script src="https://gist.github.com/amatalai/007c66c6dbbc565534b8ce565ea0b8df.js"></script>

Nothing special so far.

## Continue

Let’s modify `handle_info` return value and add new `handle_continue` callback.

<script src="https://gist.github.com/amatalai/2d3d51780c5e9a9aaa61344b836c4cc4.js"></script>

When we start our **GenServer** now, we can see different values in logs:

<script src="https://gist.github.com/amatalai/6e80904aa9493cf694f319f428a6963c.js"></script>

The reason for this is that when any callback returns `{:continue, term}` then
`handle_continue` is invoked immediately. In other words after every
`handle_info` there was `handle_continue` which incremented state value one more time.

## More realistic use case

Let’s imagine `call` that returns current state and calculates new one.

<script src="https://gist.github.com/amatalai/0e730fbf932f2f0c13fdd823def1fd1c.js"></script>

Process invoking call doesn’t need to know new state, but it’s blocked until calculation ends.

It also can’t be solved by moving calculation to `handle_info` callback because
it can’t be guaranteed that there are no other messages waiting for being processed.

It’s a kind of situation where `handle_continue` is very convenient:

<script src="https://gist.github.com/amatalai/e42f646c805c49daf5cbab4a89f2c973.js"></script>

## Last thing

There's no support for `handle_continue` in elixir yet. It means that `@impl true`
before `handle_continue` will result in compilation warning.
(EDIT: this is no longer true for Elixir `v1.7`)


quick_look_at_new_gen_server_handle_continue_callback-66f5f8cca9383c0b0f82f0773ef13eed-1

https://strapi-appunite.s3.eu-central-1.amazonaws.com/covers-with-text/354d24f5-9398-4661-a5a5-011dab55d08a.png

Erlang OTP 21.0 has been released today and I’m going to describe how new :gen_server handle_continue callback works.

Quick look at new :gen_server handle_continue callback

Reasonable defaults can make your life easier. I think that most programmers agree with that. Does that mean we should stick to them forever? Can a particular solution be suitable for everything and everyone?

This article tells the story of my experiment, which proved that sometimes it is worth breaking well-established standards.

# To get some context

Let's start with the standard elixir project.

```
.
├── config
│   └── config.exs
├── lib
│   ├── foo
│   │   ├── bar.ex
│   │   └── baz.ex
│   └── foo.ex
├── mix.exs
└── test
    ├── foo
    │   ├── bar_test.exs
    │   └── baz_test.exs
    ├── foo_test.exs
    └── test_helper.exs
```

It's the output of `mix new foo` with two additional modules: `Foo.Bar` and `Foo.Baz` added manually. You can imagine this is your favorite small open-source library.

In my opinion, it has the following advantages:

- compiles the content of `lib` out of box
- has everything that is needed to run tests
- looks familiar to many developers
- is easy to be released to hex (the content of `lib` is added to the package, the content of `test` isn't)

# That's great. So... what's your problem?

I don't like having separate `lib` and `test` folders in phoenix projects. Ones that are big and not meant to be pushed to hex.

I'm bad at remembering shortcuts and names. On the other hand, I'm pretty good at remembering where individual files are stored (especially when the project has a clear division into small contexts). However, I don't want to go through the second tree with the same structure to get to the tests. It has always been a bit annoying.

One day while reading the documentation of `mix test` task, I found out the following options: `:test_paths` and `:test_pattern`. The mere fact that such options exist in Elixir codebase means that they were useful to someone. I decided to check if they would also be useful for me.

First, I changed `:test_paths` value to `["lib"]`. It allowed me to keep a file with tests next to the file with implementation. It also forced me to move `.test_helper.exs` to the root of `lib`, but one additional file isn't a problem. What bothered me more was the alphabetical order. Of two files with the same prefix, the one ending with `_test.exs` was higher than its `.ex` counterpart. It made the files tree in my editor look weird. Luckily, it was easy to fix by changing `:test_pattern` value to `"*.test.exs"`. From now on, files with tests had to be named like this: `my_module.test.exs`.

```
.
├── config
│   └── config.exs
├── lib
│   ├── foo
│   │   ├── bar.ex
│   │   ├── bar.test.exs
│   │   ├── baz.ex
│   │   └── baz.test.exs
│   ├── foo.ex
│   ├── foo.test.exs
│   └── test_helper.exs
└── mix.exs
```

I was pleased with what I was able to achieve.

# Ok. Is that all?

No.

After a few weeks of work in this way, new advantages appeared:

- Code review has become easier because changes to tests are right under changes to implementation (long-gone days of repeatedly scrolling the whole merge request on GitLab up and down).
- Faster refactoring (move single folder when changing namespaces)
- Well-written tests are a form of documentation. It is good to have them in an easily accessible place.
- It's visible if a module is important or not. The file generated by a framework or library doesn't have an additional `.test.exs` file associated with it.

It also has some disadvantages:

- I have to set manually `:test_paths` and `:test_pattern` for every new umbrella application.
- It may not be obvious where to put integration tests when there is no `test` folder.

However, these are minor ones comparing to how more comfortable my work has become.

I'm aware this topic may be controversial for some people. I encourage you to leave me a comment if you think that I've missed something.


VG9iaWFzei1wcm9qZWN0IHN0cnVjdHVyZSBjb3Zlci5qcGc= (1)

https://strapi-appunite.s3.eu-central-1.amazonaws.com/covers-with-text/cc6c4635-41c4-46b6-9059-73a3716af937.png

Reasonable defaults can make your life easier but what reasonable means? How many benefits can the personalized default structure of Elixir project bring? 

Articles

Let’s Work Together!