What seemed like a straightforward “itch to fetch”, ended up as a six hour coding marathon.

Suddenly, I had this itch to fetch the date information of the bit.ly shorteners that I was displaying in my Elm App. So, I went about my urge, fully knowing that it is a very straightforward ask, and this time, I would document my progress as I go along.I have been using Glitch to modify my Elm Apps for some time now, and I kind of like it. Although, it is not as intuitive as doing it on Cloud9 or on your local laptop, it has the advantage of being hosted and deployed immediately on the glitch platform itself.

1. First, I fire up my existing version of the App by typing http://bitly-elm.glitch.me/ which brings up the app as shown below:

2. Then I start reviewing my code on Glitch and immediately notice that I have this data type which is the basis of the entire app:

{-| Link is the basic data type that is used to implement the logic
for this program. Link is converted to HayString for some reason.
I used HayString during the testing phase, and will need to refactor it.
Alternatively, by leaving that in, we can convert some other type
and search on that as well. Something to ponder...
-}
type alias Link =
    { title : String
    , keyword_link : Maybe String
    , long_url : String
    , tags : List String
    }

and it needs date information to be captured, before I can even think of displaying it. Now, where to get this information?

3. Then I bring up the test data which is available at https://api.myjson.com/bins/skw8e which immediately shows me two extra fields:

• Created date — always has a valid timestamp value
• Modified date — by default it is 0

• Since I have done this so many times in the past, I know I have to go and modify my JSON decoders which is were these two pieces of data can be obtained.

• Now comes the Googling part for deciding what it takes to convert a timestamp to a date string which is worth displaying.

Incremental approach

While I am tempted to get to the date string and displaying it, I decide, let me take some baby steps. It has been a while, so let me just display the timestamp as a string, before I go back and figure out how to display a Date information.

So, I went ahead and edited in the two additional fields into the linkDecoder function :

Fixing an error

Immediately, from the Log, I noticed that the Elm compiler (which runs automatically whenever a change is made)

Second Error

Immediately, the compiler gives me another error, which is almost guiding me to fix things in a progressive manner?

This means, I have to go and edit things in the Link datatype, which now looks as follows:

type alias Link =
    { title : String
    , keyword_link : Maybe String
    , long_url : String
    , tags : List String
    , created_at : String
    , modified_at : String
    }

And viola! No compile errors in the Log Console.

Invoking the elm-format tool

Now, I launch the full Console log within Glitch so that I can use the elm-format to make sure my edits conform to the coding convention in Elm. I am a big stickler for properly formatted code.

And then I run the optimize.sh script, which actually now updates the files which are actually used to control the app:

public/elm.js
public/elm.min.js

Fixing the View Part

Now, things are available to be displayed, the fun part begins. The view part of the Elm project now needs to be tinkered with.

Backup, backup

I now realized that I must have first started with raising an Issue for this in Github. Better late than never.

So, there you go. Now that I have an issue, I can do a commit to github back with the modified code, so far.

Did I check the run-time?

No, I did not — and so I am in for a surprise. The app does not show any links. But thankfully, because I am displaying an error in the display, I have this to go from:

The fix is rather elementary: the JSON data contains an integer, whereas my decoder is expecting a string. So, that has been taken care of as follows:

type alias Link =
    { title : String
    , keyword_link : Maybe String
    , long_url : String
    , tags : List String
    , created_at : Int
    , modified_at : Int
    }

Meanwhile, the issues gets updated

By using the issue number (#57) in the comments related to the interim exports from glitch to github, the issue on github gets updated, automatically.

Detour done, back to View

Now, I hone in on the right area where I need to plug in the created_at data that is now available in HayString’s created field.

Now, comes the decision, where do I hang this timestamp information? I went to the bit.ly site and saw it is separate and on top of the link. Probably the right place for now. I can always come and change it.

The Real Work

displayURL is where the real action is. This is what decides what displayed and how. For now, I am happy with displaying the integer as an integer. And then come back do something fanciful.

Initial Success!

Some CSS styling

Let’s get some Date Information

First step, is to convert the integer into milliseconds. And then use a formatter to get data information.

Breakthrough at 3.30am

Thanks to the Iso8601 elm-package and the SO answer, my night was saved.

and it resulted in this edit which finally resolved the bug fix.

Need to refactor

My displayURL function has gotten hairy because of the need to convert and display Posix values to Human readable tokens. That is not acceptable. It needs to be refactored. But that can be done later.

The final capture

At 4.08am

Closing the issue on Github

And this is the most satisfying part of documenting an incremental improvement to a side project. To use Resolved #XX (XX being the issue number), and in this case, Resolved #57 was a big high.

The Refactor code

It required the creation of a separate function displayDate which did all the grunt work.

Some more enhancements

These are self-documented in the issue area itself.

• Issue 60
• Issue 61
• Issue 58
• Issue 62

are all well documented and easy to follow.

Improving Elm project in Glitch was originally published in Professional Pirates on Medium, where people are continuing the conversation by highlighting and responding to this story.