elm-conf-2018-data-vs-metadata.md

Data vs Metadata

What do types like Maybe and RemoteData have in common? They both augment some other value with contextual metadata (presence and request status respectively).

Using this mental model, we will look at various ways we can design data structures that represent contextual metadata as well as strategies that can keep that information out of our core business functions. Has Maybe taken over your codebase? Do you need to model a complex data synchronization problem? This talk will equip you with the mental model and tools to deal with these problems and more.

Details

When designing functions, we often need some extra context about the data passed in. This extra context might tell us whether our argument has been toggled open or shut in the UI, whether the argument is in sync with the server, or even whether the argument is present or not.

It's easy to mix data and metadata, however allowing them to bleed into each other often leads to tightly coupled, non-confident code. By enforcing separation and keeping metadata out of "business functions", we can avoid a lot of unnecessary conditionals while also achieving higher code reuse.

This talk will make a distinction between "core data" and "contextual metadata". It will look at various ways we can design data structures that represent contextual metadata as well as strategies that can keep that information out of our core business functions.

We'll also confront some ambiguity as what counts as "contextual metadata" depends on where you're looking from.

I'll be looking at some contextual data structures such as:

the core Maybe

type Maybe a
  = Nothing
  | Just a

custom toggleable state

type Toggleable a
  = Open a
  | Closed a

and fancier types such as this one that tracks the synchronization state of data on the client and server.

type ClientServerData id local remote
  = OnClientOnly local
  | Diverging id local remote
  | Synced id remote

along with a "core" type like User. Well contrast functions that operate on User directly as opposed to values like Maybe User, Toggleable User, or even ClientServerData Id UserForm User.

We'll talk about data structure design, function design, and how everything fits together.

Pitch

I've consulted on multiple Elm projects and have helped out many in the community. I've noticed that a lot of pain points come down to not enforcing a separation between data and metadata. This could be as simple as allowing Maybe to run rampant throughout a codebase or might be a custom type that's leaking.

This talk will equip attendees with a mental model to think about their data structures and functions as well as strategies for combining them without the pain associated with tightly coupled data and metadata.