3 ms·

Nope, it calls it regardless of state change—that's the point, you eliminate the challenge of determining when state has changed. To quote TFA: > A set method

by tomdale 12y ago

Nope, it calls it regardless of state change—that's the point, you eliminate the challenge of determining when state has changed. To quote TFA: > A set method to change state could trigger a rerender (React has setState), but there's an even easier way to react to changes: continuously call renderComponent with requestAnimationFrame to repaint the UI, and only change the DOM when the component returns different content. Edit: I was mistaken about how Om works. I was under the impression that Om scheduled a rAF every 16ms to check for state change. In fact, it only schedules a rAF once the state changes. However, this relies on being able to listen for state change from the underlying model data. I was under the impression that one of the benefits of Om/React was that you could use its data bindings with any JavaScript library, even if it hadn't been instrumented for property observation. Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface.

mbrubeck 12y ago
That's a description of the examples that use "Bloop," jlongster's toy library. Those examples do run a continuous requestAnimationFrame loop. Om, however, does not call requestAnimationFrame in a continuous loop; it calls it only when the state changes. (To be fair, jlongster's article originally said that Om also rendered continuously, but that has now been corrected.)
jpfuentes2 12y ago
Thanks for clearing up the confusion. Although, I think it's worth it for you to edit your initial reply since it's the most upvoted comment so far. Also, your comment, to me, shows there is still some confusion regarding Om's internals: > However, this relies on being able to listen for state change from the underlying model data. [...] Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface. Actually, the interface used is ClojureScript's flavor of STM: you set your app state, generally a hash-map, in an atom. When you mutate the app state via `swap!` it is published to Om -> React -> render. This may seem like a pedantic distinction, however, the key point is that you are required to use an atom which controls app state mutation. You could also use strings and vectors as your app state if you so choose.
- Touche 12y ago
  Interfacing with an external js library that publishes changes would be trivial though. Typically if you're building a ClojureScript app you're building a ClojureScript app... which means using atoms.
swannodette 12y ago
Your conclusions about how Om works are still inaccurate :) There is no such limitation about what data structures you can use. There is no state change notification interface for data. Components can update their local state - no notification required here. Updates to global information (the application state) triggers a re-render from the root component of the application. Because of persistent data structures these updates can be done in logarithmic time as we never compute React UI subtrees that depend on unchanged data - it's just a reference equality check (JavaScript ===) in ClojureScript for any given piece of data to know whether it's changed or not.

by tomdale 12y ago

mbrubeck 12y ago

That's a description of the examples that use "Bloop," jlongster's toy library. Those examples do run a continuous requestAnimationFrame loop. Om, however, does not call requestAnimationFrame in a continuous loop; it calls it only when the state changes. (To be fair, jlongster's article originally said that Om also rendered continuously, but that has now been corrected.)

jpfuentes2 12y ago

Thanks for clearing up the confusion. Although, I think it's worth it for you to edit your initial reply since it's the most upvoted comment so far. Also, your comment, to me, shows there is still some confusion regarding Om's internals: > However, this relies on being able to listen for state change from the underlying model data. [...] Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface. Actually, the interface used is ClojureScript's flavor of STM: you set your app state, generally a hash-map, in an atom. When you mutate the app state via `swap!` it is published to Om -> React -> render. This may seem like a pedantic distinction, however, the key point is that you are required to use an atom which controls app state mutation. You could also use strings and vectors as your app state if you so choose.

Touche 12y ago
Interfacing with an external js library that publishes changes would be trivial though. Typically if you're building a ClojureScript app you're building a ClojureScript app... which means using atoms.

swannodette 12y ago

Your conclusions about how Om works are still inaccurate :) There is no such limitation about what data structures you can use. There is no state change notification interface for data. Components can update their local state - no notification required here. Updates to global information (the application state) triggers a re-render from the root component of the application. Because of persistent data structures these updates can be done in logarithmic time as we never compute React UI subtrees that depend on unchanged data - it's just a reference equality check (JavaScript ===) in ClojureScript for any given piece of data to know whether it's changed or not.