mfikes

git clone https://github.com/clojure/clojurescript
cd clojurescript
script/bootstrap
script/test

Ctrl-C when it logs

Applying optimizations :advanced to 344 sources

mhuebert

material-ui allows for customizing CSS via a higher-order component called withStyles. Like many higher-order components which expect render props, the purpose of withStyles is to accept some parameters, and then introduce a new variable into the scope of the component tree.

One succinct and simple way to translate the concept of scope into Clojure is via a custom let macro. Usage of such a macro is demonstrated here:

(:require [material-ui.styles :as m])

(m/let [{:keys [leftPad]} {:leftPad 
                           {:paddingLeft 8}}]
 ;; `leftPad` is now the _className_ associated with {:paddingLeft 8} 

athos

{:paths ["."]
 :deps {clansi/clansi {:mvn/version "1.0.0"}}}

iperdomo

;; https://developers.google.com/maps/documentation/javascript/examples/delete-vertex-menu

;; New implementaion based on comments by Andre Rauh (@rauh) in #clojurescript on clojurians.slack.com
;; 


(defn delete-vertex-menu
  [label]
  (this-as this

levand

Since it has come up a few times, I thought I’d write up some of the basic ideas around domain modeling in Clojure, and how they relate to keyword names and Specs. Firmly grasping these concepts will help us all write code that is simpler, cleaner, and easier to understand.

Clojure is a data-oriented language: we’re all familiar with maps, vectors, sets, keywords, etc. However, while data is good, not all data is equally good. It’s still possible to write “bad” data in Clojure.

“Good” data is well defined and easy to read; there is never any ambiguity about what a given data structure represents. Messy data has inconsistent structure, and overloaded keys that can mean different things in different contexts. Good data represents domain entities and a logical model; bad data represents whatever was convenient for the programmer at a given moment. Good data stands on its own, and can be reasoned about without any other knowledge of the codebase; bad data is deeply and tightly coupled to specific generating and

gdeer81

(ns spec-test.core
  (:require [clojure.spec :as s]))

(defn x-integer? [x]
  (if (integer? x)
    x
    (if (string? x)
      (try
        (Integer/parseInt x)
        (catch Exception e

halgari

The question was asked why I (as a programmer who prefers dynamic languages) don't consider static types "worth it". Here
is a short list of what I would need from a type system for it to be truely useful to me: 

1) Full type inference. I would really prefer to be able to write: 

(defn concat-names [person]
  (assoc person :full-name (str (:first-name person)
                                (:second-name person))))

And have the compiler know that whatever type required and produced from this function was acceptible as long as the 

zehnpaard

(ns figwheel-garden.core
  (:require
    [reagent.core :as r]))

(defn my-app []
  [:div
   [:h1 "Hello Reagent!"]
   [:p "Hello Garden!"]
   [:p.my-class "Hello My-Class!"]])

Deraen

(ns spec-test.core
  (:require [clojure.spec :as s]))

(defn x-integer? [x]
  (if (integer? x)
    x
    (if (string? x)
      (try
        (integer/parseint x)
        (catch exception e

seantempesta

(ns mattsum.simple-example.core
  (:require-macros [natal-shell.core :refer [with-error-view]]
                   [natal-shell.components :refer [view text image touchable-highlight]]
                   [natal-shell.alert :refer [alert]])
  (:require [om.next :as om :refer-macros [defui]]))

(set! js/React (js/require "react-native/Libraries/react-native/react-native.js"))

(def app-registry
  (.-AppRegistry js/React))