Less Wrong Than Yesterday

On designing with sum and product types

I understand product types in statically-typed FP languages; they're records:

I understand sum (or union) types; they're cool:

As I learn Elm, I'm been having considerable trouble combining the two: should I model the problem as a sum type inside a record? as records in a sum type? For a good while in my Eecrit project, I bounced around alternatives like these:

The worst part was that I was developing iteratively, and new features kept breaking my model: I didn't find my design converging in the way that I'm used to from TDD and dynamic languages (be they OO like

Continue Reading...

Phoenix, Elm, and multiple single-page apps

In the running example used in Programming Phoenix, client-side apps are launched from the master app.js file. The Javascript that's loaded for every page checks to see whether this page has the id it's looking for. If so, the code to launch the app is run.

That's fine for the book, as it avoids irrelevant complexity, but I found it awkward as my overall app grew. Multiple clauses of this form:

const ivDiv = document.querySelector('#iv-target');  
if (ivDiv) {  

... are untidy. I'd rather have the "start the client-side" code exist only on the single page

Continue Reading...

Customizing `mix phoenix.gen.*` tasks

Because I am who I am, I've deviated from some default Phoenix file layouts. For example, rather than models having a single changeset function with two parameters you combine in different ways, I've tentatively decided I'd rather have variants like new_action_changeset, create_action_changeset, update_action_changeset, etc. That means a model should start out looking like this:

Similar changes are needed in the controller - and in model tests - and in controller tests. It would be tedious to run the default mix.phoenix.html task and then edit those files to support my quirkiness, so I

Continue Reading...

Thoughts on testing Phoenix views

TL;DR: I'm not a huge fan of extensive unit tests for rendered HTML. Despite that, I've put a fair amount of work into some test support code for Phoenix views. Mostly, that was because I thought it would be a good learning experience for me, a novice in Phoenix and Elixir. But I came up with some testing conventions and code that might be useful to others. They might also serve as a model for testing other complex data structures.

Why don't I like automated tests for views?

  1. Nowadays, it's usually very quick to visually check a change.

  2. You

Continue Reading...

Taking advantage of Phoenix rendering and iodata (part 1)

DRAFT: Expect updates as people who know more than I do correct me.

Among the wonderful things about Phoenix is that it doesn't render strings. Instead, it renders iodata. That's an Elixir idiom that speeds up string processing by avoiding concatenation. But it also makes it easier to work with conditional logic in views and templates. This two-post series is about how I'm doing that in a new Phoenix app (as a new Phoenix/Elixir programmer).

First, some basics

Consider a function helper in a View module, called like this from a template:

What sort of things can helper return?

Continue Reading...