test VS elm-format

The de-facto standard for testing an Elm application is elm-test. However, as noted in the README:

Once all that handwritten C code was solid, I needed to make sure the C generated from Elm was working properly. I found the source for the core library's unit tests and decided to port them into my project and add some of my own tests. You can run the tests in WebAssembly in your browser too. (Funnily enough, one of the biggest challenges was getting the Elm Test framework itself to run! The framework is more complex than the tests themselves. I still need to come back to the fuzzer tests!)

Lesson Learned: Elm has built in recursion improvements for a variety of positive reasons, and you should think in recursion to solve looping problems. Use property/fuzz tests and bounds checking with early exit to prevent this from locking up your UI (i.e if > 9000, omg abort). If you’re algorithm is reasonable, but the data set is just gigantic, offload to a server instead for more horsepower. Or Workers if you don’t have server chops, can’t upload the large data, or don’t trust your server devs. (“But Doc, I’m the server dev!” Good joke. Ever̸y̴b̸ody laugh. Roll on s̵͓̆nâ̶̱re drum. Curtains.)

Keep in mind for the pipes, many in Elm, whether they’re using elm-format or not, will break the pipes to a different line in case there are many of them. For some, they find this more readable (I’m in that group). Let’s show an example of that using the same pattern to design a Paginator, the row of numbered buttons that allow you to move between pages of data.

9ᵗʰ - Aaron VonderHaar releases a new version of elm-format.

Unlike Javascript, Elm has an official Style Guide for how Elm code should be structured. In addition, some formatting is built into the language itself, such as requiring indents of four spaces. This removes a major point of contention within teams. In addition, the community has put together a wonderful tool called elm-format. Similar to Prettier, this utility can be used to ensure that all Elm code matches the official style guide. Unlike Prettier, there is no custom configuration, meaning once again that your team can focus on writing code instead of what kind of quotes to use.

Regarding user experience and tooling, I'd suggest you use an editor that is compatible with the elm language server: https://github.com/elm-tooling/elm-language-server VSCode is a good default choice. You'll also be interested in other toolings. elm-json (https://github.com/zwilias/elm-json) is great to simply install and uninstall dependencies. elm-format (https://github.com/avh4/elm-format) is a must since most active people in the community use it, and simply viewing your code being moved around on save is a good sign that you wrote something with a good syntax.

Take for example the debate about 2 vs 4 spaces. People often (but not always) have very strong opinions about this, yet it is clear that this formatting choice will probably not be the dominant factor in the success of a project. A quick google search also reveals no scientific research in this field. Concerning surveys, I found this interesting (from a survey on 2 vs 4 spaces in elm-format) as one datapoint: