For the remainder of this chapter, we’ll be exploring how to send the
DELETE HTTP requests to create, update, and delete posts respectively. Before we do that though, we need to restructure the code in
DecodingJson.elm. It has reached a point where breaking it into smaller modules will make adding new features easier.
The recommended way to manage data flow in an Elm app is to use the Elm Architecture. Elm doesn’t have such a recommendation when it comes to organizing code, so we can restructure our code however we want. There are many different ways to do it, but we’ll follow what Kris Jenkins — the author of
RemoteData — recommends.
Step 1: Creating a New Directory
Let’s create a new directory called
PostApp in the
beginning-elm directory instead of cluttering
elm-examples with too many modules.
We need to add
PostApp to the
source-directories list in
Step 2: Extracting Types
We’ll be storing all types we’ve defined so far using either the
type alias keywords in a file named
Types.elm. Create that file inside
PostApp and add the following code to it.
Step 3: Extracting
update functions manage the state of our app, so let’s extract them into a file named
In addition to
Types, we also imported a non-existent module called
Rest. We’ll create that module next.
Step 4: Extracting Commands and Decoders
The command we created contains an HTTP request for fetching a resource from a RESTful API server. Let’s extract that command and the decoders it uses into a file named
Rest.elm inside the
It’s worth noticing that we’re only exposing the
fetchPostsCommand from the
Rest module. We don’t want to expose the decoders because they aren’t used anywhere outside of this module.
Step 5: Extracting Main
main is the entry point for our app, we’ll extract it into a file called
App.elm. Create that file in the
PostApp directory and add the following code to it.
We imported a non-existent module called
Views.List. Let’s create that next.
Step 6: Extracting View Code
The only thing remaining to extract out of
DecodingJson.elm is the view code. Right now we have only one page that displays the posts. Soon we will be creating additional pages for updating and creating posts, so let’s create a new directory called
Next create a file named
List.elm inside the
Views directory and add the following code to it.
We have to use a dot in module’s name because
List.elm is inside the
View directory. If we remove the dot and use
ViewsList instead, the compiler will throw an error.
The dot tells the compiler that this module is included in the file named
List.elm which is inside the directory
Views, so go look there. If you don’t want to use
., you can still make it work by renaming the file to
ViewsList.elm and adding the
PostApp/Views entry to
Not only does that take more work, it also makes the file and module names not as elegant compared to the previous approach. Therefore, we will continue to use the dot in a module’s name if that module is inside the
Step 7: Verify Everything is Working
We’re done with refactoring. Let’s make sure everything is working as expected. Run
json-server with a delay from the
beginning-elm directory in terminal if it’s not already running.
elm-reactor from the
beginning-elm directory in terminal and go to this URL in a browser:
PostApp and then
App.elm to run the app. You should see the loading text for two seconds and then a list of posts.
It’s easier to start building an Elm app with a single file. A time will come when the code in that file starts to grow to a point where finding code becomes harder. That’s when you should consider extracting related parts out to separate modules as we did in this section. In the next section, we’ll create a new page for editing a post and learn how to route users to that page. Here’s how the contents of
PostApp directory should look thus far: