DEV Community: leojpod

Writing custom-elements for elm

leojpod — Sun, 01 Nov 2020 15:37:29 +0000

Summary: There are 2 options to integrate JavaScript and Elm, one is the port system which has been around for a while, the other is to use custom-elements.
In this post, we'll see that it is rather simple and show 2 examples of packages that use it.

The introduction is a tad long but you can always just skip to the main part.

What's custom-elements?

Custom elements are part of the Web Components and in short, it allows us to create new HTML tag that has a set of behaviour defined in JavaScript.
Think of it as a "super-tiny-application-wrapped-in-a-tag".

Have you ever wanted to define a small thing that you could call like <drawing-board tool="pencil" thickness="10pt"></drawing-board> and get the whole set of features that goes with it?
Well, custom-elements allows you to do just that.

When you think of it, inputs in general and <textarea> in particular encompass a lot of features and "state" to know what the user input is, where is the cursor, if there is some auto-completion available, ...

Custom-elements are just a neat way of defining your own version of that.

For a more complete look at custom-element, you can refer to this post:

Custom Elements

James Robb ・ Sep 26 '18

#customelements #javascript #html

or refer to the GREAT and all-mighty MDN: Using custom elements

How does this help us with Elm?

Quick words of introduction if you don't know Elm: Elm is a functional language designed for the front-end.
Think of it as a "light" and more friendly version of Haskell repurposed for a single task.

Among many advantages, Elm ensures that once compiled your code won't generate any runtime errors.
One of the ways to do this is to force the code your write to handle all the different way things can go wrong using constructs such as Result or Maybe which works just perfectly.

All of this is a long introduction to say that to provide you with this guarantee, Elm restrains the interactions with the unsafe world outside (a.k.a the JavaScript Doomdom...).
Traditionally most interactions are handled in something called ports.
The main interest of exchanging information between the outside world and elm via ports is that you can be sure of preserving the integrity of your elm code.

Custom elements, however, are an interesting way of integrating some isolated JavaScript in your elm codebase.
This covers for instance: charting libraries, chatbots, ...

Yes, yes, good, how does that work then? Well, let's get to it.

Making it work

The elm documentation provides an excellent base to start interoperating custom elements with elm.
However, nothing is better than a ~~shameless plug~~ detailed example.

One thing I often found myself doing in elm in the various project I've worked on is a way to trigger some action based on keyboard events (or rather a combination of keys).
In the past, I had mostly used events from the elm/browser package which worked well but there were some drawbacks (for details on that, you can refer to this link).

Making a custom element to listen to a specific set of shortcut allowed me to keep things simple in my views and treat the shortcut as any other inputs.
Using this small package, I can make a dismissible modal like this:

shortcutModal : List (Html Msg) -> Html Msg
shortcutModal =
    Shortcut.shortcutElement
        [ Shortcut.esc CloseModal ]
        [ class "fixed top-0 bottom-0 left-0 right-0 flex flex-col items-center justify-center bg-gray-500 bg-opacity-75" ]
        << List.singleton
        << div [ class "w-3/4 max-w-4xl p-12 bg-white border-gray-800 rounded-lg shadow-xl" ]

If you look a bit closer to that piece of code you'll see the 2 key lines here:

    Shortcut.shortcutElement -- simply a wrapper for Html.node "shortcut-element"
        [ Shortcut.esc CloseModal ] -- the shortcutElement expect a list of shortcut and Shortcut.esc is just a simple way to say "when the user press ESC send me a CloseModal message"

The main interest of this version compared to doing it with subscriptions and Browser.Events is mainly readability:
Now even small bits of the UI can have shortcut without requiring you to keep track of their visibility/state in your subscriptions and you can also read it directly in the view.

Enough! Show me some code!

The entire code is available here but let's go through the principal components of this solution.

Defining shortcuts

Shortcuts are an association of a message to send and a description of a key combination.
A key combination is a base key and some optional modifier.
Elm provides a nice way to do that with is called union types (if you come from TypeScript or the like, think of them as a super-powerful enum type) and record types (again, TypeScript people, think of it as a simple class without method only some properties).

In the end, the shortcut definition looks like this:

type alias Shortcut msg =
    { msg : msg
    , keyCombination :
        { baseKey : Key
        , alt : Maybe Bool
        , shift : Maybe Bool
        , ctrl : Maybe Bool
        , meta : Maybe Bool
        }
    }

