ANN: Om, a ClojureScript binding to Facebook's React

[David Nolen]

Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/

David

[Mimmo Cosenza]

Wow. It's a true Christmas present.

Thanks David

Mimmo

Inviato da iPad

Scusate gli errori d'ortografia

On 19/dic/2013, at 20:12, David Nolen <dnolen...@gmail.com> wrote:

Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/

David

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[Thomas Heller]

Hey David,

looks really interesting although I have to be a little critical of your benchmarks. Add a download of 200 todos via xhr and then do the render, you will most certainly lose to other JS Framework out there (especially if you choose EDN over JSON) cause of the extra overhead associated with going from mutable->persistent. I quite like react/om and will certainly play with it although I have some worries concerning deeply nested data, since Clojure isn't exactly performant in that situation. Happy to be proven wrong though.

Anyways, nice work. Curious to see/hear more.

Cheers,

/thomas

PS: Found a Bug: add 2 items, delete the first, double click the last remaining. 

[David Nolen]

On Thu, Dec 19, 2013 at 4:25 PM, Thomas Heller <th.h...@gmail.com> wrote:

Hey David,

looks really interesting although I have to be a little critical of your benchmarks. Add a download of 200 todos via xhr and then do the render, you will most certainly lose to other JS Framework out there (especially if you choose EDN over JSON) cause of the extra overhead associated with going from mutable->persistent.

Absolutely not. The benchmarks include serialization to localStorage, it doesn't add significantly to the time. Deserializing EDN would be completely dwarfed by network transport and DOM changes.

Of course, the CLJS reader needs some work, but I think with further tuning, it will be highly unlikely to be the bottleneck.

 

I quite like react/om and will certainly play with it although I have some worries concerning deeply nested data, since Clojure isn't exactly performant in that situation. Happy to be proven wrong though.

Anyways, nice work. Curious to see/hear more.

I ran some simple nested data benchmarks - all the time is spent ... in React.

I think if people think a bit more about how Om works, you will see that it's an optimal design and highly unlikely for traditional approaches to be able to compete.

David 

[Luke Morton]

Excellent and insightful post David. Thanks for much for your work in Clojure and ClojureScript. Going to be playing with Om as part of my exploration of Clojure(Script).

--

[David Nolen]

Give it a spin. It's very much early days so I wouldn't get too tied to anything that's currently present. It'll probably take a few months to get something closer to a real API nailed down but the conceptual foundation is there.

[Haim Ashkenazi]

Hi David,

I was wondering (ever since I saw a tweet of yours couple of days ago). Is it named after this? Just curious.

Thanks

On Thu, Dec 19, 2013 at 9:12 PM, David Nolen <dnolen...@gmail.com> wrote:

Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/

David

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

--

Haim

[David Nolen]

Haha, why not?

Nah, the name comes from the fact that we always start from the beginning, and that DOM minus D is OM.

I didn't put that much thought into it honestly :)

David

[Dan Holmsand]

Nice, React seems to be very popular around here today...

Very interesting to see such a different take on a React interface from my own humble attempt. I try to keep components as self contained as possible, where as you seem to like more of a top-down approach (if I understand your code correctly). I prefer to describe the output in plain ClojureScript data (and only convert to React components when necessary), where you call React directly with JS objects.

You also seem to call React asynchronously. That may be good for performance, but doesn't makes testing awfully cumbersome? Why not rely on React's own batching?

I tried to replicate your benchmark here (not sure I got it quite right), and results in the same ballpark (around 10ms for your "benchmark 2"):

https://github.com/holmsand/cloact/blob/benchmark/examples/todomvc/src/todomvc.cljs

Thanks for a good read. React is really cool (and ClojureScript even cooler...).

/dan

[David Nolen]

On Thu, Dec 19, 2013 at 5:02 PM, Dan Holmsand <holm...@gmail.com> wrote:

You also seem to call React asynchronously. That may be good for performance, but doesn't makes testing awfully cumbersome? Why not rely on React's own batching?

React's batching depends on setState, which I don't want to get involved in for many reasons. As far as testing, we could supply a flag to disable it.

 

I tried to replicate your benchmark here (not sure I got it quite right), and results in the same ballpark (around 10ms for your "benchmark 2"):

https://github.com/holmsand/cloact/blob/benchmark/examples/todomvc/src/todomvc.cljs

Thanks for a good read. React is really cool (and ClojureScript even cooler...).

/dan

Yes you're likely able to leverage batching on setState.

I think your design is perfectly valid but it's not one I'm particularly interested in investigating at the moment. I think treating the UI purely as EDN simplifies Om's implementation significantly and I have some other ideas like Datomic style Datalog queries to compute children in the works that will be simpler to implement with the Om design.

David

[Dan Holmsand]

On 19 dec 2013, at 23:10, David Nolen <dnolen...@gmail.com> wrote:

On Thu, Dec 19, 2013 at 5:02 PM, Dan Holmsand <holm...@gmail.com> wrote:

You also seem to call React asynchronously. That may be good for performance, but doesn't makes testing awfully cumbersome? Why not rely on React's own batching?

React's batching depends on setState, which I don't want to get involved in for many reasons. As far as testing, we could supply a flag to disable it.

Actually, you don't have to use setState: you get batching from forceUpdate as well (which is what I used in the benchmark).

 

I tried to replicate your benchmark here (not sure I got it quite right), and results in the same ballpark (around 10ms for your "benchmark 2"):

https://github.com/holmsand/cloact/blob/benchmark/examples/todomvc/src/todomvc.cljs

Thanks for a good read. React is really cool (and ClojureScript even cooler...).

/dan

Yes you're likely able to leverage batching on setState.

I think your design is perfectly valid but it's not one I'm particularly interested in investigating at the moment. I think treating the UI purely as EDN simplifies Om's implementation significantly and I have some other ideas like Datomic style Datalog queries to compute children in the works that will be simpler to implement with the Om design.

David

--
Note that posts from new members are moderated - please be patient with your first post.
---

You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/4wFYpXRGbqw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

[Samuel Aaron]

Hey David,

this looks fab. I'm trying to play with it within a stub project of mine. However, I'm not having much success getting it to compile. This is likely to be some cljs setup issue I'm having (there are so many moving parts!).

Steps taken:

* Download, and build latest cljs (0.0-2127)
* Clone om and link to it from within my cljs-src directory
* Modify project.clj file to look similar to yours
* Run `lein cljsbuild auto` and see the following error:

λ lein cljsbuild once
Compiling ClojureScript.
java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541)
at clojure.java.io$fn__8551$G__8546__8558.invoke(io.clj:73)
at clojure.java.io$reader.doInvoke(io.clj:106)
at clojure.lang.RestFn.invoke(RestFn.java:410)
at clojure.lang.AFn.applyToHelper(AFn.java:161)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.core$apply.invoke(core.clj:619)

My project.clj is as follows:

(defproject overtext "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url "http://example.com/FIXME"
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
:dependencies [[org.clojure/clojure "1.5.1"]
[http-kit "2.1.13"]
[org.clojure/clojurescript "0.0-2127"]]
:plugins [[lein-cljsbuild "1.0.1"]]
:source-paths ["cljs-src" ]
:profiles {:dev {:plugins [[com.cemerick/austin "0.1.3"]]}}
:cljsbuild {
:builds [{:id "dev"
:source-paths ["cljs-src"]
:compiler {
:output-to "resources/web/js/cljs-main.js"

:optimizations :none
:externs ["cljs-src/om/externs/react.js"]}}]})


My project directory structure is:

∴ /Users/sam/scratch/overtext
λ tree .
.
├── LICENSE
├── README.md
├── cljs-src
│ ├── om -> /Users/sam/Development/cljs/om/src/om
│ └── overtext
│ ├── onload.cljs
│ └── ws.cljs
├── doc
│ └── intro.md
├── pom.xml
├── project.clj
├── resources
│ └── web
│ └── static
│ ├── index.html
│ └── js
│ └── cljs-main.js
├── src
│ └── overtext
│ └── core.clj
└── test
└── overtext
└── core_test.clj

12 directories, 11 files


Am I doing anything obviously foolish?

Sam

---
http://sam.aaron.name

On 19 Dec 2013, at 19:12, David Nolen <dnolen...@gmail.com> wrote:

> Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/
>

> David
>
> --
> Note that posts from new members are moderated - please be patient with your first post.
> ---

> You received this message because you are subscribed to the Google Groups "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.

