From 6dd84ffb9444ecff7e9bfe0883888cb907cca84b Mon Sep 17 00:00:00 2001 From: Evan Czaplicki Date: Sat, 23 Jul 2016 18:03:47 -0700 Subject: [PATCH] Fix sub-headers --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a463785..be00617 100644 --- a/README.md +++ b/README.md @@ -26,7 +26,7 @@ Furthermore, you do not want to be creating table configurations dynamically, pa This library is one of the first “reusable view” packages that also manages some state, so I want to point out some design considerations that will be helpful in general. -## The Elm Architecture / Single Source of Truth +### The Elm Architecture / Single Source of Truth It may not be obvious at first glance, but this library follows The Elm Architecture: @@ -49,7 +49,7 @@ To make this more clear, let’s imagine the alternate choice: instead of gi Point is, **when creating an API like this, own as little state as possible.** Having multiple copies of “the same” value in your `Model` is a sure way to create synchronization errors. Elm is built on the idea that there should be a single source of truth, but if you design your API poorly, you can force your users to make duplicates and open themselves up to bugs for no reason. Do not do that to them! -## Simple By Default +### Simple By Default I designed this library to have a very smooth learning curve. As you read the docs, you start with the simplest functions. Predefined columns, and very little customization. This makes it easier for the reader to build a basic intuition for how things work.