D3 and ClojureScript

This is a guest post by Joanne Cheng (twitter), a freelance software engineer and visualization consultant based in Denver, Colorado. She has taught workshops and spoken at conferences about visualizing data with D3. Turns out ClojureScript and D3 are a great fit, in this post she’ll show you how to create your own visualization using the power of D3 and the elegance of ClojureScript.

I use D3.js for drawing custom data visualizations. I love using the library, but I wanted to try one of the several compile to JavaScript options, and I decided to look into ClojureScript. It ended up working out well for me, so I’m going to show you how I created a D3.js visualization using ClojureScript!

What we’re visualizing

The U. S. Energy Administration releases data on how much energy the US produces and consumes and what types of energy are used. NPR released slopegraphs of how much and what types of energy each state in the US produces. The article inspired me to dive into the data and create a slopegraph that shows how energy generation has changed in the entire country over the last 10 years.

I downloaded energy generation data from 2005 to 2015 from the U. S. Energy Information Administration data browser, converted it to a Clojure hash map, and used it to create the visualization.

Setup

Install Leiningen

If you don’t have Clojure set up on your machine or installed it years ago, telling yourself that you would look into Clojure one day, you’re going to need to install Leiningen. Leiningen is your build tool and dependency manager for this project. You can use your package manager of choice to install it (preferred) or check out the installation instructions on the official website.

Figwheel

We’re going to create a new Figwheel project. Figwheel is what is going to create our new project directory, build our ClojureScript code, and autoreload the browser every time our code changes.

In your command line, go to the directory where you want your project to live and run the following command:

lein new figwheel us-energy-slopegraph

Sit back a few seconds, and make sure no errors appear. Here’s what the output should look like:

Generating fresh 'lein new' figwheel project.

Change into your 'us-energy-slopegraph' directory and run 'lein figwheel'
Wait for it to finish compiling
Then open 'http://localhost:3449/index.html' in your browser

Now you can change into your newly created project directory, and start Figwheel:

cd us-energy-slopegraph
lein figwheel

You should now see something like this:

$ lein figwheel
Figwheel: Cutting some fruit, just a sec ...
Figwheel: Validating the configuration found in project.clj
Figwheel: Configuration Valid ;)
Figwheel: Starting server at http://0.0.0.0:3449
Figwheel: Watching build - dev
Compiling build :dev to "resources/public/js/compiled/us-energy-slopegraph.js" from ["src"]...
Successfully compiled build :dev to "resources/public/js/compiled/us_energy_slopegraph.js" in 1.689 seconds.
........
Prompt will show when Figwheel connects to your application
dev:cljs.user=>

After a little while your browser will pop up with Figwheel’s welcome page, located at http://0.0.0.0:3449. Now your ClojureScript project is all set up!

Every time you save a file in the project directory, Figwheel will automatically recompile and reload your browser, so you don’t need to manually refresh the page.

Once it’s fully loaded, Figwheel will switch to a REPL, a command line prompt that lets you evaluate bits of ClojureScript. This allows you to enter bits of ClojureScript code directly into your terminal, and it will be executed by your browser.

Type this in and press “enter”:

(js/alert "Now look at your browser!")

Installing D3.js

In your us-energy-slopegraph project directory, open the file called project.clj. Insert [cljsjs/d3 "4.12.0-0"] in that list of library names after :dependencies: It should look something like this:

  :dependencies [[org.clojure/clojure "1.8.0"]
                 [org.clojure/clojurescript "1.9.946"]
                 [org.clojure/core.async  "0.3.443"]
                 [cljsjs/d3 "4.12.0-0"]]

Now you’re going to want Figwheel to install this dependency. Restart Figwheel by hitting Ctrl-D and running lein figwheel again. Figwheel will install any new dependencies added to project.clj.

Open up src/us_energy_slopegraph/core.cljs — you’ll mostly be working in this file. You may notice there are a few lines of boilerplate code. Remove the println and the defonce app-state lines - we don’t need those for this project. core.cljs should now look something like this:

(ns example-project.core
    (:require ))

(enable-console-print!)

(defn on-js-reload []
  )

The first line is the namespace definition. This is also where we’ll load the D3.js package that we just installed. Require cljsjs.d3 in this file by altering the first two lines to look like this:

(ns us-energy-slopegraph.core
  (:require [cljsjs.d3]))

By loading this namespace you make sure the necessary JavaScript files get loaded. These typically define global variables, which you can access with the js prefix, like js/d3. If you wanted to add React to this ClojureScript project, you would add it as a dependency, require cljsjs.react, and access it with js/React.

ClojureScript and JavaScript libraries

Using existing JavaScript libraries from ClojureScript can be challenging. ClojureScript does aggressive code optimizations, but these only work when the compiler is able to analyze the complete project, including third party libraries, and this isn’t always possible for code found “in the wild”.

So called “externs” provide extra hints to the compiler about external references that should not be optimized away. The CLJSJS project bundles popular JavaScript libraries together with the necessary externs, and publishes them on Clojure’s code repository: Clojars.

More recent versions of ClojureScript support NPM packages directly, so in time the need for CLJSJS will go away, but for now it’s still the most convenient way to include JavaScript libraries in your ClojureScript project.

Code

Let’s first add some scaffolding to make sure reloading works smoothly.

When you open http://localhost:3449/index.html in your browser, it’s loading resouces/public/index.html. Let’s make a few changes so it works better with this project.

First add this CSS link to the <head> section:

<head>
  ...
  <link href="https://rawgit.com/lambdaisland/us-energy-slopegraph/master/resources/public/css/style.css" rel="stylesheet" type="text/css">
</head>

And then replace the <body> tag with this:

<body>
  <div id="slopegraph">
  </div>
  <script src="js/compiled/us_energy_slopegraph.js" type="text/javascript"></script>
  <script>us_energy_slopegraph.core.main()</script>
</body>

Save and reload the page in the browser. We’ve added a <div> for the visualization, and an extra <script> tag. This script calls an exported function called main in the us-energy-slopegraph.core namespace and is called once when the page loads. We’ll implement this main function in ClojureScript.

Add this main function (make sure it’s before the on-js-reload function) in core.cljs and export it so it’s callable from JavaScript.

(defn ^:export main []
  (println "This is the main function."))

Also call this main function in on-js-reload

(defn on-js-reload []
  (println "This is the on-js-reload function.")
  (main))

Now make some changes in core.cljs — you can just change the string in the println function — and save the file. When you look at your browser’s JavaScript console you’ll see that on-js-reload gets called every time you make changes.

Why are we using this pattern? Figwheel has an autorefresher built in that will load what we write into the browser. We want to create a main function so we can define exactly what happens when the the app loads the first time, and what happens on subsequent reloads.

SVG

One of D3’s core concepts is the data join. This tutorial won’t go into the deep parts of D3.js, so if you’re completely unfamilar with it, I suggest looking into Mike Bostock’s blog post or the book Interactive Data Visualization for the Web.

We’re going to be drawing our visualization using SVG. To start, we’ll need to create an SVG element using D3.js.

Before you continue you might want to grab this code template off Github. ClojureScript can be quite particular about the order you put things in. The template contains empty stubs for most of the functions so you can simply fill them in, and named sections that should make it clear where to put the rest.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; data

(def height 450)
(def width 540)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Lifecycle

(defn append-svg []
  (-> js/d3
      (.select "#slopegraph")
      (.append "svg")
      (.attr "height" height)
      (.attr "width" width)))

append-svg is a function that selects an HTML element with the id of slopegraph, appends an svg element, and sets height and width attributes on it. The Mozilla Web docs is a resouce that can tell us what attributes we can set on certain SVG elements are great to have as a reference when working with SVG. We defined the height and width values in the first two lines of the code example above because we’ll be using them throughout the code example.

In JavaScript append-svg would look like this:

function append_svg() {
  return d3.select("#slopegraph").append("svg").attr("height", height).attr("width", width);
}

Try calling (append-svg) from the Figwheel REPL running in your terminal.

(us-energy-slopegraph.core/append-svg)

Now inspect the page in your browser (F12). You should see an SVG element in your HTML now!

<div id="slopegraph">
    <svg height="450" width="540">
    </svg>
</div>

Now call append-svg from the main function so that you have an SVG element to work with when the page loads.

(defn ^:export main []
  (append-svg))

Save the changes, and inspect the HTML on index.html again. Do you notice anything unusual?

There are two SVG elements! When we save our changes, on-js-reload gets called and calls main, which calls append-svg.

To solve this issue for now, let’s remove the SVG element when on-js-reload gets called. Add the remove-svg function to core.cljs, and modify on-js-reload so we call remove-svg before main is called.

(defn remove-svg []
  (-> js/d3
      (.selectAll "#slopegraph svg")
      (.remove)))

(defn on-js-reload []
  (remove-svg)
  (main))

As soon as you save this change core.cljs will reload, Figwheel will invoke on-js-reload, which then removes any leftover <svg> elements, before adding a new one. No more duplicate SVG elements!

You’ll notice I used the thread-first macro (->) in append-svg and remove-svg when chaining calls to D3 methods. The thread-first macro takes a starting value and a number of function calls. The starting value is used as the first argument for the first function, then the result is used as first argument for the next function, and so forth. This helps us “chain” the D3 selection methods together. Without it remove-svg would look like this:

(defn remove-svg []
  (.remove (.selectAll js/d3 "#slopegraph svg")))

Those periods in .remove and .selectAll indicate that we’re calling JavaScript methods, rather than plain ClojureScript functions.

You may also want to check out the .. operator. It works similarly to thread-first, but you don’t have to prefix all those JavaScript methods with a .. The ClojureScript Interop episode on Lambda Island explains more about this syntax.

The benefit of using -> over .. is that it allows you to freely mix ClojureScript functions and JavaScript methods.

The Data

I used a separate script to transform the CSV data I downloaded from U. S. Energy Information Administration into a ClojureScript hash map containing the percentages of a few energy sources generated (Note: “Renewables” is the sum of biomass, geothermal, solar, and wind). This is the data we’ll be working with to draw our slopegraph. Insert this hash map definition into core.cljs.


(def data {2005 {:natural-gas 0.2008611514256557
                 :coal        0.48970650816857986
                 :nuclear     0.19367190804075465
                 :renewables  0.02374724819670379}
           2015 {:natural-gas 0.33808321253456974
                 :coal        0.3039492492908485
                 :nuclear     0.1976276775179704
                 :renewables  0.08379872568702211}})

Drawing!

Let’s create a function called draw-slopegraph that takes a D3 selection called svg and the data hash map. Update main to call draw-slopegraph with the svg element created by append-svg and the data hash map. This will make sure that our visualization reflectes the changes we make in our code.

(defn draw-slopegraph [svg data])

,,,

(defn ^:export main []
  (let [svg (append-svg)]
    (draw-slopegraph svg data)))

Each column of our slope graph represents a year. The column on the left will display 2005 data, the column on the right will display 2015 data. If you look back at the slopegraph examples in the NPR article, you’ll notice that each text element is positioned vertically based on the associated numeric value. The text element in this case is the hash map key (‘natural-gas’, ‘coal’, etc), and the numeric value is the hash map value (in percent). We’ll use D3.js to position those names correctly for each column.

Create a function called draw-column. draw-column will take a D3.js selection (where the text elements be drawn inside), a year’s worth of data, the column index, and any additional svg attributes. draw-column will do the standard D3.js procedure for creating new elements from data: create a placeholder selection, bind the data, call enter, create new elements (in this case, SVG text elements), then set attributes for those text elements.

(defn draw-column [svg data-col index custom-attrs]
  (-> svg
      (.selectAll (str "text.slopegraph-column-" index))
      (.data (into-array data-col))
      (.enter)
      (.append "text")))

Notice the call to into-array when we pass our data to the .data call. One of the things you’ll find when using JavaScript libraries from ClojureScript is that sometimes you need to turn ClojureScript data structures into plain JavaScript ones. into-array turns a ClojureScript sequence type into a native JavaScript array. I could have also used clj->js, but clj->js recursively turns all ClojureScript values in data into native JavaScript types, which means we can’t use ClojureScript methods on those JavaScript values.

Now modify draw-slopegraph to make sure we’re calling draw-column for each year of data.

(defn draw-slopegraph [svg data]
  (let [data-2005 (get data 2005)
        data-2015 (get data 2015)]
    (draw-column svg data-2005 0 {"x" (* width 0.25)})
    (draw-column svg data-2015 0 {"x" (* width 0.75)})))

We’re setting the x attribute for each column to align them horizontally.

Save your changes, open index.html and inspect the HTML. You won’t see anything on the page, but you’ll see that we just created text SVG elements for each item in data-col.

We need to set the y attribute of those text elements, which will set the vertical position. We’re going to create a helper function that will return a D3 scale function which will help us translate those values into pixel values.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; helpers

(def height-scale
  (-> js/d3
      (.scaleLinear)
      (.domain #js [0 1])
      (.range #js [(- height 15) 0])))

For the display text itself, we want to display the name of the energy source and the percent value. For example, :natural-gas 0.2008611514256557 will be Natural gas 20.08%. Some more helper functions should help us out with that.

Modify the require statement to include clojure.string.

(ns us-energy-slopegraph.core
  (:require [cljsjs.d3]
            [clojure.string :as str]))

Then add these two helpers:

(defn format-percent [value]
  ((.format js/d3 ".2%") value))

(defn format-name [name-str]
  (-> name-str
      (str/replace "-" " ")
      (str/capitalize)))

format-percent uses D3’s formatters to convert the decimal number into a percent string. format-name does some simple string manipulation to clean up the name string. Feel free to try out these two functions using the REPL!

dev:cljs.user=> (us-energy-slopegraph.core/format-name "natural-gas")
"Natural gas"
dev:cljs.user=> (us-energy-slopegraph.core/format-percent 0.19293818293)
"19.29%"

Now let’s set the attributes in the text elements we created in draw-column. Add the attrs function below and modify draw-column.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; helpers

(defn attrs [el m]
  (doseq [[k v] m]
    (.attr el k v)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; draw functions

(defn draw-column [svg data-col index custom-attrs]
  (-> svg
    (.selectAll (str "text.slopegraph-column-" index))
    (.data (into-array data-col))
    (.enter)
    (.append "text")
    (.classed (str "slopegraph-column" index) true)
    (.text (fn [[k v]] (str (format-name (name k)) " " (format-percent v))))
    (attrs (merge custom-attrs
            {"y" (fn [[_ v]] (height-scale v))}))))

The attrs function is a helper function that helps us pass in SVG attributes to a selection using a whole hash map, rather than calling attr for every attribute we want to set without needing to install an external library.

Save your changes and look at index.html again. You should now see text!

We’re still missing the line and the header, but let’s first refactor the code to make drawing those easier. The data join pattern in D3.js is going to be used again and again, so let’s pull out some of that code into a separate function.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; helpers

(defn data-join [parent tag class data]
  (let [join  (-> parent
                  (.selectAll (str tag "." class))
                  (.data (into-array data)))
        enter (-> join
                  (.enter)
                  (.append tag)
                  (.classed class true))]
    (-> join (.exit) (.remove))
    (.merge join enter)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; draw functions

(defn draw-column [svg data-col index custom-attrs]
  (-> svg
      (data-join "text" (str "text.slopegraph-column-" index) data-col)
      (.text (fn [[k v]] (str (format-name (name k)) " " (format-percent v))))
      (attrs (assoc custom-attrs
                    "y" (fn [[_ v]] (height-scale v))))))

With that data-join in place we’re now ready to implement draw-header and draw-line

(def column-1-start (/ width 4))
(def column-space (* 3 (/ width 4)))

(defn draw-header [svg years]
  (-> svg
      (data-join "text" "slopegraph-header" years)
      (.text (fn [data _] (str data)))
      (attrs {"x" (fn [_ index]
                    (+ 50 (* index column-space)))
              "y" 15})))

(defn draw-line [svg data-col-1 data-col-2]
  (-> svg
      (data-join "line" "slopegraph-line" data-col-1)
      (attrs {"x1" (+ 5 column-1-start)
              "x2" (- column-space 5)
              "y1" (fn [[_ v]]
                     (height-scale v))
              "y2" (fn [[k _]]
                     (height-scale (get data-col-2 k)))})))

And call them from draw-slopegraph

(defn draw-slopegraph [svg data]
  (let [data-2005 (get data 2005)
        data-2015 (get data 2015)]

    (draw-column svg data-2005 1 {"x" column-1-start})
    (draw-column svg data-2015 2 {"x" column-space})

    (draw-header svg [2005 2015])
    (draw-line svg data-2005 data-2015)))

Again I’m not going to go into the details of the D3 API, I hope that intuitively you can get a sense of what is going on. The line connecting the two columns together uses a d3 line generator which works a little differently than the text elements we drew.

There are a lot of things we can do to make this visualization more readable. Maybe we can attach mouse handlers so we can highlight one column at a time, like this slopegraph example here? You may want to clone the finished project and try to add that feature yourself using ClojureScript!

Final thoughts

Learning a new language can be an overwhelming task. There’s the pain of learning new syntax and paradigms, then also build tools, editor tools, a decent number of conceptual talks, and a whole lot more. Getting all these thrown in the face can feel like too much work to get started with a language.

Picking up figwheel meant that I could learn Clojure in a responsive environment with a pretty small setup process. I was able to apply my JavaScript knowledge to ClojureScript and start writing small D3.js visualizations to learn the language. From there, I slowly learned about better ways to write my code, picked up new editor and REPL tools, and continued my Clojure education.

If learning Clojure seems overwhelming, a Figwheel project may be right for you!

Additional Clojure Resources

  • If you want to dive straight into Clojure in a graphical environment with zero setup, I also highly suggest Maria.cloud.
  • Figwheel

D3.js resources

More blog posts

Test Wars: A New Hope

Yesterday was the first day for me on a new job, thanks to Clojurists Together I will be able to dedicate the coming three months to improving Kaocha, a next generation test runner for Clojure.

A number of projects applied for grants this quarter, some much more established than Kaocha. Clojurists Together has been asking people through their surveys if it would be cool to also fund “speculative” projects, and it seems people agreed.

I am extremely grateful for this opportunity. I hope to demonstrate in the coming months that Kaocha holds a lot of potential, and to deliver some of that potential in the form of a tool people love to use.

Two Years of Lambda Island, A Healthy Pace and Things to Come

It’s been just over two years since Lambda Island first launched, and just like last year I’d like to give you all an update about what’s been happening, where we are, and where things are going.

To recap: the first year was rough. I’d been self-employed for nearly a decade, but I’d always done stable contracting work, which provided a steady stream of income, and made it easy for me to unplug at the end of the day.

Lambda Island was, as the Dutch expression goes, “a different pair of sleeves”. I really underestimated what switching to a one-man product business in a niche market would mean, and within months I was struggling with symptoms of burnout, so most of year one was characterised by trying to keep things going and stay afloat financially, while looking after myself and trying to get back to a good place, physically and mentally.

Reloading Woes

Setting the Stage

When doing client work I put a lot of emphasis on tooling and workflow. By coaching people on their workflow, and by making sure the tooling is there to support it, a team can become many times more effective and productive.

An important part of that is having a good story for code reloading. Real world projects tend to have many dependencies and a large amount of code, making them slow to boot up, so we want to avoid having to restart the process.

The Bare Minimum, or Making Mayonnaise with Clojure

Making Mayonnaise

Imagine you have a grandfather who’s great at making mayonnaise. He’s been making mayonnaise since before the war, and the result is truly excellent. What’s more, he does this with a good old fashioned whisk. He’s kept his right arm in shape throughout decades just by beating those eggs and oil and vinegar.

Now he’s bought himself a handheld electric mixer after hearing his friend rave about hers, but after a few tries he gives up and goes back to his whisk. He says he just can’t get the same result. This seems slightly odd, so the next time you go over you ask him to show you how he uses the mixer.

Clojure Gotchas: "contains?" and Associative Collections

When learning a programming language we rarely read the reference documentation front to back. Instead someone might follow some tutorials, and look at sample code, until they’re confident enough to start a little project for practice.

From that point on the learning process is largely “just in time”, looking up exactly the things you need to perform the task at hand. As this goes on you might start to recognize some patterns, some internal logic that allows you to “intuit” how one part of the language works, based on experience with another part.

Developing this “intuition” — understanding this internal logic — is key to using a language effectively, but occasionally our intuition will be off. Some things are simply not obvious, unless someone has explained them to us. In this post I will look at something that frequently trips people up, and attempt to explain the underlying reasoning.

Dates in Clojure: Making Sense of the Mess

You can always count on human culture to make programming messy. To find out if a person is a programmer just have them say “encodings” or “timezones” and watch their face.

In Java, and hence Clojure, there are half a dozen different ways to represent dates and times, which can lead to confusion, needless type coercion, and inconsistent code. In this post I’ll give you a quick lay of the land, and some tips to make it all a bit easier to deal with.

Representing Time

Clojure Gotchas: Surrogate Pairs

tl;dr: both Java and JavaScript have trouble dealing with unicode characters from Supplementary Planes, like emoji 😱💣.

Today I started working on the next feature of lambdaisland/uri, URI normalization. I worked test-first, you’ll get to see how that went in the next Lambda Island episode.

One of the design goals for this library is to have 100% parity between Clojure and ClojureScript. Learn once, use anywhere. The code is all written in .cljc files, so it can be treated as either Clojure or ClojureScript. Only where necessary am I using a small amount of reader conditionals.

Simple and Happy; is Clojure dying, and what has Ruby got to do with it?

The past week or so a lot of discussion and introspection has been happening in the Clojure community. Eric Normand responded to my one year Lambda Island post with some reflections on the size and growth of the community.

And then Zack Maril lamented on Twitter: “I’m calling it, clojure’s dying more than it is growing”. This sparked a mega-thread, which was still raging four days later. A parallel discussion thread formed on Reddit. Someone asked if their were any Clojure failure stories. They were pointed at this talk from RubyConf 2016, which seemed to hit a lot of people right in the feels, and sparked a subthread with a life of its own.

Meanwhile Ray, one of the hosts of the defn podcast reacted to the original tweet: “I’m calling it: Clojure is alive and well with excellent defaults for productive and sustainable software development.” This sparked another big thread.

Loading Clojure Libraries Directly From Github

Did you ever fix a bug in an open source library, and then had to wait until the maintainer released an updated version?

It’s happened to me many times, the latest one being Toucan. I had run into a limitation, and found out that there was already an open ticket. It wasn’t a big change so I decided to dive in and address it. Just a little yak shave so I could get on with my life.

Now this pull request needs to be reviewed, and merged, and eventually be released to Clojars, but ain’t nobody got time for that stuff. No sir-ee.

Lambda Island Turns One, The Story of a Rocky Ride

One year ago to date I launched Lambda Island, a service that offers high quality video tutorials on web development with Clojure and ClojureScript. It’s been quite a ride. In this post I want to look back at the past year, provide some insight into how this experience has been for me, and give you a glimpse of what the future has in store.

This story really starts in December 2015. After three years of doing contract work for Ticketsolve I decided it was time for a change. I have been self-employed for many years, but I knew that sooner or later I wanted to try my hand at selling a product, rather than selling my time.

In January and February I took some time for soul-searching, and recharging. I went to speak at RubyConf Australia, and got to hang out with some old friends around Australia and New Zealand. Once back in Berlin I got busy creating Lambda Island.

Writing Node.js scripts with ClojureScript

In the two most recent  Lambda Island episodes I covered in-depth how to create command line utilities based on Lumo, how to combine them with third party libraries, and how to deploy them to npmjs.com.

However there’s a different way to create tools with ClojureScript and distribute them through NPM, without relying on Lumo. In this blog post I want to quickly demostrate how to do just that.

To recap, Lumo is a ClojureScript environment based on Node.js, using bootstrapped (self-hosted) ClojureScript. This means the ClojureScript compiler, which is written in Clojure and runs on the JVM, is used to compile itself to JavaScript. This way the JVM is no longer needed, all you need is a JavaScript runtime to compile and run ClojureScript code, which in this case is provided by Node.js. On top of that Lumo uses nexe, so Lumo can be distributed as a single compact and fast executable binary.

Announcing lambdaisland/uri 1.0.0

I just released lambdaisland/uri, a pure Clojure/ClojureScript URI library. It is available on Github and Clojars.

This is a small piece of the code base that powers lambdaisland.com. It’s inspired by Ruby’s Addressable::URI, the most solid URI implementation I’ve seen to date, although it only offers a small part of the functionality that library offers.

It’s written in pure Clojure/ClojureScript, with only minimal use of .cljc reader conditionals to smooth over differences in regular expression syntax, and differences in core protocols. It does not rely on any URI functionality offered by the host, such as java.net.URL, so it’s usable across all current and future Clojure implementations (Clojure, ClojureScript, ClojureCLR).

re-frame Subscriptions Got Even Better

Up until recently, to use re-frame subscriptions in Reagent views, you had to use a form-2 component.

A form-2 component is a function that returns another function, which does the actual rendering of the component to hiccup. In contrast, a form-1 component renders the hiccup directly.

;; form-1
(defn todo-item [todo]
  [:div.view
   [todo-checkbox (:id todo) (:completed todo)]
   [:label {:unselectable "on"} title]
   [:button.destroy {:on-click #(dispatch [:todos/remove (:id todo)])}]])

;; form-2
(defn todo-item [todo]
  (fn [todo]
    [:div.view
     [todo-checkbox (:id todo) (:completed todo)]
     [:label {:unselectable "on"} title]
     [:button.destroy {:on-click #(dispatch [:todos/remove (:id todo)])}]]))

Game Development with Clojure/ClojureScript

This weekend it’s Ludum Dare again, the world’s longest running game jam. The idea is that, alone or with a team, you build a game in a weekend based on a certain theme.

We got a little team together here in Berlin, and so I’ve been reviewing what options there are for someone wanting to build a game in Clojure or Clojurescript.

The good news is there are plenty of options, as you’ll see from the list below. You can do desktop games, browser based games with canvas or webgl, and you can even create Unity 3D games, all from your comfortable Clojure parentheses.

Union Types with Clojure.Spec

Elm and other statically typed languages have a great feature called Union Types (also called Sum Types or Algebraic Data Types).

Here’s an example taken from Elm. Suppose your system used to represent users as integers, maybe just an auto-incrementing primary key, but then switched to UUIDs represented as strings.

To correctly model this situation, you need a way to create a type that can be either an integer or a string, that’s what union types give you.