The type Key is a union typed defined as (complete code here):

type Key
    = Escape
    | BackSpace
    -- | ... and many other constructors for the special keys
    | Regular String

Defining a custom element

Before actually writing our custom element(s) one thing we should probably do is install a polyfill.
While custom elements are rather well supported (see Can I use?, even the Android browser joined the party!), it's still safer and nice to people who are stuck on IE11 to use a polyfill and make sure they are not left out.
There is one right here and all you need is just to install it via NPM, ain't that simple?

Once that's done you can start by making a file for your custom element and put the following scaffolding in it.

import '@webcomponents/custom-elements' // that's our polyfill

// custom elements are really just a custom HTMLElement
// so it is really no surprise that you just need to extends the HTMLElement class
export class ShortcutElement extends HTMLElement { 
  connectedCallback () {
    // here goes the code you want to run when your custom element is rendered and initialised
  }

  disconnectedCallback () {
    // here goes the actions you should do when it's time to destroy/remove your custom element
  }
}

// the last important step here: registering our element so people can actually use it in their HTML
customElements.define('shortcut-element', ShortcutElement)

If we look at the code above, the key really is in creating a new class to backup our element that extends HTMLElement and registering it to a tag name via customElements.define(tagName: string, constructor: HTMLElement).

Now let's fill that up.
As mentioned in the comments on the snippet above, the first entry and exit points are the 2 callbacks: connectedCallback and disconnectedCallback.
The first one is called when your element is added to the page, the second one when it's taken away.

In our shortcut example, we'll use the connectedCallback to register an event listener on the body (since that will capture events regardless of what's on the page) and disconnectedCallback to unsubscribe our event listener from the body.
So we'll start with something like:

export class ShortcutElement extends HTMLElement {
  connectedCallback () {
    this.listener = (evt) => {
      const event = evt
      // TODO check with the associated shortcuts if we have a match
      // TODO if we have one then send a custom event
    }
    // let's register
    // NOTE: we will register at the capture phase so as to take precedence over the rest (e.g. textarea, input, ...)
    document.body.addEventListener('keydown', this.listener, { capture: true })
  }

  disconnectedCallback () {
    // let's unregister
    document.body.removeEventListener('keydown', this.listener, {
      capture: true
    })
  }
}

And we're almost done for the JavaScript part! Yes there are 2 big TODO in there but we'll get back to them after we take a look at the elm side of things

How to use this in Elm?

On the elm side, things are rather simple. We need but 2 things: define a custom Html.Html msg that uses our element and find a way to communicate with that element.

The first part is super easy: Html.node "shortcut-element".
To make it nice we can wrap that in a function:

shortcutElement: List (Html.Attribute msg) -> List (Html msg) -> Html msg
shortcutElement =
  Html.node "shortcut-element"

Now, the communication part. Well, this one has 2 subparts actually: information going to the custom element and information coming from the custom element.
For sending information from the JavaScript to Elm we'll use CustomEvent on the JavaScript part which means we can just use our normal Html.Events.on function and the familiar Json.Decode (and Json.Decode.Extra)
For sending information down to the JavaScript from the Elm world we'll play with attributes and properties.

So it's gonna look like this:

encodeShortcut : Shortcut msg -> Json.Encode.Value
encodeShortcut ({ keyCombination } as shortcut) =
    Json.Encode.object
        [ ( "name", Json.Encode.string <| hashShortcut shortcut )
        , ( "baseKey", Json.Encode.string <| keyToString keyCombination.baseKey )
        , ( "alt", Json.Encode.Extra.maybe Json.Encode.bool keyCombination.alt )
        , ( "shift", Json.Encode.Extra.maybe Json.Encode.bool keyCombination.shift )
        , ( "ctrl", Json.Encode.Extra.maybe Json.Encode.bool keyCombination.ctrl )
        , ( "meta", Json.Encode.Extra.maybe Json.Encode.bool keyCombination.meta )
        ]


onShortcut : List (Shortcut msg) -> Html.Attribute msg
onShortcut shortcuts =
    Html.Events.on "shortcut"
        (Json.Decode.at [ "detail", "name" ] Json.Decode.string
            |> Json.Decode.andThen
                (\hash ->
                    List.Extra.find (hashShortcut >> (==) hash) shortcuts
                        -- NOTE: if a event decoding failed then no message is emitted
                        |> Maybe.Extra.unwrap (Json.Decode.fail "did not match a known shortcut") (.msg >> Json.Decode.succeed)
                )
        )


shortcutElement : List (Shortcut msg) -> List (Html.Attribute msg) -> List (Html msg) -> Html msg
shortcutElement shortcuts attrs =
    node "shortcut-element"
        -- Add 2 attributes here: one to send the props we're listening to
        (Html.Attributes.property "shortcuts" (Json.Encode.list encodeShortcut shortcuts)
            -- one to listen to the stuff
            :: onShortcut shortcuts
            :: attrs
        )

(For those curious about the note on the onShortcut function, have a look at this article)

The main thing here is that we're setting a property called shortcuts on our custom elements that contains all the shortcuts passed to the shortcutElement function and that we will listen to the shortcut event from which we are going to extract the name of our shortcut and find out which message should be sent.

In the end, the elm-side looks rather simple doesn't it?

Huston, JavaScript speaking do you copy?

Getting back to our 2 TODO in JavaScript:

find out if we have a match among the shortcut the element should listen for
send an event if there is one.

Since the elm part will set the shortcuts property we can simply access this array via this.shortcuts from within our ShortcutElement class. Then one small caveat with shortcuts is the need to detect which key was really pressed since if we ask the user to press ShiftAlto for instance, the value of event.key might vary a lot based on the user's input method and OS (e.g. o, Ø, ...).
As explained on MDN, using event.code would work if we assume our user are all using QWERTY keyboards but that is kind of a rubbish solution.
Instead, I'd recommend using deburr from lodash, which will remove all the "diacritical marks" (a.k.a. give you back the original letter that was pressed).

Sending out the event is as simple as using the constructor for a CustomEvent and setting a property in the detail part of its second parameter.
Putting it all together we get:

    this.listener = (evt) => {
      const event = evt
      this.shortcuts
        .filter(
          ({ baseKey, alt, shift, ctrl, meta }) =>
            deburr(event.key).toLowerCase() === baseKey.toLowerCase() &&
            (alt == null || alt === event.altKey) &&
            (shift == null || shift === event.shiftKey) &&
            (ctrl == null || ctrl === event.ctrlKey) &&
            (meta == null || meta === event.metaKey)
        ) // now we have all the shortcuts that match the current event
        .map(({ name }) => {
          event.preventDefault()
          event.stopPropagation()
          this.dispatchEvent(
            new CustomEvent('shortcut', {
              bubbles: false,
              detail: {
                name,
                event
              }
            })
          )
        })
    }

To see it in action you can have a look at the Github page here

Apex Charts in Elm

Apex charts is a fancy charting library for JavaScript that provides a lot of interactive chart types and interesting ways to combine them.
As I was looking for such library in Elm but could not quite find the one I was looking for, I thought I would make a custom element to integrate Apex charts and Elm.

In the end, it allows the dev to write things like:

Apex.chart
    |> Apex.addLineSeries "Connections by week" (connectionsByWeek logins)
    |> Apex.addColumnSeries "Connections within office hour for that week" (dayTimeConnectionByWeek logins)
    |> Apex.addColumnSeries "Connections outside office hour for that week" (outsideOfficeHourConnectionByWeek logins)
    |> Apex.withXAxisType Apex.DateTime

and get a nice chart with one line and 2 columns.

Since this post is already quite lengthy, I'll keep the second custom element for another time but you can already have a primeur of it here (with the code here).
To make it work, we will need to take a closer look at getter and setter in JavaScript so as to handle properties that can change over time (i.e. during the life-time of our custom element).

Anyone attending AWS summit online?

leojpod — Wed, 17 Jun 2020 07:58:11 +0000

I'll be listening all day, any tips on which topics not to miss?

Testing and documenting your APIs with Vim-Rest-Console

leojpod — Thu, 27 Feb 2020 16:45:53 +0000

I have previously written about a few plugins that I enjoy immensely while working with vim every day.
I had so far forgotten an obvious one until I read a post on Dev.to about yet another VSCode extension copying its behaviour from the already existing and great Vim counterpart!
Not to be a complete troll but it's nice to see that the other editors are finally catching on... 😁
Sadly they are not reusing the existing syntax making sharing those requests among co-workers not using the same IDE not quite possible...

Bye bye Postman ! Let's share your REST API calls in team, easily !

Jonathan BROSSARD for Monisnap ・ Jan 10 '20

#vscode #rest #postman

It would be interesting to try unifying those various plugins and get one common syntax. That way, the IDE troll-war wouldn't prevent people from having the niceness of versioning their requests!

Anyway, I thought a quick review of the vim-version could be a nice thing to have on dev.to, so without further ado here we go.

vim-rest-console

In essence, this plugin is quite simple: it defines a .rest file format and provides one command to run the HTTP call under the cursor of a .rest file. By default, this command is mapped to <C-j> but I had hard time remembering it so I remapped it to <C-x> (for eXecute).

For a complete look at the doc, just follow the usual :help rest-console😀. But let's have a look at the basic syntax.

A simple request looks like this:

http://someurl:port
// here you can put some options: 
// - either cURL options
// - or Http Headers for your request: e.g. content-type, ... 
GET /api/status

As you can guess, there is a way to avoid repeating the host of your request and the headers that you'd like to have by default. You can do that in the global section of your .rest files.

Best use an example to see how that would work:

# Global section
// set the host for the whole file
http://localhost:1337

// set some common header
// those can be overriden for specific calls
Accept: application/json
Content-Type: application/json
// usually most of the api you're gonna call are gonna be secrued behind 
// some authentification scheme. 
// I tend to put mine at the top of the files (of course you need to 
// change those frequently as they have an expiration date)
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.{...}.ka3IfQFX0-Yb5uFp45f97y0zEevNf3en8TLzoPEJDu0



// you can also setup some variables here: 
username = John Doe
password = NOT_a_g00d-password

// the two -- coming next are important: they indicate the end of of the global scope
--


-- // <-- to start a request block, put two dashes
# Get some resource // be nice and put some comments about what your request does
GET /api/resource

-- 
# Create a user
POST /api/users
{ 
  "name": username
  "password": password
}
// note the use of the variables above

⚠️ an important thing to keep in mind

Vim-rest-console does NOT encode your URLs and this is particularly something to keep in mind when your API allows some complex filtering on your GET requests.

I lost a couple of ~~minutes~~ almost an hour on this particular request last week. My API leverage some of sailsjs' powerful ORM to allow to write queries like: ?filter[name]={\"startsWith\":\"jojo\"}. While writing it in my Rest-console file I had completely forgotten about this, hence my request wasn't returning me any match. Once corrected back to: ?filter[name]=%7B%22startsWith%22:%22jojo%22%7D all was good again. 🙏

In short:

As always, vim shows that it's a full-blown IDE for whoever wants to make it their own and I hope that this quick example will help you on your vim-journey. Don't hesitate to reach out if things are unclear!

Reviewing PR from Vim: Critiq.vim

leojpod — Mon, 11 Nov 2019 15:16:59 +0000

Reviewing PRs is daunting at times, even when dealing with merge requests less massive than the one showed in the cover picture. But regardless of the size of the PR, it has become my latest obsession: why should I quit the comfort of my own settings to review some code? Wouldn't I do the same faster if I was keeping my own cherished environment?

So, after a quick web search, I found a few candidates and narrowed it to one by applying the "last commit on GitHub/Gitlab shouldn't be 3+ years old if issues are more recent" rule: Critiq.vim.

Preliminary work

Before using critiq.vim I had to make a few changes to my config files: mainly, I introduced a new file, which will be imported when loading zsh, that will load some secrets into environment variables to let Critiq use my GitHub account (the changes are in this commit if anyone is mad enough to check it). The nice thing to remember here is that you don't have to put your GitHub password to authenticate with Critiq (thanks for that!). Instead, you can just head to https://github.com/settings/tokens and generate an access token, give it just the rights you want and use that.

Reviewing Critiq.vim

(pun intended)

The first thing you need to do once you've installed Critiq.vim is to simply call it: :Critiq which should list the open PRs from Github for your current project in a new tab (this was also a good opportunity for me to (re)learn about tabs in vim since I tend to do most things with only buffers). Pick one and press Enter. This should open 2 panes: the description of the PR in the upper pane and the diff in the lower one.

From there, just go about your business as you would in GH, with a few twists.

I don't get how it runs 🤔

:CritiqCheckout while it doesn't do exactly what it should (check out the branch locally), it does check out the code but under a weird name. I assume it does this to prevent conflicts with a potential local branch. Either way, after that you can just move to the previous tab to get your regular vim setting and go check that file or even simpler: CritiqOpenFile which will open the file in a new vertical pane for you. Isn't that neat?

That's code could be better!

:CritiqCommentLine while the cursor is on the line you want to comment will open a new small pane at the bottom in which you can type your comment. When you're ready to submit it: :CritiqSubmitComment

I haven't found yet if there is a possibility to write up a suggestion directly but it's not too complicated to write it yourself since it is after all just a simple code sample typed as suggestion

Approve/Reject/Comment

The last part of the process is now to submit your final assessment of the review: :CritiqComment, :CritiqApprove & :CritiqRequestChanges are here for that. They will open a new pane to write a comment justifying your assessment. Then use :CritiqSubmitReview and job done!

I've created a quick terminal recording (with asciinema) to show how it works (which sadly doesn't keep my beloved colour scheme):

Final thoughts

I'd like to see if it is possible to achieve the same thing for Gitlab as well. I also spend a good time on Gitlab-hosted projects and that would be grand!

Hope this can be somewhat useful to others and see you next time!

Hacktober: From Exercism to elm-pages

leojpod — Tue, 05 Nov 2019 14:15:26 +0000

So, at the beginning of last month, I asked my boss at Zeit.io if it was ok to push some PRs around for Hacktober while waiting for the compiler which he, of course, accepted and encouraged.

No excuses for not doing this year then!

Exercism

Exercism is a great platform to learn a programing language and owning your skills. I was feeling kind of bad for not having time to review people's submissions on the elm-track as I used to a while back. So I decided that I could at least use Hacktober to give back to this platform by implementing a few problems for it.

It was a rather interesting experience as porting a problem includes several steps:

RFTM ... (a step I clearly missed at first which lead to my first PRs failing tests because I hadn't set up properly my exercises). The Generating setup part was really helpful to repair my dive-in-first-read-the-readme-after approach.
The first step I always took after setting up the folder for the new exercise was to grab all the data from the canonical-data.json file from the exercise specification and turn it into a test suite with elm-test (I was more than glad to use vim and to have become decent at making macros to turn each entry into a test case without having to write too much code myself)
Once I had the test suite it was time for the really fun part: Make the first solution for the actual problem! For some exercises it was rather straight forward, for other it was actually more complex (looking at you bowling exercise)
Clean up! An important part of making nice exercises is to make sure that the solutions are clear enough as they might be de-facto examples for a while, one should make sure that the code looks nice enough.
Push the PR and collect a T-shirt :)

Elm-pages

I have recently discovered this project on the elm slack (join us here: http://elmlang.herokuapp.com/). Since I'd read a few days before about the possibility to sync dev.to and something like gatsby I was quite keen on looking up this project. One of the issue I had originally was that it forced me to use the port 3000 to work with locally which was already quite crowded by work stuff.

So I've made adding an option to specify the port my last Hacktober PR. It allowed me to dive into a really interesting project made by the same guy who is behind elm-pages ((Dillon Kearns)[https://github.com/dillonkearns]): (elm-cli-options-parser)[https://github.com/dillonkearns/elm-cli-options-parser]. It's a project that allows you to use elm to define a CLI interface. It's simple yet powerful. If you want to build a CLI tool with elm or node definitely have a look.

To sum it up, it didn't take very long to participate and hopefully help out and it was rather fun. Also, right after that, we completed our migration from elm 0.18 to 0.19 so no more "it's compiling" excuses from now on!

The day I decided to learn DBext.vim

leojpod — Mon, 23 Sep 2019 09:49:53 +0000

Feel free to skip over that part and head straight to the hopefully useful content here.

Almost a year and a half ago, while I was working at Repositive (a cool start-up, you should check what they do), I was convinced by mostly 2 of my colleagues to start using vim.

Soon after, I started a quest for plugins for everything! A part of that quest can be found by looking at the history of my dotfiles repo, you'll see it's a mess.

At some point during that quest, I thought of looking for a plugin that would allow me to not use things like workbench, robomongo, pgAdmin or even psql as I tend to use most after I ditched Atom for nvim. That's when I found this plugin: DBext.vim

It promised to do all I needed and then some more! awesome!

Except, I never took the time to learn it properly hence I never used it and continued to hack my way with psql. Fast-forward to today, I had to do a bunch of work on our database for my new ticket at Zeit.io (new website coming soon - in the meantime, if you need something done well give us a call!) and went on looking for the perfect nvim plugin again and ... wait a minute, I know this plugin! Yep... I knew it, it was already in my config and had been there for a while... So this time I decided to take learn how to use it properly or well enough at least that I would not need to use psql anymore and could work from my text editor.

Diving in

The repo's README.md sounded a good place as any to start and that 's where I saw that DBext.vim provided a nice tutorial, it might be a bit lengthy for some but in short:

start by setting up a connection: in my case, I wanted to connect to PSQL by default so I added this to my .vimrc

let g:dbext_default_profile_PG = 'type=PGSQL:user=postgres:passwd=:host=localhost:port=5432:dbname=@askb'
let g:dbext_default_profile = 'PG'

Note the @askb, it means that DBext will prompt me to know which database to connect once for each buffer.

then learn about a few commands that are quite handy:
- <leader>sbp: if your config isn't right this will allow you to open a quick setup guide. I used it a lot while trying things at first.
- <leader>slt: list the tables in your database.
- <leader>st: show table, probably one of the command I use the most. It allows you to get a really quick overview of a table. Just put your cursor over a table name, type in the mapping and voilà! (If you capitalise the t, i.e. <leader>sT, DBext will prompt you to know how many rows you'd like to see)
- <leader>stw: Same as above but will ask you for a WHERE clause. This is sooo neat!
- <leader>sd: Describe the table instead of listing its content, this is also pretty handy.

But most importantly the feature I like the most in all of this is that I don't need to be in a SQL or any other database script: I can run all these from anywhere, from my front-end code, from the doc, from a ticket description, ... This allows me to get a quick glance at what the db holds and to get good insights on what it holds for which tables.

EDIT: since I started writing this post, I've seen the Tim pope version of this: vim-dadbod. I haven't tried it yet, that might wait another year :D but if you've feedback about this plugin or some database recipes to share: please let me know!

The interesting case of the `/remind` command in slack

leojpod — Wed, 31 Jul 2019 15:34:35 +0000

A while back, as I was setting some reminder on slack so I would not forget about that code-review I was supposed to do, I missed type what I wanted to ask slack to remember. It showed me this help message:

I'd seen this message a countless amount of time before but I don't know why I paused. @someone? Really? Can I make slackbot notify other people whenever I want? Even if I'm not online? let's give it a try, shall we!

Next, I was setting up a couple of reminders for my colleagues so they would not forget to drink coffee and take a walk from time to time to refresh their brain...

Still when concentration is maybe the most precious asset for a dev, isn't it odd that we can steal away that of our co-workers in one line?
In order to prevent any retaliation, I started using the /dnd command to turn off any notification for a given amount of time. As an occasional Pomodoro person, I must that using /dnd 25 minutes is working well.

Has anyone found a useful use case for putting reminders to other people?

Has anyone tried pixel art with their GH profile?

leojpod — Sun, 28 Jul 2019 14:52:01 +0000

If you think of it, the infamous GitHub show-off activity-viewer is just a small canvas of roughly 52*7 pixels...

It should be possible to make a mono-chrome of something with it.

My 5 late ideas for the 'Blog More' challenge on CNC2018

leojpod — Mon, 29 Jan 2018 15:52:11 +0000

So here is a mix of 5 ideas which is a mix of some old and new ones for posting (those in bold are locked for the next phase):

1/ Making a PWA in Elm: I made a small tabata/interval trainer app in Elm that runs with Webpack and cordova. How to make and deploy an app with that stack, how to make a PWA with lightbox, some personal experience and why I would skip cordova if I was to start again
2/ Playing with SVG and animation in Elm: still about this tabata app, I've made a few unsuccessful attempts to get a nice animation while working out and resting. Comparing generating an animation tag in SVG vs regenerating the SVG itself from Elm (latter is the best solution IMO but... I'd started with the other one first)
3/ The carbon cost of emails. I recently switched from gmail to lilo.org's mail solution, it's a carbon-compensated solution and that got me to think of a few costs of emailing, problem is there isn't enough good numbers on it.
4/ Some kind of shortish "biography" on how I went from an engineering school in France to freelancing from the North of Sweden and focus on a few pointers to start as a freelancer and of what I would do different.
5/ Another Elm article about some of the tools in the ecosystems that I recently discovered hoping other Elm enthusiast will get to know them if they haven't already (mainly elm-lens & elm-analyse to provide the next level of code quality for your elm projects).

So I've got the 3 posts I needed! Thanks to all of you for helping!

A few more steps with Elm: Mdl, architecture and "local" update

leojpod — Mon, 22 May 2017 15:20:24 +0000

Picking up where I left off last time, I'll share my experience on moving from an ugly web-page to an elm-mdl based one and how to split the code and the update method (which doesn't seem that popular though)

Starting to play with elm-mdl

Although the module elm-mdl proved itself rather nice to use, setting it up wasn't as easy. I followed this post to set up my app. The first step was to create a "property" on my main model to plug-in the mdl model. This is where elm-mdl is gonna work its magic and keep up with the state of things across the app. elm-mdl also provide us with an "initial" state for its module.

Next thing that we need to do to get ready to play with elm-mdl is to "tag" elm-mdl's messages so that anything coming up for an elm-mdl function in your code will be redirected to elm-mdl for handling, be transformed into whatever you asked for and be returned to you in a better message. We will do that by adding this:

You'll probably have to follow the same principle for the subscription if you start playing with Layout and things like that but elm-mdl explain it rather well and the previously mention post as well.

Then of course you need to remember to put these lines in your html file (and no I definitely did NOT scratched my head for a moment before I remember about it…)

Talking about the index.html file. I couldn't find a nice way to use a custom html file with elm-reactor, so instead I turned to elm-live for that. Bottom line: install it with npm or yarn and then use this line to start your app:

elm-live "your-file" --output=elm.js --open

and that's it! Elm-live will open your browser and reload as you make your changes! Ain't it cool?

Splitting the app into "modules"

One thing bothered me with the code as it was: having all the code in a bunch of big files, no matter how clear they were, was still not "clean code" for me. So I went out and tried to find guidelines on how to split the code and found out this link. Well I had to pause a bit after reading it actually. Splitting the original code into different files to separate the responsibilities was rather easy. I got 4 files:

Types.elm: host the types used in our application (mainly Model and Msg)
State.elm: host the state of our application. i.e. how to initialize the application, how to update it
View.elm: host the HTML of our application
App.elm: ties it all together!

Now, that was enough for my small game but still it would have been cleaner to extract each part of the application in a separate module. So for the sack of the exercise (and for the peace of my mind…) I split up the application on 2 parts: the setup and the actual game. I will not go into the detail of the implementation of each module: it is more or less copied and paste from the previous implementation however linking the pieces together was rather interesting and we'll check that out here.

First let's look at the "main" type file:

What we see in here is more or less a natural definition of our model: a record that host the model definition of each of its submodule. Each module in turn is responsible for hosting whichever properties they need in their model. But the most interesting part (IMO at least) lies in the State.elm file where we will define the app's initial state and update function.

As you can see on the init, this code is rather simple yet verbose. For each direct child-module, our current modul need to pull the init state and add it to it's own init. This could be automatically written though, I hope to have some time to dig in Atomist to try making that happen. Then the update method is just a dispatcher that forward each message to its rightful submodule. It makes it rather easy to communicate between each submodule as they just need to trigger the right message to send something to another module: in this app for instance, the setup send message to let the board module now when it should be ticking or not. The counter point to that is that it requires our view to send Msg (i.e. the main message type).

The same observation can be seen on the Cmd part of our update method in the submodule. One could be tempted to "tag" the command like we do for the elm-mdl messages but then it would prevent or at least complicate the process of sending command to other modules.

Anyhow, enough of that. Have a look at the code if you've questions, suggestions I'll be happy to talk :)

A quick stop via SVG!

Before closing this post, let's have a look at how manipulating SVG is seamless in Elm. For those who checked the code of my first post about elm you've seen something like this:

the ugly state in which I left things lastÂ time.

The view code that was responsible for that horror looking table was this:

Switching to SVG was seamless: in Elm SVG nodes are manipulated exactly like HTML ones! (provided you remember to elm package elm-lang/svg).

And we're done!

If you want to have a look at the app's current state: check this out

Why is there no need for Multicase matching in Elm

leojpod — Thu, 30 Mar 2017 15:23:58 +0000

As a beginner developer with Elm, I quickly ended up both loving the union types and the _ operator but founded a tad bit irritating the absence of Multicase matching until … Until I saw the light!

TL;DR?

Use the following pattern whenever you have some behaviour shared by several constructor of your union types and stay away from the _ operator!

The problem with single case matching

Let's say I want to create a task tracking software. I might end up with this Item type to describe my model:

As you can guess, a lot of operations are gonna require the same treatment for most kind of Item : assigning the item to somebody, changing the start or end date, adding/editing a description, … while there will be some that will differ. So how can we deal with that?

Using the underscore matching

When I encountered this problem my first idea was to use the _ to match all the kind of Item that didn't require a specific treatment for any given case ... of . There are two main problems with that approach: we can't get the properties and it introduce potential BUGS! And by that I mean problems and unexpected behaviour that won't be caught up by the compiler. But first let's see how it looks:

Let's take back the Item example and let's pretend that we want to create a new kind of Item : milestone. Say milestones do not have start date but are just used as deadlines. Say my app is pretty developed and I am doing a lot of things on my Item and use the underscore matching a lot. By adding a new kind of Item in my union type I'd expect the compiler to throw a bunch of errors at my face directly which will not happen in that case: my new kind Milestone would already be matched by the _ so there will not be anything wrong that will be caught by the compiler. Yet I probably don' t want my Milestone items to be dealt with like any other items… So I would have to resolve to looking up for any _ and make sure that I adapt the code manually.

The replacement

Use let … in! (or make another helper function)… It really is as simple as that… instead of making multicase matching, put the common treatment in a function within the let ... in or put it outside if the treatment is consequent and use it afterwards:

And voilÃ ! It sounds pretty stupid but I hope it helps!

Here is a small "project" showing this… nothing fancy, only one message and one button.

To all JS dev, please use Standard!

leojpod — Wed, 29 Mar 2017 14:52:52 +0000

Once upon a time

you can jump over that section it's merely an introduction of what has led me to adopt standardjs

As a dev coming from the world of Java to JavaScript some 6-7 years ago I was kind of lost by the "liberty" of coding that JS offered. Then again with that was a good deal of good and bad things and I quickly ended up using JSLint to help me navigate through this world and to teach me what was right and what was wrong.

It wasn't enough though. I quickly moved on to JSHint, later to JSCS and to ESLint with each time a new set of recommendations and some change to my coding style and habits. It is worse noting that most of these tools were actually a great help to polish my skills little by little each of them providing finner and finner warnings.

What's the link with Standard.js?

That I've seen a lot of different style of JavaScript and I am use to the discomfort of changing your coding habits from one style to the other depending on which project one works on.

Recently, I've been working on 3 different freelance projects all using different configuration of ESLint... Why are we doing that to ourselves when there is a single style without config (a.k.a divergences) readily usable!

By using one single config for all the JS code out there no more time spent configuring an IDE, no more time "configuring" our brain to read and write the code according to this or that style.

The ultimate rules!

As said previously, standardjs makes opinionated yet fully justified choice regarding the coding style. You may not agree with all of them but it doesn't matter! (I disagree with many exceptions of the French language but I still accept them :x).

Here are the "main" ones:

no unused variable: it always drive me nuts when I review some code to see them... I become a game of guessing, what that supposed to be used somewhere? Should I delete the whole stuff?
plenty of aesthetic decisions that helps make the code clearer
plenty of totally sound decisions about more or less obscure things that are allowed by JavaScript but that should never have been! (like reassigning const, calling constructor without parenthesis when there is no parameters, ...)

Globally there is nothing out of the ordinary in there. Most of these rules are already applied by most of the good coding styles out there. The most important change however is yet to be introduced.

Getting ride of the semicolon

Perhaps the most important change when switching to standardjs is to stop putting ; all around the place. We don't need it! If you doubt it, go read this and that.

When I read it for the first time I paused for a second and asked myself why I had always put some? 'cause I was coming from Java and Java forced me to... Right but other than that? No idea.

Moreover, how many lines of code do we type everyday? sparing that one key press if helping greatly to reduce the stress and repetitive strain injury risks to our right ring finger. Ain't it great?

Just a few more words

A few notes to conclude this totally biased post:

standard is totally compatible with ES6!
there is an effort toward porting standard to the TypeScript world
you don't need to agree with me but please give standard a try :D