[mxavier]

When I code in Haskell, the first and most important step I make is to create rich types for the domain I'm working in. If you disambiguate your types, your code becomes more readable and the compiler is a lot better able to help you out when you make a mistake.

For example, rather than having an Invoice with a status field of Text or String, I have a type InvoiceStatus = Paid | Unpaid | Void. From there, you can write a very precise parser that takes exactly what you want and nothing else. When I apply this approach to each component of the thing I need to parse (or do it generically even), I don't really find myself having to munge javascript types into my data structures.

[awj]

To expand on that, these "custom" types are really the only time you have to do any extra work for support with aeson. If you leave your status field as Text or String it's implicitly supported.

That said, aeson support for nullary types (i.e. types that hold no "extra" values, like InvoiceStatus above) is trivial and the types make a huge difference in the rest of your code.