Re: [ClojureScript] working reference/example apps in cljs wanted for educational purposes
Thanks Alexander, I think this fits the bill! On Thursday, October 23, 2014 12:02:06 PM UTC+2, Alexander Solovyov wrote: I think my own small implementation of snake mostly meets your requirements: https://github.com/piranha/qsnake (it's based on react/quiescent). On Thu, Oct 23, 2014 at 12:01 PM, Michiel Borkent michiel...@gmail.com wrote: For newcomers to cljs I think it's very important to have out of the box working examples in clojurescript. I tried the twitterbuzz application, but it's fundamentally broken because of the 1.1 API version of Twitter and its oauth demands. I tried ClojureScript One but it requires leiningen 1.7 and I don't want to go back to that version. These are two examples that newcomers might give 5 minutes and then quit clojurescript because of a bad experience. So, what I'm looking for is good out of the box working examples in: - Vanilla clojurescript - React based examples One example of a vanilla clojurescript example that *just works* is this todomvc port: https://github.com/dfuenzalida/todo-cljs Preferable the examples should be - short and simple (not thousands of lines of code) - easy to understand for newcomers - easy to run (lein cljsbuild once, open index.html) - not dependent on too many third party libraries Your suggestions are welcome. I'll write down the suggestions in a gist or github repo in a later stage. Thanks in advance! -- 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. -- 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] working reference/example apps in cljs wanted for educational purposes
I'm not sure if this meets your complexity requirements, but you could try the Goya pixel editor: https://github.com/jackschaedler/goya. On 24 October 2014 00:05, Michiel Borkent michielbork...@gmail.com wrote: Thanks Alexander, I think this fits the bill! On Thursday, October 23, 2014 12:02:06 PM UTC+2, Alexander Solovyov wrote: I think my own small implementation of snake mostly meets your requirements: https://github.com/piranha/qsnake (it's based on react/quiescent). On Thu, Oct 23, 2014 at 12:01 PM, Michiel Borkent michiel...@gmail.com wrote: For newcomers to cljs I think it's very important to have out of the box working examples in clojurescript. I tried the twitterbuzz application, but it's fundamentally broken because of the 1.1 API version of Twitter and its oauth demands. I tried ClojureScript One but it requires leiningen 1.7 and I don't want to go back to that version. These are two examples that newcomers might give 5 minutes and then quit clojurescript because of a bad experience. So, what I'm looking for is good out of the box working examples in: - Vanilla clojurescript - React based examples One example of a vanilla clojurescript example that *just works* is this todomvc port: https://github.com/dfuenzalida/todo-cljs Preferable the examples should be - short and simple (not thousands of lines of code) - easy to understand for newcomers - easy to run (lein cljsbuild once, open index.html) - not dependent on too many third party libraries Your suggestions are welcome. I'll write down the suggestions in a gist or github repo in a later stage. Thanks in advance! -- 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. -- 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.
Re: [ClojureScript] working reference/example apps in cljs wanted for educational purposes
On Thursday, 23 October 2014, Michiel Borkent michielbork...@gmail.com wrote: So, what I'm looking for is good out of the box working examples in: - Vanilla clojurescript - React based examples Preferable the examples should be - short and simple (not thousands of lines of code) - easy to understand for newcomers - easy to run (lein cljsbuild once, open index.html) - not dependent on too many third party libraries For my first dive into Clojurescript, I have found the Quiescent ToDoMVC very interesting and readable: https://github.com/levand/todomvc/tree/gh-pages/architecture-examples/quiescent I already had some experience with Clojure (and go, so core.async was not too foreign, even though I had never used it yet) and had read the entire React documentation, so maybe I was not exactly your typical newbie. -- 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] working reference/example apps in cljs wanted for educational purposes
I consider that an advanced example. Also cool, but not for total beginners probably. On Thursday, October 23, 2014 1:12:56 PM UTC+2, Colin Fleming wrote: I'm not sure if this meets your complexity requirements, but you could try the Goya pixel editor: https://github.com/jackschaedler/goya. On 24 October 2014 00:05, Michiel Borkent michiel...@gmail.com wrote: Thanks Alexander, I think this fits the bill! On Thursday, October 23, 2014 12:02:06 PM UTC+2, Alexander Solovyov wrote: I think my own small implementation of snake mostly meets your requirements: https://github.com/piranha/qsnake (it's based on react/quiescent). On Thu, Oct 23, 2014 at 12:01 PM, Michiel Borkent michiel...@gmail.com wrote: For newcomers to cljs I think it's very important to have out of the box working examples in clojurescript. I tried the twitterbuzz application, but it's fundamentally broken because of the 1.1 API version of Twitter and its oauth demands. I tried ClojureScript One but it requires leiningen 1.7 and I don't want to go back to that version. These are two examples that newcomers might give 5 minutes and then quit clojurescript because of a bad experience. So, what I'm looking for is good out of the box working examples in: - Vanilla clojurescript - React based examples One example of a vanilla clojurescript example that *just works* is this todomvc port: https://github.com/dfuenzalida/todo-cljs Preferable the examples should be - short and simple (not thousands of lines of code) - easy to understand for newcomers - easy to run (lein cljsbuild once, open index.html) - not dependent on too many third party libraries Your suggestions are welcome. I'll write down the suggestions in a gist or github repo in a later stage. Thanks in advance! -- 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. -- 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. -- 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] (newbie) Om/reagent (and react) clarity questions
(apologies if I have overlooked any of this in the docs, it isn't from lack of
reading, more reaching saturation point - RTFM is a perfectly good response if
it contains a link to the relevant bit :))
My use case is that I have a non-trivial single page app. Inside this app there
are a number of distinct areas, for a completely made up domain of car rental:
- searching for/editing/adding a new customer
- searching for/editing/adding a car
- assigning a car to a customer
- receiving a car from a customer
- removing a car due to maintenance/crash
- various reports - top 10 customers, top 10 cars etc.
- and so on
Each functional area is pretty unrelated from the others. Inside each
functional area there are individual components that all need to talk to each
other.
Is it true that om really wants to manage the entire application state in a
single atom. So we might have an atom map structured with keys referencing each
functional area {:car-search {} :patient-search {} ...}? I understand that this
isn't inefficient as components receive a cursor into their bit of the map thus
avoiding unnecessary false changes.
The main app will have an expandable left panel containing the global menu. In
dom-manipulation world I would add a collapsed or expanded CSS class which
defined the appropriate widths etc. In om (or rather react) land this is still
possible I think, but is it more idiomatic to store the expanded/collapsed flag
in the application state thus causing the panel component to re-render, the
panel component then switching on that expanded? flag? The central panel
also needs to be resized in response to the expansion/collapse, thus both
components need to be in-sync. How is this idiomatically handled?
In the more general case, there are components that need to be shown/hidden
(tabs, validation pop-up errors etc.). In dom-manipulation world I would set
css classes to change style's visibility for example, is this idiomatically
done through flags in the application state?
I am stumped as to how routing navigation fits into something like om. Again,
is it a case that the navigation handlers simply update the application state?
(You can see a theme in my thinking here!)
In terms of reagent is it true to say that it is a bit less opinionated about
these things and where-as om has a very opinionated approach to front-end state
management (happening to use om), reagent is a (very nice) wrapper to om? Not
to trivialize reagent, but is is simply trying to introduce clojurescript to
react?
Is it also true to say that whilst om wants to manage the whole application,
reagent allows you to think about disconnected bits of your app?
FWIW - reagent appeals to my pragmatic need to get stuff done and it feels
very un-opinionated and very lightweight. However, the more I read about om the
more it jives with me. However, I am in the pattern of yeah, that is how I
would solve that problem, I just can't quite connect the dots in the bigger
picture.
It is also worth saying that there are no losers here, I am sure I will be
delighted using either om or reagent.
I think that is sufficient for now - thanks for reading, and thanks even more
for responding :).
--
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] working reference/example apps in cljs wanted for educational purposes
I have started the list here on github: https://github.com/borkdude/simple-cljs-examples/blob/master/README.md Feel free to send me a pull request. -- 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] (newbie) Om/reagent (and react) clarity questions
A few thoughts, though I’m sure others will have more:
-
Om requires your entire React render tree’s data to be stored in a
single atom, but you can have as many render trees as you’d like on a page,
each with its own atom of state. It’s more common to just use one, but more
than one is an option, if it makes sense for you.
-
In Om, state like showing and hiding a tab is sometimes stored in the
application state, and sometimes stored in the component’s local state.
That’s a matter of preference. As far as I know there’s no big rule of
thumb for when one is better than the other; they each have some subtle
advantages and disadvantages.
-
Reagent is more than just a thin veneer over React. It does quite a bit
of work, just as Om does. This is subjective, but Reagent feels more easy
than simple to me. Sometimes, that’s what you want; sometimes it’s not.
But: I’ve barely touched Reagent myself, so take that with a large grain of
salt. I’d love to hear a response from someone actually working with
Reagent.
-
There *is* a React wrapper that’s mostly a thin veneer: Quiescent
https://github.com/levand/quiescent. Quiescent, to me, is at the
simple end of the simple-easy spectrum. Unlike Om or Reagent, it doesn’t
manage your rendering for you; you store your state where you will and tell
it to render the tree when you think it should (which is how React itself
works).
I have a blog post
http://blog.peeja.com/blog/2014/10/01/react-four-ways-how-to-use-react-in-clojurescript/
that goes into some more detail with links to examples, if you’re curious.
Hooking up URL routing to any of these has had my head spinning as well.
I’d love to hear what other people are doing for that too.
Peter
On Thu, Oct 23, 2014 at 9:04 AM, Colin Yates colin.ya...@gmail.com wrote:
(apologies if I have overlooked any of this in the docs, it isn't from
lack of reading, more reaching saturation point - RTFM is a perfectly good
response if it contains a link to the relevant bit :))
My use case is that I have a non-trivial single page app. Inside this app
there are a number of distinct areas, for a completely made up domain of
car rental:
- searching for/editing/adding a new customer
- searching for/editing/adding a car
- assigning a car to a customer
- receiving a car from a customer
- removing a car due to maintenance/crash
- various reports - top 10 customers, top 10 cars etc.
- and so on
Each functional area is pretty unrelated from the others. Inside each
functional area there are individual components that all need to talk to
each other.
Is it true that om really wants to manage the entire application state in
a single atom. So we might have an atom map structured with keys
referencing each functional area {:car-search {} :patient-search {} ...}? I
understand that this isn't inefficient as components receive a cursor into
their bit of the map thus avoiding unnecessary false changes.
The main app will have an expandable left panel containing the global
menu. In dom-manipulation world I would add a collapsed or expanded CSS
class which defined the appropriate widths etc. In om (or rather react)
land this is still possible I think, but is it more idiomatic to store the
expanded/collapsed flag in the application state thus causing the panel
component to re-render, the panel component then switching on that
expanded? flag? The central panel also needs to be resized in response
to the expansion/collapse, thus both components need to be in-sync. How is
this idiomatically handled?
In the more general case, there are components that need to be
shown/hidden (tabs, validation pop-up errors etc.). In dom-manipulation
world I would set css classes to change style's visibility for example, is
this idiomatically done through flags in the application state?
I am stumped as to how routing navigation fits into something like om.
Again, is it a case that the navigation handlers simply update the
application state? (You can see a theme in my thinking here!)
In terms of reagent is it true to say that it is a bit less opinionated
about these things and where-as om has a very opinionated approach to
front-end state management (happening to use om), reagent is a (very nice)
wrapper to om? Not to trivialize reagent, but is is simply trying to
introduce clojurescript to react?
Is it also true to say that whilst om wants to manage the whole
application, reagent allows you to think about disconnected bits of your
app?
FWIW - reagent appeals to my pragmatic need to get stuff done and it
feels very un-opinionated and very lightweight. However, the more I read
about om the more it jives with me. However, I am in the pattern of yeah,
that is how I would solve that problem, I just can't quite connect the
dots in the bigger picture.
It is also worth saying that there are no losers here, I am sure I will be
delighted
Re: [ClojureScript] (newbie) Om/reagent (and react) clarity questions
One cool thing which solves one of the problems (namely get views out of
the data) is DataScript [1]. There are some nice and quite compact examples
[2] which are not that trivial (at least they have two different widgets).
DataScript is encouraging in that it feels doable to get data out of the
model without having to manually make clever but brittle structural
assumptions on the inevitable evolving of the data schema.
[1] https://github.com/tonsky/datascript
[2] https://github.com/tonsky/datascript-chat
/Linus
2014-10-23 15:32 GMT+02:00 Peter Jaros peter.a.ja...@gmail.com:
A few thoughts, though I’m sure others will have more:
-
Om requires your entire React render tree’s data to be stored in a
single atom, but you can have as many render trees as you’d like on a page,
each with its own atom of state. It’s more common to just use one, but more
than one is an option, if it makes sense for you.
-
In Om, state like showing and hiding a tab is sometimes stored in the
application state, and sometimes stored in the component’s local state.
That’s a matter of preference. As far as I know there’s no big rule of
thumb for when one is better than the other; they each have some subtle
advantages and disadvantages.
-
Reagent is more than just a thin veneer over React. It does quite a
bit of work, just as Om does. This is subjective, but Reagent feels more
easy than simple to me. Sometimes, that’s what you want; sometimes it’s
not. But: I’ve barely touched Reagent myself, so take that with a large
grain of salt. I’d love to hear a response from someone actually working
with Reagent.
-
There *is* a React wrapper that’s mostly a thin veneer: Quiescent
https://github.com/levand/quiescent. Quiescent, to me, is at the
simple end of the simple-easy spectrum. Unlike Om or Reagent, it doesn’t
manage your rendering for you; you store your state where you will and tell
it to render the tree when you think it should (which is how React itself
works).
I have a blog post
http://blog.peeja.com/blog/2014/10/01/react-four-ways-how-to-use-react-in-clojurescript/
that goes into some more detail with links to examples, if you’re curious.
Hooking up URL routing to any of these has had my head spinning as well.
I’d love to hear what other people are doing for that too.
Peter
On Thu, Oct 23, 2014 at 9:04 AM, Colin Yates colin.ya...@gmail.com
wrote:
(apologies if I have overlooked any of this in the docs, it isn't from
lack of reading, more reaching saturation point - RTFM is a perfectly good
response if it contains a link to the relevant bit :))
My use case is that I have a non-trivial single page app. Inside this app
there are a number of distinct areas, for a completely made up domain of
car rental:
- searching for/editing/adding a new customer
- searching for/editing/adding a car
- assigning a car to a customer
- receiving a car from a customer
- removing a car due to maintenance/crash
- various reports - top 10 customers, top 10 cars etc.
- and so on
Each functional area is pretty unrelated from the others. Inside each
functional area there are individual components that all need to talk to
each other.
Is it true that om really wants to manage the entire application state in
a single atom. So we might have an atom map structured with keys
referencing each functional area {:car-search {} :patient-search {} ...}? I
understand that this isn't inefficient as components receive a cursor into
their bit of the map thus avoiding unnecessary false changes.
The main app will have an expandable left panel containing the global
menu. In dom-manipulation world I would add a collapsed or expanded CSS
class which defined the appropriate widths etc. In om (or rather react)
land this is still possible I think, but is it more idiomatic to store the
expanded/collapsed flag in the application state thus causing the panel
component to re-render, the panel component then switching on that
expanded? flag? The central panel also needs to be resized in response
to the expansion/collapse, thus both components need to be in-sync. How is
this idiomatically handled?
In the more general case, there are components that need to be
shown/hidden (tabs, validation pop-up errors etc.). In dom-manipulation
world I would set css classes to change style's visibility for example, is
this idiomatically done through flags in the application state?
I am stumped as to how routing navigation fits into something like om.
Again, is it a case that the navigation handlers simply update the
application state? (You can see a theme in my thinking here!)
In terms of reagent is it true to say that it is a bit less opinionated
about these things and where-as om has a very opinionated approach to
front-end state management (happening to use om), reagent is a (very nice)
wrapper to om? Not to trivialize
[ClojureScript] Re: [ANN] clairvoyant 0.0-43-ga703f4e
On Wednesday, October 22, 2014 10:15:13 PM UTC-7, Joel Holdbrooks wrote: Clairvoyant, a flexible tracing library for ClojureScript is now version 0.0-43-ga703f4e. Included in this release: * Fixed bug which caused anonymous functions to thrown an exception * Fixed bug with IPrintWithWriter protocol causing maximum call stack exceeded exceptions * Improved display of exit values and function values (you only see the noise when you want to) * Basic tracing for deftype and defrecord * trace-forms can be called without the options map I hope these features improve your debugging experience. Leiningen dependency: [spellhouse/clairvoyant 0.0-43-ga703f4e] Project homepage: https://github.com/spellhouse/clairvoyant Just noticed there were a few problems with the last release. Please use: [spellhouse/clairvoyant 0.0-46-g876ac46] instead. Sorry! -- 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] State of Clojure/ClojureScript 2014 survey results
I've published links to the State of Clojure and ClojureScript 2014 survey results here: http://blog.cognitect.com/blog/2014/10/20/results-of-2014-state-of-clojure-and-clojurescript-survey That page links to some reports with graphs where you can also export the raw data. I also have links to broken out answers from each of the open text questions for easier consumption. Those are redundant, but perhaps useful. I have not had the time to do any analysis or commentary on these yet. Of particular interest in a few questions are comparisons with prior years which are also linked from the post. Big thanks to everyone that participated - it's invaluable to get this snapshot of the community every year, especially as we grow. Alex -- 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: (newbie) Om/reagent (and react) clarity questions
re routing with om, it stumped me at first too, i've outlined an evolving approach here https://groups.google.com/forum/#!topic/clojurescript/E2Lxody9SlM would be happy to bounce ideas of any alternative approaches. -- 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: State of Clojure/ClojureScript 2014 survey results
Thanks, I do hope to follow up with some analysis, just thought it was more important to release the data sooner rather than later. Alex On Thursday, October 23, 2014 12:30:47 PM UTC-5, Fergal Byrne wrote: Great stuff Alex. I'd recommend taking a look at this talk https://www.youtube.com/watch?v=3MvKLOecT1I which does a great analysis job on a similar survey for Erlang. On Thu, Oct 23, 2014 at 4:58 PM, Alex Miller al...@puredanger.com javascript: wrote: I've published links to the State of Clojure and ClojureScript 2014 survey results here: http://blog.cognitect.com/blog/2014/10/20/results-of-2014-state-of-clojure-and-clojurescript-survey That page links to some reports with graphs where you can also export the raw data. I also have links to broken out answers from each of the open text questions for easier consumption. Those are redundant, but perhaps useful. I have not had the time to do any analysis or commentary on these yet. Of particular interest in a few questions are comparisons with prior years which are also linked from the post. Big thanks to everyone that participated - it's invaluable to get this snapshot of the community every year, especially as we grow. Alex -- 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 javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- Fergal Byrne, Brenter IT http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne Founder of Clortex: HTM in Clojure - https://github.com/nupic-community/clortex Author, Real Machine Intelligence with Clortex and NuPIC Read for free or buy the book at https://leanpub.com/realsmartmachines Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: http://euroclojure.com/2014/ and at LambdaJam Chicago, July 2014: http://www.lambdajam.com e:fergalby...@gmail.com javascript: t:+353 83 4214179 Join the quest for Machine Intelligence at http://numenta.org Formerly of Adnet edi...@adnet.ie javascript: http://www.adnet.ie -- 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] (newbie) Om/reagent (and react) clarity questions
Reagent is more than just a thin veneer over React. It does quite a bit of work, just as Om does. This is subjective, but Reagent feels more easy than simple to me. Sometimes, that’s what you want; sometimes it’s not. But: I’ve barely touched Reagent myself, so take that with a large grain of salt. I’d love to hear a response from someone actually working with Reagent. OK, I'll bite. I'm bothered by your use of the term easy. As I'm sure you know, that has a negative connotation in our community, and your remarks seem to imply that Reagent is a toy not to be taken seriously for non-trivial apps. That is certainly not the case. To me, Reagent feels simple, as in just the right level of abstraction, whereas Om feels like incidental complexity. This is just my opinion, but I think perhaps much of the initial popularity of Om was due to the rock-star status of its creator (no disrespect intended - David Nolen IS a rock star in this community, and has made tremendous contributions to our community, and I am very grateful for that). But many people, including myself, seem to be finding the additional complexity unwarrranted in some (most) cases and switched to Reagent. They are BOTH excellent libraries, and it really comes down to which one fits your app and/or your team's mental model best. From my experience, Reagent is generally easier to work with, and you have a lot of flexibility with structuring your app state, which could be good or bad depending on what you are looking for. Om is much more prescriptive, which can be a good thing too - if you have no idea how you should structure your app, well Om might be a good choice because it does force you into doing things a certain way. One thing I did early on when trying to decide between Om and Reagent was write a small but non-trivial part of my app in both. I used Kioo for templating, so I didn't have to write the view code twice, plus having all the markup in templates let me really focus on how I was managing state in both versions. I found it very useful, and I think it just makes sense to do a small spike like this before committing to a particular library for a large project. One last thing - Dmitri Sotnikov has written some nice blog posts on Reagent, which are really helpful for getting starting. I recommend starting with this one: http://yogthos.net/#/blog/54 There is also one on how to do routing with Reagent: http://yogthos.net/#/blog/55 -- 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: working reference/example apps in cljs wanted for educational purposes
Snake: https://github.com/logaan/snake Nonaga: https://github.com/logaan/nonaga Nonaga is a turn based two player tabletop game. On Thursday, 23 October 2014 20:01:49 UTC+11, Michiel Borkent wrote: For newcomers to cljs I think it's very important to have out of the box working examples in clojurescript. I tried the twitterbuzz application, but it's fundamentally broken because of the 1.1 API version of Twitter and its oauth demands. I tried ClojureScript One but it requires leiningen 1.7 and I don't want to go back to that version. These are two examples that newcomers might give 5 minutes and then quit clojurescript because of a bad experience. So, what I'm looking for is good out of the box working examples in: - Vanilla clojurescript - React based examples One example of a vanilla clojurescript example that *just works* is this todomvc port: https://github.com/dfuenzalida/todo-cljs Preferable the examples should be - short and simple (not thousands of lines of code) - easy to understand for newcomers - easy to run (lein cljsbuild once, open index.html) - not dependent on too many third party libraries Your suggestions are welcome. I'll write down the suggestions in a gist or github repo in a later stage. Thanks in advance! -- 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: (newbie) Om/reagent (and react) clarity questions
Is it true that om really wants to manage the entire application state in a
single atom. So we might have an atom map structured with keys referencing
each functional area {:car-search {} :patient-search {} ...}? I understand
that this isn't inefficient as components receive a cursor into their bit of
the map thus avoiding unnecessary false changes.
Technically, each root component can only have 1 state atom, so you could in
theory use multiple roots. I think this ends up being pretty rare in practice,
though. For various reasons, most people seem to end up using a single root
component for the whole app.
The main app will have an expandable left panel containing the global menu.
In dom-manipulation world I would add a collapsed or expanded CSS class
which defined the appropriate widths etc. In om (or rather react) land this
is still possible I think, but is it more idiomatic to store the
expanded/collapsed flag in the application state thus causing the panel
component to re-render, the panel component then switching on that
expanded? flag? The central panel also needs to be resized in response to
the expansion/collapse, thus both components need to be in-sync. How is this
idiomatically handled?
I have that scenario in my app, and yes I just programmatically toggle those
css classes based on the state so I can take advantage of CSS animations (which
are hardware-accelerated on mobile platforms).
Here's a gist using Reagent:
https://gist.github.com/mdhaney/e873611160341da79d77
These are just a few components for the menu, to show the pattern. There are
actually 2 menus, the off-canvas menu to the left, and from there a sub-menu
can be selected (I'm using Foundation for my base CSS framework, and haven't
completed my conversion to semantic classes, which is why the components are
still littered with presentational classes).
A few notes about how I structured this:
1. Most components receive 2 parameters, state and event. The state is
a map containing all the application state, but not in the Om sense. Most of
the values inside state are separate Reagent atoms, I just bundle them up to
make the easier to pass around. The app logic is structured into components
that generally take the entire state map as their input and extract what they
need (similar to the Component library in regular clojure).
2. Event is the core.async pub/sub channel, and subscribe-to is a macro to
easily set up listener go blocks for the given event.
3. In Reagent, a component can return either its markup or a fn with the same
parameters and that fn will be called when it needs to be rendered. This
allows you to setup closures for local state, and I also take advantage of this
to just setup event handlers for the component, like in [main-menu] which has
no local state.
In the more general case, there are components that need to be shown/hidden
(tabs, validation pop-up errors etc.). In dom-manipulation world I would set
css classes to change style's visibility for example, is this idiomatically
done through flags in the application state?
Another way to do it though, is to simply render just the DOM you need for
something like a tab view (rather than rendering all tabs and switching using a
CSS class). I mentioned this in your thread the other day, but as a general
rule what I do is use the CSS classes if I need to take advantage of animations
(like an off-canvas menu) and just render the actual DOM needed (based on
flag(s) in application state) for things like tabs, main content view, etc.
With Reagent you could have an atom representing the current tab and store the
component name in there (as a symbol) and then just reference it like any other
component. Whenever some part of your app updates that state, then it will
automatically be re-rendered. I'm not sure if that makes sense, but he does
that in the routing example I linked to in my previous response.
I am stumped as to how routing navigation fits into something like om. Again,
is it a case that the navigation handlers simply update the application
state? (You can see a theme in my thinking here!)
Your thinking appears to be on track in that in general, you modify app state
and then your UI components are just a pure functional transformation from that
app state to React's virtual DOM.
In terms of reagent is it true to say that it is a bit less opinionated about
these things and where-as om has a very opinionated approach to front-end
state management (happening to use om), reagent is a (very nice) wrapper to
om? Not to trivialize reagent, but is is simply trying to introduce
clojurescript to react?
Addressed this in my previous reply.
Is it also true to say that whilst om wants to manage the whole application,
reagent allows you to think about disconnected bits of your app?
Yes, and that's why I like the Reagent approach better - I can modularize and
reason
Re: [ClojureScript] Re: working reference/example apps in cljs wanted for educational purposes
Hello Logan, Snake: Two things are missing, before I would be willing to try it out as a newcomer: - There are no descriptions in the README how to run it. - The project contains unfinished tests, which may look a bit sloppy. Either remove them or finish them. It would be nice if you could add in the README what technology the game is based on (for example: bare React) Nonaga: - No descriptions in README how to run it + dead links. If you can fix these things I could take a look again and see if it all works. Then I'll add it to the list. Kind regards, Michiel On Fri, Oct 24, 2014 at 5:08 AM, Logan Campbell co...@logaan.net wrote: Snake: https://github.com/logaan/snake Nonaga: https://github.com/logaan/nonaga Nonaga is a turn based two player tabletop game. On Thursday, 23 October 2014 20:01:49 UTC+11, Michiel Borkent wrote: For newcomers to cljs I think it's very important to have out of the box working examples in clojurescript. I tried the twitterbuzz application, but it's fundamentally broken because of the 1.1 API version of Twitter and its oauth demands. I tried ClojureScript One but it requires leiningen 1.7 and I don't want to go back to that version. These are two examples that newcomers might give 5 minutes and then quit clojurescript because of a bad experience. So, what I'm looking for is good out of the box working examples in: - Vanilla clojurescript - React based examples One example of a vanilla clojurescript example that *just works* is this todomvc port: https://github.com/dfuenzalida/todo-cljs Preferable the examples should be - short and simple (not thousands of lines of code) - easy to understand for newcomers - easy to run (lein cljsbuild once, open index.html) - not dependent on too many third party libraries Your suggestions are welcome. I'll write down the suggestions in a gist or github repo in a later stage. Thanks in advance! -- 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/84nnVJ2OLvU/unsubscribe. To unsubscribe from this group and all its topics, 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. -- http://www.michielborkent.nl http://www.eetvoorjeleven.nu -- 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: (newbie) Om/reagent (and react) clarity questions
Thank you all, kudos to Mike again!
You are right, a spike is an excellent idea.
On 24 Oct 2014 05:20, Mike Haney txmikes...@gmail.com wrote:
Is it true that om really wants to manage the entire application state
in a single atom. So we might have an atom map structured with keys
referencing each functional area {:car-search {} :patient-search {} ...}? I
understand that this isn't inefficient as components receive a cursor into
their bit of the map thus avoiding unnecessary false changes.
Technically, each root component can only have 1 state atom, so you could
in theory use multiple roots. I think this ends up being pretty rare in
practice, though. For various reasons, most people seem to end up using a
single root component for the whole app.
The main app will have an expandable left panel containing the global
menu. In dom-manipulation world I would add a collapsed or expanded CSS
class which defined the appropriate widths etc. In om (or rather react)
land this is still possible I think, but is it more idiomatic to store the
expanded/collapsed flag in the application state thus causing the panel
component to re-render, the panel component then switching on that
expanded? flag? The central panel also needs to be resized in response
to the expansion/collapse, thus both components need to be in-sync. How is
this idiomatically handled?
I have that scenario in my app, and yes I just programmatically toggle
those css classes based on the state so I can take advantage of CSS
animations (which are hardware-accelerated on mobile platforms).
Here's a gist using Reagent:
https://gist.github.com/mdhaney/e873611160341da79d77
These are just a few components for the menu, to show the pattern. There
are actually 2 menus, the off-canvas menu to the left, and from there a
sub-menu can be selected (I'm using Foundation for my base CSS framework,
and haven't completed my conversion to semantic classes, which is why the
components are still littered with presentational classes).
A few notes about how I structured this:
1. Most components receive 2 parameters, state and event. The
state is a map containing all the application state, but not in the Om
sense. Most of the values inside state are separate Reagent atoms, I just
bundle them up to make the easier to pass around. The app logic is
structured into components that generally take the entire state map as
their input and extract what they need (similar to the Component library in
regular clojure).
2. Event is the core.async pub/sub channel, and subscribe-to is a macro
to easily set up listener go blocks for the given event.
3. In Reagent, a component can return either its markup or a fn with the
same parameters and that fn will be called when it needs to be rendered.
This allows you to setup closures for local state, and I also take
advantage of this to just setup event handlers for the component, like in
[main-menu] which has no local state.
In the more general case, there are components that need to be
shown/hidden (tabs, validation pop-up errors etc.). In dom-manipulation
world I would set css classes to change style's visibility for example, is
this idiomatically done through flags in the application state?
Another way to do it though, is to simply render just the DOM you need for
something like a tab view (rather than rendering all tabs and switching
using a CSS class). I mentioned this in your thread the other day, but as
a general rule what I do is use the CSS classes if I need to take advantage
of animations (like an off-canvas menu) and just render the actual DOM
needed (based on flag(s) in application state) for things like tabs, main
content view, etc.
With Reagent you could have an atom representing the current tab and store
the component name in there (as a symbol) and then just reference it like
any other component. Whenever some part of your app updates that state,
then it will automatically be re-rendered. I'm not sure if that makes
sense, but he does that in the routing example I linked to in my previous
response.
I am stumped as to how routing navigation fits into something like om.
Again, is it a case that the navigation handlers simply update the
application state? (You can see a theme in my thinking here!)
Your thinking appears to be on track in that in general, you modify app
state and then your UI components are just a pure functional transformation
from that app state to React's virtual DOM.
In terms of reagent is it true to say that it is a bit less opinionated
about these things and where-as om has a very opinionated approach to
front-end state management (happening to use om), reagent is a (very nice)
wrapper to om? Not to trivialize reagent, but is is simply trying to
introduce clojurescript to react?
Addressed this in my previous reply.
Is it also true to say that whilst om wants to manage the whole
application, reagent allows
