3 ms·

Local State, Global Concerns: Better Snapshot Debugging for ClojureScript/Om

20 points by brandonbloom 12y ago

dwwoelfel 12y ago
It's not mentioned in the blog post, but this has been pulled into the main Om repo: https://github.com/swannodette/om/commit/ee9d92bf1191a391df804c066868c8180f9d64cf#diff-67c3db4c8f48d3573baf5792b062251fR683 https://github.com/swannodette/om/commit/ee9d92bf1191a391df8... If you're on the new Om alpha, you can use it with: (om/root app-component app-state {:target target :instrument (fn [f cursor m] (om/build* f cursor (assoc m :descriptor (om/no-local-descriptor om/no-local-state-methods))))})
sgrove 12y ago
This solves (or at least attempts to solve) one of the biggest problems I had about Om. We bent over backwards to get global visibility for tooling, pretty much sacrificing encapsulation entirely, because it was so important for building the right tools. Kudos to React for having such an state-location-agnostic design, to Brandon for hacking out such a cool implementation in basically no time, and to Om for exposing a great API for it. Speaking of Om's API, I'm very impressed with the surface area that Om exposes. CircleCI continues to build really powerful tooling on top of it - check out this Om Rendering toolbar that Daniel built with just a few lines of code https://dwwoelfel.github.io/instrumenting-om-components.html https://dwwoelfel.github.io/instrumenting-om-components.html - more than anything else, tools like this help designers on the frontend be more independent, productive, and happy. As an aside, the last gripe I have around Om's API is that after exploring Datascript for ClojureCup[1], it feels a lot more natural to have a client-side db backing the components, with each component having a few queries that feed it. Then, when a transaction invalidates a query, queue the component for re-rendering. I've been exploring a DataScript wrapper around React, and even just a weekend project was able to build something that was really exciting to use [2][3]. David Nolen's talked about wanting to see things like DataScript better integrated into Om, and I'm definitely hoping to see the same thing. [1] http://prcrsr.com/document/789 http://prcrsr.com/document/789 | https://github.com/clojurecup2014/livemocker https://github.com/clojurecup2014/livemocker [2] Example query for tracking mouse position in Sul https://github.com/sgrove/sul/blob/master/src/sul/core.cljs#L247 https://github.com/sgrove/sul/blob/master/src/sul/core.cljs#... [3] Sul Example recording/playback: http://sgrove.github.io/sul/ http://sgrove.github.io/sul/

20 points by brandonbloom 12y ago

It's not mentioned in the blog post, but this has been pulled into the main Om repo: https://github.com/swannodette/om/commit/ee9d92bf1191a391df804c066868c8180f9d64cf#diff-67c3db4c8f48d3573baf5792b062251fR683 https://github.com/swannodette/om/commit/ee9d92bf1191a391df8... If you're on the new Om alpha, you can use it with: (om/root app-component app-state {:target target :instrument (fn [f cursor m] (om/build* f cursor (assoc m :descriptor (om/no-local-descriptor om/no-local-state-methods))))})

sgrove 12y ago

This solves (or at least attempts to solve) one of the biggest problems I had about Om. We bent over backwards to get global visibility for tooling, pretty much sacrificing encapsulation entirely, because it was so important for building the right tools. Kudos to React for having such an state-location-agnostic design, to Brandon for hacking out such a cool implementation in basically no time, and to Om for exposing a great API for it. Speaking of Om's API, I'm very impressed with the surface area that Om exposes. CircleCI continues to build really powerful tooling on top of it - check out this Om Rendering toolbar that Daniel built with just a few lines of code https://dwwoelfel.github.io/instrumenting-om-components.html https://dwwoelfel.github.io/instrumenting-om-components.html - more than anything else, tools like this help designers on the frontend be more independent, productive, and happy. As an aside, the last gripe I have around Om's API is that after exploring Datascript for ClojureCup[1], it feels a lot more natural to have a client-side db backing the components, with each component having a few queries that feed it. Then, when a transaction invalidates a query, queue the component for re-rendering. I've been exploring a DataScript wrapper around React, and even just a weekend project was able to build something that was really exciting to use [2][3]. David Nolen's talked about wanting to see things like DataScript better integrated into Om, and I'm definitely hoping to see the same thing. [1] http://prcrsr.com/document/789 http://prcrsr.com/document/789 | https://github.com/clojurecup2014/livemocker https://github.com/clojurecup2014/livemocker [2] Example query for tracking mouse position in Sul https://github.com/sgrove/sul/blob/master/src/sul/core.cljs#L247 https://github.com/sgrove/sul/blob/master/src/sul/core.cljs#... [3] Sul Example recording/playback: http://sgrove.github.io/sul/ http://sgrove.github.io/sul/