I have been enjoying the combination of writing Clojurescript clients with server side Clojure + Compojure. However, I have run across a few pain points and use a few simple little hacks to make things easier. My little hacks may be far from “best practice”:

Forget about JSON, just serialize Clojure data. This seems strange since JSON is nice to use and cross platform, but when talking Clojure to Clojure, I find it easier to use pr-str to print Clojure data to a string and in Clojurescript to read it using:

(ns myfocus.client
  (:use-macros [crate.def-macros :only [defpartial]])
  (:require [goog.net.XhrIo :as xhr]
            [goog.object :as gobj]
            [goog.events.KeyHandler :as key-handler]
            [goog.events :as gevents]
            [goog.dom :as dom]
            [domina :as d]
            [domina.events :as events]
            [dommy.template :as template]
            [cljs.reader :as reader])) 

(defn str-to-clojure-data [s]
  (let [data (reader/read-string s)]
    ....))

and on the server side in Clojure (there may be security issues with this):

  (let [data (read-string s)
    ...

EDIT: Lucian and Bernard pointed out that I should have used clojure.edn/read-string instead of cljs.reader.read-string to avoid a security hole.

Handle authentication with an anonymous unique user ID and add this to all calls to the server. The first time a user hits an app, generate a unique and anonymous ID for them; on the server side:

(ns myfocus.server
  (:require [compojure.route :as route]
            [compojure.core :as compojure]
            [ring.util.response :as response]
            [ring.adapter.jetty :as jetty]
            clojure.pprint)
  (:use [ring.middleware.cookies :only [wrap-cookies]]
        [ring.middleware.params :only [wrap-params]]
        [ring.middleware.keyword-params :only [wrap-keyword-params]])
  (:use myfocus.utils)
  (:use myfocus.db)
  (:gen-class :main true))

(def cookie-name "magic-cookie-name")

(defn check-auth [request]
  (let [id (:value ((:cookies request) cookie-name))
   id2 (or id (str (java.util.UUID/randomUUID)))]
    id2))

I will use this check-auth function both when the user first loads the page and the user’s auth ID and data is sent to the client when I return a very small HTML file with the route

(route/resources "/")

and also later to verify that client requests are valid. The first thing that the Clojurescript (compiled to Javascript) does on page load is to request the user’s data that I process on the server side with a route like this:

  (compojure/GET "/edn" request
       (let [id (check-auth request)
             data (all-data-for-user id)]
             {:cookies {cookie-name id}
              :body (pr-str data)}))

I ended up forgetting about the proper semantics of REST verbs and always used GET requests, reusing the same functions for different types of requests. I pass a user’s auth ID with every call to the server.

I store the user’s auth ID, user data and dirty data identifiers in the browser using something like:

(def user-data (atom []))
(def dirty-data-names (atom #{}))
(def user-auth (atom ""))

All application data lives in the browser and I send diffs back to the server as data changes. I am writing a one page application and I use a few forms with no action like this on a single HTML page:

<form id="menu-form" class="menu_form" action="javascript:void(0);">
   <input id="recent-button" type="button" value="Recent"/>
   ...

I set event handlers for this input button (and all other controls) in a main function on the client:

(defn ^:export main [] ;;    main static initialization:
  (let [document (dom/getDocument)
        handler (goog.events.KeyHandler. document true)
        timer (goog.Timer. 2000)]  ;; 2 seconds
    (fetch-user-data)
    (when (not (.-enabled timer))
      (. timer (start)))
    (gevents/listen handler "key"
      (fn [evt]
        (let [id (.-id (.-target evt))]
          ...)))
    (gevents/listen timer goog.Timer/TICK flush-dirty-foci-to-server)
    (events/listen!
      (d/by-id "recent-button")
      :click (fn [event]
               (update-menu-focus-list sort-by-most-recent)
               (d/set-styles! (d/by-id "recent-button") {:background-color "darkgrey"})
               (d/set-styles! (d/by-id "important-button") {:background-color "white"})
               (d/set-styles! (d/by-id "archived-button") {:background-color "white"})))
    ...))

I generate new HTML for elements on the page when a user has to edit data, and discard the newly generated HTML when it is not needed.

While it at first seems tedious handling every event on the client and all communication with the server I (eventually) found that it just requires a set of small utility functions for communication, creating HTML DOM elements, and modifying and destroying DOM elements. Once the low level stuff is written then the main client side application logic is fairly easy to write. Because I have a lot of code reuse the client side code is fairly concise even though I have to handle low level details.

I have two apps I am working on (one simple and one moderately complicated) and after a learning curve I now have a better understanding of writing client side apps in Clojurescript.

I wrote several days ago about going a little crazy evaluating both rich client web stacks I have used in the past and new ones. I decided to use Clojurescript for the rich client and Clojure + Compojure on the server side.

My Clojurescript setup is fairly simple: I use a small HTML stub to load dependent CSS, Javascript libraries, and my Clojurescript code (with all dependencies) compiled into a single Javascript file that is also loaded in my HTML stub. So far, I am just using the domina (a HTML DOM manipulation library) and jayq (a wrapper for jQuery) libraries. On the server side the only libraries I am using are compojure and ring. The server side code loads the HTML stub, deals with cookies and auth, and provides REST services.

My development setup is working well for me. I use three zsh windows open running ‘lein run,’ ‘lein cljsbuild auto,’ and ‘lein repl.’ I edit all code, HTML, and CSS in IntelliJ. I run the web app in Chrome with the Developers Tools panel always open. This setup provides a really good view into all the pieces of code during development.