[David Nolen]

Your externs path is wrong. It should be the same as the instructions in the README.

David

[Samuel Aaron]

On 20 Dec 2013, at 13:07, David Nolen <dnolen...@gmail.com> wrote:

> Your externs path is wrong. It should be the same as the instructions in the README.

I started with it matching the README, but got (and still get) the same error. Seems to be a Clojure problem - perhaps Clojure can't find the om .clj files in my project structure? I'm symlinking your src/om directory, but perhaps I'm missing some sort of config.

Sam

---
http://sam.aaron.name

[David Nolen]

I also don't see Om in your list of dependencies.

David

[Samuel Aaron]

On 20 Dec 2013, at 16:12, David Nolen <dnolen...@gmail.com> wrote:

> I also don't see Om in your list of dependencies.

I also started with that in my dependencies, but it doesn't seem to be available on Clojars etc:

λ lein cljsbuild once
Compiling ClojureScript.

Could not find artifact om:om:jar:0.1.0-SNAPSHOT in clojars (https://clojars.org/repo/)
This could be due to a typo in :dependencies or network issues.

This is why I cloned the om repo directly and symlinked it in. Is there a more appropriate method for manually pulling in cljs projects?

Sam

---
http://sam.aaron.name

[Vijay Kiran]

If you cloned the repo - using lein install should make the snapshot available via dependencies.

[Daniel Bell]

Sam---What I did was, from the cloned git repo, run 'lein install,' which installs the current project to your local repository. When lein sees Om in your dependencies, it will look in the local repo as well as clojars, find it, and all is well.

[Samuel Aaron]

On 20 Dec 2013, at 16:38, Daniel Bell <dchrist...@gmail.com> wrote:

> Sam---What I did was, from the cloned git repo, run 'lein install,' which installs the current project to your local repository. When lein sees Om in your dependencies, it will look in the local repo as well as clojars, find it, and all is well.

Interesting. It doesn't seem to have that behaviour on my system, it just seems to generate a jar file in the target dir:

∴ /Users/sam/Development/cljs/om
λ lein install
Created /Users/sam/Development/cljs/om/target/om-0.1.0-SNAPSHOT.jar
Wrote /Users/sam/Development/cljs/om/pom.xml

Regardless, the contents of om-0.1.0-SNAPSHOT.jar is the contents of the src/ dir within lm's root. This is what I'm symlinking from my project's root/cljs-src directory which is explicitly added to the project.clj :source-paths vector, so it should be visible on the JVM class path...

To be honest though, I'm just fumbling around blindly here. Reading http://lukevanderhart.com/2011/09/30/using-javascript-and-clojurescript.html shed some light on the :externs key, but I'm still struggling.

Sam

---
http://sam.aaron.name

[David Nolen]

The Om README is explicit that you need to install Om from the repo with "lein install". ClojureScript 0.0-2127 just got released so you can use that. 

Sam

---
http://sam.aaron.name

[Samuel Aaron]

On 20 Dec 2013, at 16:35, Vijay Kiran <ma...@vijaykiran.com> wrote:

>
> If you cloned the repo - using lein install should make the snapshot available via dependencies.

Ah ok, `lein install` did add om to my ~/.m2, it just didn't tell me it was doing it :-)

OK, so that seems to get things working - I can now compile a .cljs file that requires om without any compile errors.

I think I get why I was seeing the issues before. As I had symlinked om from my cljs-src directory which is part of the path that cljsbuild is scanning for .cljs files to compile, cljsbuild was trying to compile the .cljs files within om seemingly when some dependencies weren't available.

I also figured out that I don't need to `lein install` om into my ~/.m2 directory, I can just symlink it from my standard Clojure src directory - provided that directory isn't on the list of dirs for cljsbuild to scan. I think I prefer this approach as it means that any updates that David pushes to om are just a `git pull` away, and I don't need to build any intermediate jar files and put them in my ~/.m2 directory for the changes to be available in my project.

Thanks to everyone for all their help and patience with me. It must be frustrating to try and help someone so clearly in the dark :-)

Sam


---
http://sam.aaron.name

[Luke Morton]

You should probably just use `lein install` like everyone else no?

`git pull && lein install`

[Tim Visher]

On Fri, Dec 20, 2013 at 12:43 PM, Luke Morton <lukemor...@gmail.com> wrote:
> You should probably just use `lein install` like everyone else no?
>
> `git pull && lein install`

Biggest problem with this is that you only get updates every 24 hours
without further monkey business in the case of SNAPSHOT dependencies.

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

[Samuel Aaron]

On 20 Dec 2013, at 17:43, Luke Morton <lukemor...@gmail.com> wrote:

> You should probably just use `lein install` like everyone else no?
>
> `git pull && lein install`

When I work on other projects that depend on fast moving targets, I've definitely benefitted from symlinking them (traditionally with lein's checkouts feature). This allows me to easily play with the source of the dependencies without having to go through all the mvm machinery.

Is anyone aware of any specific reason(s) why symlinking om is a bad move?

Sam

---
http://sam.aaron.name

[Tim Visher]

Transitive dependencies?

[Samuel Aaron]

On 20 Dec 2013, at 18:07, Tim Visher <tim.v...@gmail.com> wrote:

>> Is anyone aware of any specific reason(s) why symlinking om is a bad move?
>
> Transitive dependencies?

Ah, excellent point, although Om currently only depends on cljs and clj.

Sam

---
http://sam.aaron.name

[David Nolen]

Currently React is included, this is likely to change and I will put React into it's own jar.

[David Powell]

You say you are symlinking the clj-src directory?

lein checkouts works by you symlinking

/projects/myproject/checkouts/om => /projects/om

[Samuel Aaron]

Yep, given that Om is a standard Clojure jar, checkouts should work just fine. I was using a symlink in the src directory - putting om into clj-src generated the errors described previously.

Sam

---
http://sam.aaron.name

[Moritz Ulrich]

David Nolen writes:

> Enjoy,
> http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/
>
> David

Fantastic work! Om is (even in it's current state) really accessible and
easy to use. The TodoMVC implementation you mentioned in the Readme is a
really nice help when following the React tutorial.

I really look forward to using this library for some private and
(hopefully) work-related projects in the future.


Cheers!

--
Moritz Ulrich

[Tom Henderson]

I've been hoping that Om might let me technology-leapfrog the MVC
framework. That mollyrocket 'Immediate Mode GUI' talk made a lot of
sense -- I've been looking over React/Om to try and see the
equivalents for the "hot" and "active" and "user interaction state"
concepts.

[Conrad Barski]

Two quick questions as I am working through the OM stuff... glad if anyone here has some pointers to point me in the right directions...

1. I seem to be unable to get "lein trampoline cljsbuild repl-listen" to serve up a css file on my own Om project... I have my css located at "[project root]/css/main.css" and then reference it in the html as <link rel="stylesheet" href="css/main.css"> but this just throws a 404 error for main.css when I run my program. I've tried many other variations but nothing seems to work. Javascript, html, and sourcemaps work fine. Anyone have an idea of what I'm doing wrong? How does repl-listen decide where the css lives?

2. In the Om TodoMVC app in the function "handle-new-todo-keydown" there is one ugly line of code that reads:
(set! (.-value new-field) "")

Anyone figure out yet why such a DOM manipulation was necessary in that case?

[David Nolen]

Don't know about 1. 2 is actually being sorted out, we're determining the best approach according to the core React devs given our slightly unusual usage of React.

[Daniel Bell]

[Daniel Bell]

Conrad---

Is there a typo or something? AFAIK, repl-listen doesn't have anything to do with serving up files (are you thinking of Ring?), but with providing a bridge for a REPL to execute cljs in the browser.

[Conrad Barski]

Hi Daniel- someone doctored up repl-listen to do double duty as a Dev server for clojurescript files. This is needed because a standard web server can't follow all the app dependencies to find the cljs files and source map files necessary for the fancy new source mapping stuff. If you follow the last few posts on David's blog it goes through this.

[David Nolen]

Conrad,

That's old bug / hack. Your web server can serve the generated source maps now just fine. The easiest thing to do is use :optimizations :none and we generate source maps for each compiled file.

David

On Sun, Dec 22, 2013 at 1:30 PM, Conrad Barski <drc...@gmail.com> wrote:

Hi Daniel- someone doctored up repl-listen to do double duty as a Dev server for clojurescript files. This is needed because a standard web server can't follow all the app dependencies to find the cljs files and source map files necessary for the fancy new source mapping stuff. If you follow the last few posts on David's blog it goes through this.

[Daniel Bell]

On Sunday, December 22, 2013 11:30:12 AM UTC-7, Conrad Barski wrote:
> Hi Daniel- someone doctored up repl-listen to do double duty as a Dev server for clojurescript files. This is needed because a standard web server can't follow all the app dependencies to find the cljs files and source map files necessary for the fancy new source mapping stuff. If you follow the last few posts on David's blog it goes through this.

Egg on my face. Thanks.

[David Nolen]

I've marked my blog post on source maps as outdated - accurate information on source maps and integrating them into your development web server setup can be found here - https://github.com/clojure/clojurescript/wiki/Source-maps

David

[Nikita Prokopov]

Hi David,

cool work,

Just wondering, why in todomvc you rely so heavily onto #js literals, and prefer dsl-like syntax (dom/...) instead of some declarative markup like hiccup? Is it because of performance reasons?

Thanks!

[Conrad Barski]

I'm not David, but I'm guessing "performance reasons" is the answer. The React library relies on member functions to render html (React.DOM.div, React.DOM.input, etc) so this maps more efficiently onto a macro-based html rendering solution, as opposed to one based purely on EDN (like hiccup). Note that the approach used by Om is common in the Common Lisp & Scheme worlds (since those languages don't have clean map & vector literals like Clojure, the hiccup approach is more awkward in those languages.)

The #js literals can forwarded directly to the React.js library and are therefore also very efficient.

[Conrad Barski]

(Should have written "DSL-based" not "macro-based"

[David Pidcock]

On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote:
> Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/
>
>
>
> David

I've been playing around with some basics. I'm still a relative n00b when it comes to functional programming, and I've never looked at React before.

Very cool stuff.

I managed to get Om+React to display a list of items that are sorted by a given key, and I have a content-editable span which updates the state of the owner with new value of that key for a given item, and voila! the list item moves to the correct position. (as expected)

Now here's the tricky part...
I want to implement a drag-list, where I can drag-drop items into a new position, and update the key based on the new position. I have that algorithm working in a different project (using goog.DragListGroup) , but React does not like you to manipulate the DOM outside it's knowledge.

I found this :
https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ

which lead to
http://jsfiddle.net/LQxy7/

Unfortunately, I can't get this to work with Om. I am having trouble navigating the data structures.

How are "props" created/accessed? I followed the TodoMVC example, but that seems to be using "state", which I am given to understand should be kept as high in the hierarchy as possible (per the React recommendations). I tried something like (:value (om/get-props this)) from within IRender, but that doesn't work. Also : (om/get-props this [:items] ) (following the idiom established by get-state.

I'm probably missing something obvious, so I thought I'd pop in here to see if there's someone who can point me in the right direction.

[David Nolen]

From a React dev:

https://www.khanacademy.org/preview/content/items/xfa03b103

https://github.com/Khan/perseus/blob/master/src/widgets/orderer.jsx#L6-L439

I'm sure this can be adapted for Om. I may write up a simpler Om example in the future.

David

--

--
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com

Note that posts from new members are moderated - please be patient with your first post.

To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

---

You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[David Pidcock]

Very nice. Relatively easy to follow.  Basically it's re-implementing the drag-list behaviour  in React.  I had thought to re-use some existing code, provided I could inform React that the DOM was changing. (This is the approach used by the example in the fiddler, albeit with jquery instead of goog.closure as the UI manipulation library)

I'm very interested to see what you do with this, in Om.

This example is complex enough that following along would most likely fill in the conceptual gaps for me, that the TODO example lacks.

Again - inspiring work.. 

-- David

[Dave Dixon]

Trying to build an om example. "lein cljsbuild once hello" throws java.lang.IllegalArgumentException: Duplicate key: org.clojure/clojure. Am I missing something? The todo example builds fine. Thanks.

Dave

[David Nolen]

Sounds like a problem in your project.clj.

On Fri, Jan 3, 2014 at 11:22 AM, Dave Dixon <dave.d...@gmail.com> wrote:

Trying to build an om example. "lein cljsbuild once hello" throws java.lang.IllegalArgumentException: Duplicate key: org.clojure/clojure. Am I missing something? The todo example builds fine. Thanks.

Dave

--

Note that posts from new members are moderated - please be patient with your first post.

---

[Dave Dixon]

Project file is unchanged from Github.

[David Nolen]

Then need more information., need a link to a minimal project where you're experiencing this problem.

[Dave Dixon]

On Friday, January 3, 2014 9:11:34 AM UTC-8, David Nolen wrote:
> Then need more information., need a link to a minimal project where you're experiencing this problem.

Sorry, I wasn't clear. I'm building directly from om, i.e. https://github.com/swannodette/om/blob/master/project.clj.

[Dave Dixon]

On Friday, January 3, 2014 9:11:34 AM UTC-8, David Nolen wrote:
> Then need more information., need a link to a minimal project where you're experiencing this problem.

I think this is a local lein problem, not something specific to the om project. Just created an empty project using "lein new mies", tried to build and got the same error. I'll try clearing out my local repo, please let me know if there are any other suggestions. Thanks.

Dave

[David Nolen]

Yeah I cannot reproduce this.

Dave

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.

[Dave Dixon]

On Friday, January 3, 2014 9:25:49 AM UTC-8, David Nolen wrote:
> Yeah I cannot reproduce this.

Updating to the latest version of lein fixed the problem. Om/React is very cool, looking forward to having some fun with it.

[David Pidcock]

Ha! Just saw your Sortable example popup in Git!

Very cool.

[Curtis Gagliardi]

I watched a few talks from facebook people about React and was impressed, lots of talk about the simplicity of just rerendering everything and pure functions.  I think this is the first time I've been excited about a javascript framework, looking forward to trying it out with Om. 

[David Nolen]

The sortable example in the repo is now relatively baked. I'm happy to see React can handle interactive UIs so well.

[Rick Walsh]

Hi Guys,

So... I'm trying to compile a cljs project with OM.

As in instructed above I've:

cloned the repo:

git clone https://github.com/swannodette/om.git

Installed:

lein install

(Output shown below)

Retrieving org/clojure/clojurescript/0.0-2138/clojurescript-0.0-2138.pom from central
Retrieving org/clojure/core.async/0.1.267.0-0d7780-alpha/core.async-0.1.267.0-0d7780-alpha.pom from central
Retrieving com/facebook/react/0.8.0.1/react-0.8.0.1.pom from clojars
Retrieving org/clojure/core.async/0.1.267.0-0d7780-alpha/core.async-0.1.267.0-0d7780-alpha.jar from central
Retrieving org/clojure/clojurescript/0.0-2138/clojurescript-0.0-2138.jar from central
Retrieving com/facebook/react/0.8.0.1/react-0.8.0.1.jar from clojars
Created G:\om\target\om-0.1.6-SNAPSHOT.jar

I then added to my projects cljs a dependency of [om "0.1.6"]

I still get the following error on compilation:

Could not find artifact om:om:jar:0.1.6 in central (http://repo1.maven.org/maven2/)
Could not find artifact om:om:jar:0.1.6 in clojars (https://clojars.org/repo/)

I'm clearly being terribly stupid.

Any suggestions?

[David Nolen]

If you install locally you need to depend on 

[om "0.1.6-SNAPSHOT"]

I did make a mistake and accidentally did not push the previous version to Clojars which you can depend on as specified in the README:

[om "0.1.5"]

--

Note that posts from new members are moderated - please be patient with your first post.

[Alexander Semenov]

Hi, David.

May I ask you - in Om you queue rendering in requestAnimationFrame by passing a function which calls forceUpdate on the affected components. But as I understand forceUpdate does not guarantee to execute immediately and is also queued. So, the rendering should be out of sync with requestAnimationFrame.

Am I misunderstanding something? Can you help to get this, please?

Regards,
Alex.

[Alexander Semenov]

Found this https://groups.google.com/forum/#!topic/reactjs/LkTihnf6Ey8

"React, by default, only batches it's own events because we need an efficient way of knowing the boundaries of an event loop. You can see this by trigger an update through a click handler:

http://jsfiddle.net/25Adh/5/ "

That's why calling forceUpdate from requestAnimationFrame is not a problem?

--
Note that posts from new members are moderated - please be patient with your first post.
---

You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/4wFYpXRGbqw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.