ANN: Om 0.3.0

[David Nolen]

A few minor simplifications to the Om model in this release. A breaking change if you were using om.core/bind, om.core/pure-bind or om.core/read - these complications have been removed.

There's also now a tutorial optimized for Light Table for people want to understand the Om approach to React without losing time cobbling together a working environment: http://github.com/swannodette/om/wiki/Tutorial

Have fun!

David

[David Pidcock]

I was following along with this and hit an interesting "bug"

The contact list delete button actually works "out of the gate" in the first example, (when its supposed to fail) and when I add the deref in the next step I get

Uncaught Error: No protocol method IDeref.-deref defined for type om.core/MapCursor: [object Object]

And that was with 0.2.3 and 0.3.0 (I tried both)

[David Nolen]

You need to use 0.3.0 and you need to run `lein cljsbuild clean` before running `lein cljsbuild auto`.

--
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.

[David Pidcock]

Ahh whoops. Forgot the clean step.
The lein new project imported 0.2.3 for me. I assume that has been fixed then?

[David Nolen]

I just now tried `lien new mies-om foo` which created a project that uses 0.3.0.

On Sat, Jan 25, 2014 at 2:59 PM, David Pidcock <eraz0...@gmail.com> wrote:

Ahh whoops. Forgot the clean step.
The lein new project imported 0.2.3 for me. I assume that has been fixed then?

[Joel]

This tutorial was exactly what I needed, and hope to see more in the tutorial as hinted at at the end.

I think I'm having a Light Table issue though. There is quite a few places where you mention to try evaluating the functions. However, I think something is messed up with my LightTable installation because I get things like:

#<function parse_contact(contact_str){var vec__8926 = string.split.call(null,contact_str,/\s+/);var first = cljs.core.nth.call(null,vec__8926,0,null);var middle = cljs.core.nth.call(null,vec__8926,1,null);var last = cljs.core.nth.call(null,vec__8926,2,null);var parts = vec__8926;var vec__8927 = (((last == null))?new cljs.core.PersistentVector(null, 2, 5, cljs.core.PersistentVector.EMPTY_NODE, [first,middle], null):new c

this was when evaluating the (defn parse-contact) function.
It doesn't look very useful at all to me to read that, so I'm hoping something is screwed up, but I don't know what?!

[David Nolen]

Nothing "wrong" here. Light Table shows the result from the browser, that's the source of the function you just evaluated. It's a quirk of ClojureScript that's existed for some time - we might show something else in the future.

--

[wuqi...@gmail.com]

I following the tutorial. After I opened index.html, the page is empty without any word. This is different from what said in the tutorial. BTW, I double clicked the index.html, and then chrome shows the page, is this the right way to open it or need to use some http://.../index.html after start some service?

Once the build has succeeded open index.html in your favorite browser (we recommend Google Chrome as it has excellent support for source maps). You should see an h1 tag with the text content Hello World! in it.

[Rudi Engelbrecht]

Yip - that fixed it for me - the behaviour of the delete button is now working as per your tutorial.

[mynomoto]

Hi wuqi...@gmail.com,

You can just open the file. I got some blank pages when for some reason I wasn't able to reach fb.me. Check your Network tab in the developer tools.

[Jamie Orchard-Hays]

David, there's a confusing sentence in the paragraph before the om.core/root header:

"Everything in the atom should be an associative data structure - either a ClojureScript map or indexed sequential data structure such as a vector, list and lazy sequences are not allowed."

[David Nolen]

What is unclear?

[Ivan Kozik]

I'm not Jamie, but I had to read that a few times to realize "list and
lazy sequences are not allowed" is another sentence, not a
continuation of the list of things that are allowed.

[David Nolen]

Ah good point, I've clarified the tutorial.

[Jamie Orchard-Hays]

:) Worked through the Om tutorial today. Thanks much, David. Good stuff. 

[David Nolen]

Glad to hear it. I recommend taking a look at the new section "Higher Order Components" http://github.com/swannodette/om/wiki/Tutorial#wiki-higher-order-components, we're finally getting to the "good stuff" IMO :)

David

[mynomoto]

Thank you for this David. It's really amazing.

[Joel Trunick]

I think if there's a reason to sway folks to ClojureScript Om/React is a very good one. I won't be surprised if through this tutorial and Om, we'll see some nice production apps.

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/pj6UwzP9QL4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

[Mike Haney]

Yes! This is good stuff.

Over the weekend, I started working on using Om for a potential "real world" project and I quickly encountered the need for "higher order" polymorphic components. Then I started worrying that maybe I had missed some fundamental concept of Om/React and was complecting. I'm glad to see that wasn't the case, and it looks like I was actually on the right track for my design.

I was initially surprised by the implementation in your tutorial using multimethods instead of protocols, especially since you are only dispatching on a single function. But as I thought about it more, I realized this could be a perfect place for multiple dispatch, i.e. swapping components based on multiple pieces of application state. Powerful stuff!

One question - I've tended to shy away from multimethods because of the performance hit, but this is a compelling case for their usage. Just how big of a performance hit are we talking about, compared to protocols or regular function invocation?

[David Nolen]

On Mon, Jan 27, 2014 at 12:48 PM, Mike Haney <txmik...@gmail.com> wrote:

I was initially surprised by the implementation in your tutorial using multimethods instead of protocols, especially since you are only dispatching on a single function.  But as I thought about it more, I realized this could be a perfect place for multiple dispatch, i.e. swapping components based on multiple pieces of application state.  Powerful stuff!

The problem with protocols is that they are type directed - I think for most user interfaces you want something data directed.

One question - I've tended to shy away from multimethods because of the performance hit, but this is a compelling case for their usage.  Just how big of a performance hit are we talking about, compared to protocols or regular function invocation?

Multimethods are probably 4X-5X slower in ClojureScript then they should be. I'll probably be looking into optimizing them in the near future. However using them with Om is fine since they aren't really part of the inner loop - all the time is going to be spent in React, not your ClojureScript.

David

[David Pidcock]

Did you get this fixed Rudi? 

If your project file requires om 0.2.3,  then it was something with the lein new command (which is now fixed). 

I recommend manually changing the project file to require om 0.3.0 and then don't forget to "lein cljscript clean" before recompiling  (which I did). 

 

On Saturday, January 25, 2014 1:41:54 PM UTC-8, Rudi Engelbrecht wrote:

Hi David

Thank you for a great tutorial!

I really enjoyed working through your Tutorial on LightTable and Om. 

A note: In my environment the contact is being deleted when the contact-view has the following code

(defn contact-view [contact owner]
  (reify
    om/IRenderState
    (render-state [this {:keys [delete]}]
      (dom/li nil
        (dom/span nil (display-name contact))
        (dom/button #js {:onClick (fn [e] (put! delete contact))} "Delete")))))

and not when it is the following:

(defn contact-view [contact owner]
  (reify
    om/IRenderState
    (render-state [this {:keys [delete]}]
      (dom/li nil
        (dom/span nil (display-name contact))
        (dom/button #js {:onClick (fn [e] (put! delete @contact))} "Delete")))))

So the change to

(put! delete @contact)

has the effect of the delete button not working anymore.

I will investigate further.

Kind regards

Rudi

--

--
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, visithttps://groups.google.com/groups/opt_out.

[David Pidcock]

I'm a big fan of this new tutorial.

It hi-lights some of the benefits of cursors, and I actually realize how I might use om/join suddenly :D

[Joel Trunick]

A "by the way" this is how it looks using Sablano/Kioo would be nice in the tutorial.

--

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/pj6UwzP9QL4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

[Jamie Orchard-Hays]

looking forward to working through the new stuff later this week.

[David Nolen]

om/join is conceptually quite cool, but it actually needs some serious work as alluded - currently you're likely to run into some nasty surprises if you really try to use it. The tutorials aren't going to proceed until this is addressed sometime this week.

David

On Mon, Jan 27, 2014 at 1:28 PM, David Pidcock <eraz0...@gmail.com> wrote:

I'm a big fan of this new tutorial.

It hi-lights some of the benefits of cursors, and I actually realize how I might use om/join suddenly :D

--

[Rudi Engelbrecht]

Hi David

I managed to fix it by:

1. Changing project.clj to use om 0.3.0

2. lein cljsbuild clean

Thanks a lot for following up ;-)

I am enjoying working in Om/React with ClojureScript ;-)

--

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

---

[David Pidcock]

Well at least I can know guess at the etymology : sql join leaps to mind, joining on a different "branch" of the state tree with keys from another branch.

I didn't understand that until I read your tutorial.

[Conrad Barski]

Is it wrong to wish "component" worked like this?

(component (render []
(div nil "Hello There!")))

(component (render-state [state]
(div nil "Hello There!"))

(component (will-mount [_]
(js/console.log "mounting!"))L
(render []
(div nil "Hello There!")))

...I could see the appeal of the current "component" macro before render-state was introduced... I can also see the appeal of using a raw "Reify", but given that all the Om interfaces have a single member function, having to write "IWillMount (will-mount [] ...))" etc is starting to feel like java boilerplate

(but maybe such a macro will interfere with other features that I'm overlooking)

[David Nolen]

People should implement sugar if they feel so inclined. Om is not mature enough that I want to spend time supporting extra stuff when the library is evolving so rapidly. Keeping docstrings and tutorials in sync and fielding questions is keeping me plenty busy :)

David

[Conrad Barski]

Yes, docstrings/etc are hard work- Certainly sensible to focus on the core design issues.

[Mike Haney]

IMO, you definitely have your priorities straight, and I would question whether Om ever needs to add a lot of sugar.  When building any non-trivial app, you will most likely end up creating your own abstractions anyway.

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/pj6UwzP9QL4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

[David Nolen]

I'm not against sugar, but let's go there when everyone is excited about the fundamentals :)