[ClojureScript] Looking for project - cljs data to HTML DOM pretty-printing
Hi All, A while back I came across a project that could take cljs data and render it in a nice readable way as HTML. I was sure I bookmarked it, or starred the github repo, but now that I need it there is no sign of it. Google searches are proving fruitless. There is the abandoned github.com/stuartsierra/cljs-formatter, but this project was much better as I recall. Does anyone know what project this was? Thanks Tom -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] om - focused re-rendering
Thanks David.
On Thursday, 6 November 2014 14:27:23 UTC, David Nolen wrote:
Most of the conundrums are obviated by reference cursors. Organize
your data however you like, only want needs to be re-rendered will be
re-rendered.
On Wed, Nov 5, 2014 at 8:38 AM, Colin Yates colin.ya...@gmail.com wrote:
Hi,
Another question of idiomatic usage (will somebody *please* right a
JoyOfClojure type book about om ;)).
I have a hierarchy in my app-state (e.g. a hierarchy of locations). I also
have app-state which stores the ids of the nodes that are selected
{:reference {:locations {:id 1 :text All locations :children [...]}} :ui
{:page-1 {:locations {:selected-ids [].
However, for the purposes of this question let's assume I don't want to
store the ids of the expanded nodes.
My question is where to store this state:
[tree local state in an expanded-ids []]
If I do this (i.e. the tree's IInitState returns {:expanded-ids []}). Each
component node in the tree is passed {:expanded? (id-in? (:id node)
expanded-ids). Every time I expand or collapse the tree the tree
component's top-level state (i.e. the expanded-ids vector) is changed which
causes the whole tree to re-render.
[tree local state in a projected-tree]
In this scenario the component state is a hierarchy that merges the
underlying (e.g. locations) tree with an expanded?: {:id 1 :text All
locations :children [...] :expanded? bool). As before, each tree node is
now mapped to an individual node however, expanding or collapsing the tree
only changes the data that a specific node is referencing so only that node
needs to be re-rendered?
[no local state]
In this scenario there is no local state and it all comes from the
app-state. This is actually a red herring as the question is the same -
what data structure do you store?
In both scenarios the same amount of dom manipulation is done due to om's
optimisations and react's fantastic diff engine, but in the first the whole
component is re-rendered, in the second only the individual node is
re-rendered.
It would seem that the second approach is the way to go, the more expensive
the rendering the truer this is, except it has an additional complexity of
wrangling together a bunch of data structures (as well as expanded there
might be many more).
Firstly, are my assumptions correct (they seem to be based on my initial
investigations) and secondly, what do you all do?
(Has anyone thought of writing a book on this stuff? I can't be the only
person who has been doing this a while and been completely blown out of the
water by the whole treat the dom like a projection/state-machine/pure
function mind set?)
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: om - focused re-rendering
On hindsight, I think my question is based on an incorrect assumption. In a
test case, whether you construct the data on the fly or map directly to
app-state the same number of render calls are made, so move on please,
nothing to see here :).
On Wednesday, 5 November 2014 13:38:46 UTC, Colin Yates wrote:
Hi,
Another question of idiomatic usage (will somebody *please* right a
JoyOfClojure type book about om ;)).
I have a hierarchy in my app-state (e.g. a hierarchy of locations). I also
have app-state which stores the ids of the nodes that are selected
{:reference {:locations {:id 1 :text All locations :children [...]}} :ui
{:page-1 {:locations {:selected-ids [].
However, for the purposes of this question let's assume I don't want to store
the ids of the expanded nodes.
My question is where to store this state:
[tree local state in an expanded-ids []]
If I do this (i.e. the tree's IInitState returns {:expanded-ids []}). Each
component node in the tree is passed {:expanded? (id-in? (:id node)
expanded-ids). Every time I expand or collapse the tree the tree component's
top-level state (i.e. the expanded-ids vector) is changed which causes the
whole tree to re-render.
[tree local state in a projected-tree]
In this scenario the component state is a hierarchy that merges the
underlying (e.g. locations) tree with an expanded?: {:id 1 :text All
locations :children [...] :expanded? bool). As before, each tree node is now
mapped to an individual node however, expanding or collapsing the tree only
changes the data that a specific node is referencing so only that node needs
to be re-rendered?
[no local state]
In this scenario there is no local state and it all comes from the app-state.
This is actually a red herring as the question is the same - what data
structure do you store?
In both scenarios the same amount of dom manipulation is done due to om's
optimisations and react's fantastic diff engine, but in the first the whole
component is re-rendered, in the second only the individual node is
re-rendered.
It would seem that the second approach is the way to go, the more expensive
the rendering the truer this is, except it has an additional complexity of
wrangling together a bunch of data structures (as well as expanded there
might be many more).
Firstly, are my assumptions correct (they seem to be based on my initial
investigations) and secondly, what do you all do?
(Has anyone thought of writing a book on this stuff? I can't be the only
person who has been doing this a while and been completely blown out of the
water by the whole treat the dom like a projection/state-machine/pure
function mind set?)
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: om - focused re-rendering
Re: Om book, I think it's still a bit too early since the idioms and best
practices are still largely being figured out.
A crowd sourced book that can be quickly updated as Om gets more and more
battle tested could work, but for now I think contributing to the official
docs and tutorials to bring (and keep) them up to date would be of greater
value for now.
On Fri, 7 Nov 2014 11:31 Colin Yates colin.ya...@gmail.com wrote:
On hindsight, I think my question is based on an incorrect assumption. In
a test case, whether you construct the data on the fly or map directly to
app-state the same number of render calls are made, so move on please,
nothing to see here :).
On Wednesday, 5 November 2014 13:38:46 UTC, Colin Yates wrote:
Hi,
Another question of idiomatic usage (will somebody *please* right a
JoyOfClojure type book about om ;)).
I have a hierarchy in my app-state (e.g. a hierarchy of locations). I
also have app-state which stores the ids of the nodes that are selected
{:reference {:locations {:id 1 :text All locations :children [...]}} :ui
{:page-1 {:locations {:selected-ids [].
However, for the purposes of this question let's assume I don't want to
store the ids of the expanded nodes.
My question is where to store this state:
[tree local state in an expanded-ids []]
If I do this (i.e. the tree's IInitState returns {:expanded-ids []}).
Each component node in the tree is passed {:expanded? (id-in? (:id node)
expanded-ids). Every time I expand or collapse the tree the tree
component's top-level state (i.e. the expanded-ids vector) is changed which
causes the whole tree to re-render.
[tree local state in a projected-tree]
In this scenario the component state is a hierarchy that merges the
underlying (e.g. locations) tree with an expanded?: {:id 1 :text All
locations :children [...] :expanded? bool). As before, each tree node is
now mapped to an individual node however, expanding or collapsing the tree
only changes the data that a specific node is referencing so only that node
needs to be re-rendered?
[no local state]
In this scenario there is no local state and it all comes from the
app-state. This is actually a red herring as the question is the same -
what data structure do you store?
In both scenarios the same amount of dom manipulation is done due to
om's optimisations and react's fantastic diff engine, but in the first the
whole component is re-rendered, in the second only the individual node is
re-rendered.
It would seem that the second approach is the way to go, the more
expensive the rendering the truer this is, except it has an additional
complexity of wrangling together a bunch of data structures (as well as
expanded there might be many more).
Firstly, are my assumptions correct (they seem to be based on my initial
investigations) and secondly, what do you all do?
(Has anyone thought of writing a book on this stuff? I can't be the only
person who has been doing this a while and been completely blown out of the
water by the whole treat the dom like a projection/state-machine/pure
function mind set?)
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Improving ClojureScript eval on Light Table
I'd love it if external browser connection could automatically update the websocket port in my index.html so I don't have to. Or perhaps manage the port lifecycle and assign a stable port per project. I personally really like the utility of CLJS debugging via Chrome DevTools so external browser is my preferred connection method. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: javascript to clojurescript transpiler
Ha! Make a lein plugin for it and we're set. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] MVI/virtual-dom improvement over React/Om?
Has anyone applied Clojurescript to this new alternative to React by Andre Medeiros? http://futurice.com/blog/reactive-mvc-and-the-virtual-dom He claims it's more purely reactive and performant than ReactJS. gvim -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
