To be or not to be: custom `type`s

[badlydrawnrob]

A few notes and examples from the forums.
My attempt at a custom type and other people's suggestions.

Simple rules to follow

I start with the caveat that for me, as a "non-programmer" just make your apps as simple as feasibly possible. Then handover to someone who knows what they're doing when you scale up!

1. Start with the simplest thing first, until you find that you need a custom type to convey useful information.
   • It's probably right to say that much of the time, regular Elm data types are just fine.
2. As soon as you see complexity and complection arise ... STOP! Simplify it.
   • You don't need to set default data for optional form fields. Don't bother to Json.Encode them
   • You'll have missing sections in your data but just treat them as empty views.
3. Make sure to think through your data structures first. Only use a type Custom if it describes the problem better, or does something a simple data type can't.
   • There's nothing wrong with Maybe, just don't overuse it.
   • Here's a very good reason to use a custom type. Tags could also be a great reason.
   • You might want to distinguish things like Id Int from OtherId Int in your code.
4. Entries Entry (List Entry) could be better than Entries (List Entry)
5. But codecs and hacking json to replicate types can make life complicated.
6. Sometimes you may want to reach for packages that do the work for you
   • Such as RemoteData, nonempty lists or List-Extra
7. But again, we come back to (1) — Keep it simple, stupid!