core.cljs

(ns react-cljs.core
  (:require React))

(declare render)

(defn handle-change [e]
  (render {:text (.. e -target -value)}))

(defn render [{:keys [text]}]
  (React/renderComponent
    (React/DOM.div nil
      (array
        (React/DOM.h1 nil "Type some stuff in the text box")
        (React/DOM.input
          (js-obj
            "type" "text"
            "value" text
            "onChange" handle-change))
        text))
    js/document.body))

(render {:text ""})

;;  -- Oh the beautiful DSLs that await us! --
;;
;;  (render-component
;;    (div nil
;;      [(h1 nil "type some stuff here")
;;       (input :type "text" :value text :change handle-change)
;;       text])
;;    js/document.body)

project.clj

(defproject react-cljs "0.1.0-SNAPSHOT"
  :description "FIXME: write this!"
  :url "http://example.com/FIXME"

  :dependencies [[org.clojure/clojure "1.5.1"]
                 [org.clojure/clojurescript "0.0-2080"]
                 [reactjs "0.5.1"]]

  :plugins [[lein-cljsbuild "1.0.0"]]

  :source-paths ["src"]

  :cljsbuild { 
    :builds [{:id "dev"
              :source-paths ["src"]
              :compiler {
                :output-to "main.js"
                :output-dir "out"
                :optimizations :none
                :source-map true
                :foreign-libs [{:file "reactjs/react.js"
                                :provides ["React"]}]
                :externs ["reactjs/externs/react.js"]}}]})

Is it possible to protocolize the component api somehow?

It might be nice to define types/records and have them end up with the render function, without having to manually modify their prototype.

@rads I won't speak for @piranha but one advantage I can think of is that there is no intermediate parsing step. With the macro this isn't as much of an issue (since the expanded macro code will be emitted at compile time). However, there are the typical disadvantages of macros, such as composability, and, in the case of this particular one, there are a variety of things you must do to get this to work properly (see here).

So it looks like React is quite useful even w/o the magic props and state machinery. https://gist.github.com/swannodette/7782780, looks a lot like WebFUI to me. Seems like we could do a more idiomatic version of the props and state functionality w/o much hassle?

@noprompt @rads that's right, main reason for functions instead of hiccup-like data structures is performance. IIRC transformation step takes around 20-30% of runtime of a whole application, which is just an overhead and could be fixed quite easily.

@swannodette well state is really not needed with CLJS, local atoms could be used, but I still think that creating React components makes sense since React has some optimisations related to components update. For example, if your props didn't change, there is no need to call render, which you will call anyway if you're going with a simple function like render-counter.

Though it would be interesting to see how would you scale code you wrote into something bigger. :) TBH most components could be represented as just a function (render), but sometimes you need a bit more: sometimes it's local state - that's possible with closures, I guess, but then when you need to integrate with external libraries you will need componentDidMount and componentWillUnmount at least.

I wonder if Github should notify me somehow when I got mentioned here, since it does not right now and that's frustrating.

@piranha are there many external React libraries? Or do you mean that components created in ClojureScript will need componentDidMount, componentWillUnmount in order to be used by others? To be honest this seems unlikely given ClojureScript's whole program compilation model.

Interesting point about props, I didn't realize this was compared - do you have a link to the documentation and/or source about this optimization?

@swannodette by "external libraries" I mean absolutely separate external libraries, i.e. jQuery, various date pickers and calendars, d3 and so on.

Regarding optimizations, something like that.

Is there a way to suppress the warnings of React.js? I'm getting 268 warnings about JSDoc tags. I can't find the real warnings about my code (like undefined variables).

@ericnormand, this is fixed in master, your release build should look something like this to suppress warnings:

{:id "release"
 :source-paths ["src"]
 :compiler
 {:output-to "main.js"
  :optimizations :advanced
  :pretty-print false
  :foreign-libs [{:file "reactjs/react.js"
                  :provides ["React"]}]
  :externs ["reactjs/externs/react.js"]
  :closure-warnings {:non-standard-jsdoc :off}}}

After chatting with the React devs some more, there are definitely some improvements to my approach in the counter Gist, will keep exploring and post updates when I discover something new.

@swannodette, in case you weren't aware, Conrad Barski (webfui) has made a few comments on the React mailing list: https://groups.google.com/forum/#!topic/reactjs/e3bYersyd64

Hi I see that you use React, so I am sure that you will find interesting the https://reactjs.co - this is the free online convention and tutorial book for React.JS Developers. React is not only the View (in MVC) anymore. ReactJS For Dummies: Why & How to Learn React Redux, the Right Way.