[ClojureScript] Meetup in SF
Hi all, New guy here. Fascinated by ClojureScript, and planning to make some contributions. I'm wondering what are the essential things that people want to have for the ideal meetup space? I'm asking because we have a really decent space at 150 California St and would like to help with hosting if the community needs a bigger space to attract more participants. I was led to the meetup by @sgrove who was kind enough to reply to a random tweet. Thanks and looking forward to engaging here. Marc -- 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] Conceptual question re: utility of virtual DOM in ClojureScript apps
<> Maybe a dumb question, but I'm trying to bridge two worlds. In one world, I have an optimized data structure for holding state of the UI (on app, component and individual element level) including data and properties specific to each element which I update (explicitly mutate) and from which the DOM is rendered (via render called on the component level with no argument or render(element) for applying latest state to the actual DOM elements, or passing on to a custom rendering scheme (e.g. WebGL, Canvas, non-DOM renderer) That's been my way for accomplishing state-driven polyglot rendering (dom and independent canvas/webgl widgets) I never have to render entire components or whole DOM if I don't want to. I render individual elements by applying the latest state on demand using optimized DOM manipulation. Mutating state does not automatically update the DOM but can send an event that another component listens to and in turn that component can update its state of the state and render itself, or any individual element within it by applying. There is more to the model, and it's a work in progress, although I have built very complex real time data visualizations using it. My struggle is to understand how to think about the Virtual DOM in React, and while that may be better question for the React mailing list, I have a feeling that folks on this list would have a broader view on things. Specifically, what does Reagent or Om buy me in terms of sanitizing the architecture of the app that I'm not getting by isolating app state from the DOM and rendering individual elements directly based on the state object? I'm digging into Reagent and React, as well as taking on the ClojureScript learning curve. But I need to understand why virtual DOM and tree diff-ing is needed if you have (like in my case) already isolated app state from the DOM and have extremely performant state-driven, on-demand or event-driven per-element rendering. I suspect the answer has to do with core FP paradigm that I've not been considering, and if so I want to know what the paradigm is. Thank you so much for any thoughts. I can post my own JS code with a short notice (needs cleaning up etc) if that helps. Marc -- 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] Conceptual question re: utility of virtual DOM in ClojureScript apps
Ah. Making things easy, with some magic. I wonder what the caveats are. I appreciate your answer. It's the same I got from my CTO/mentor, who is very psyched about Reagent. I wonder what gotchas exist beneath all this, but that's work for me to catch up with React. Thank you very much Mike! nice to meet you virtually. Marc On Wed, Jan 21, 2015 at 2:44 PM, Mike Haney wrote: > The short answer is that React is doing the heavy lifting for you. > Conceptually, you can just think of it as your app rendering the entire DOM > on every state change. It is a very functional approach, because you can > think of rendering as a pure function that takes your app state as input > and returns a DOM. > > React uses DOM diffing to make this model work without killing > performance. Clojurescript wrappers like Om and Reagent can optimize this > further by using the efficiency of equality checks on immutable data > structures to cheaply calculate precisely when to tell React it should > update a component. > > -- > 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] Conceptual question re: utility of virtual DOM in ClojureScript apps
The only thing novel to me (vs my own way) is that after updating state I don't have to explicitly call render on the corresponding element(s) ... it guesses by computing a diff but I am not sure what that buys me besides beautiful functional code ... On Wed, Jan 21, 2015 at 5:23 PM, Mike Haney wrote: > Always glad to help. > > Probably the biggest caveat with React is that you have to break old > habits of trying to directly manipulate the DOM, and be careful with other > libraries like jQuery that directly manipulate the DOM. It is possible to > integrate things like jQuery components with React, but it has to be done > in a specific way. > > A simple example - suppose you have a drop-down menu that is toggled > open/closed by setting a css class on the parent DOM element (pretty > standard stuff). Using something like jQuery, you would have an onClick > handler that directly adds or removes the class as needed. > > With React, you can't (easily) do that, nor should you. Instead, your > event handler would update application state, or maybe send a message to > some dispatcher that then updates state for you (depending on how > sophisticated your architecture needs to be). Your React component in this > case would check application state for this flag you have set, and add the > appropriate css class when needed. So whether or not this this css class > gets set depends on the state passed to your component at the time a render > is requested. In the case of Om and Reagent, the render would have been > triggered when you modified the state, so the results will be seen right > away. > > So with React, your entire app UI becomes a declarative specification of > what to render given a particular app state, which is refreshingly easy to > reason about. > > -- > 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] Conceptual question re: utility of virtual DOM in ClojureScript apps
sure, it's work in progress, and for now showing use of D3 widget written independently (using D3's own reusable component pattern) and simply hooking into the state layer (which holds the data for the chart as well as the pan/zoom of the brush on the chart) which it is then rendered from (by the D3 widget itself)... that 'bridging' is specified as a custom rendering scheme which could also be done for any independent/3rd party canvas or webgl widget... the changes to the d3 chart are two lines to store state in the state layer I provide .. same would be for any webgl or canvas widget, i.e. minimal code to hook into the state layer ... I'm looking at the ClojureScript atom and the Reagent ratom version to learn more I'll post the github link by Monday, needs some comments and cleaning up On Wed, Jan 21, 2015 at 8:16 PM, Mike Haney wrote: > Well, Reagent and Om will trigger the renders for you as well, and even > batch renders. > > What sounds novel about your approach is doing the same thing for canvas > and webgl. Are you saying you have a library that does this for the dom, > canvas, and webgl all at once? That I would be interested in seeing. > > -- > 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] Conceptual question re: utility of virtual DOM in ClojureScript apps
actually I realize now why the virtual dom is so cool in an FP paradigm like ClojureScript: it simply orients you toward data and UI state and you never have to even map back to the DOM ... having said that, I bet that I can find a similar way to achieve the same purpose without the magic of virtual dom ... but it won't be as pleasant ... we'll see .. will post my code over the weekend On Thu, Jan 22, 2015 at 6:26 AM, Marc Fawzi wrote: > sure, it's work in progress, and for now showing use of D3 widget written > independently (using D3's own reusable component pattern) and simply > hooking into the state layer (which holds the data for the chart as well as > the pan/zoom of the brush on the chart) which it is then rendered from (by > the D3 widget itself)... that 'bridging' is specified as a custom rendering > scheme which could also be done for any independent/3rd party canvas or > webgl widget... the changes to the d3 chart are two lines to store state in > the state layer I provide .. same would be for any webgl or canvas widget, > i.e. minimal code to hook into the state layer ... > > I'm looking at the ClojureScript atom and the Reagent ratom version to > learn more > > I'll post the github link by Monday, needs some comments and cleaning up > > > > On Wed, Jan 21, 2015 at 8:16 PM, Mike Haney wrote: > >> Well, Reagent and Om will trigger the renders for you as well, and even >> batch renders. >> >> What sounds novel about your approach is doing the same thing for canvas >> and webgl. Are you saying you have a library that does this for the dom, >> canvas, and webgl all at once? That I would be interested in seeing. >> >> -- >> 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] Clojurescript Experience Poll, please participate!
Thank you Leila Will pass this on to our devs, lots of hairy pulling here around simple things like string matching... for people with killer JS skills the simple stuff is the most challenging , but to us CLJS and Reagent are such a fresh and elegant approach that we're looking past the issue of the knowledge gap and learning curve and source maps, trying to get it to work here . my first couple of days with CLJS Will fill out the survey and ask others to do the same On Fri, Jan 23, 2015 at 10:58 AM, Leila Hamon wrote: > Hi, there's a poll I would like everyone to take when you have free time: > http://www.polljunkie.com/poll/ibxsde/clojurecript-experience-poll > > Thank you! > > -- > 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] Clojurescript Experience Poll, please participate!
No, but we will! Looks good and pretty detailed ... I am hoping that there are enough libraries out there that we won't have to use JS from cljs Thank you much for the tip! Sent from my iPhone > On Jan 23, 2015, at 10:36 PM, gvim wrote: > >> On 23/01/2015 19:29, Marc Fawzi wrote: >> Thank you Leila >> >> Will pass this on to our devs, lots of hairy pulling here around simple >> things like string matching... for people with killer JS skills the >> simple stuff is the most challenging , but to us CLJS and Reagent are >> such a fresh and elegant approach that we're looking past the issue of >> the knowledge gap and learning curve > > Have you tried cuerdas? > > https://github.com/funcool/cuerdas > > 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. -- 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] having trouble with source maps
at work, we've implemented a few features/pages in cljs without source map
support.. to me that's like using the force, but we know we will eventually
get stuck trying to fix a bug that we can't trace to the code manually
so we need source map support asap to smooth out the cljs adoption process
at our company
the way we develop is by running "lein cljsbuild auto dev" and refreshing
the browser once we make changes (figwheel is on my list of tools to
investigate)
anyway, the problem is with source maps
We run node or python based web server to serve index.html (see below) and
we inherited this sample project.clj file
(defproject CHANGE-ME-ME "0.1.0-SNAPSHOT"
:description "CHANGE-ME"
:url "https://CHANGE-ME";
:dependencies [[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2280"]
[reagent "0.4.2"]
[cljs-ajax "0.2.6"]]
:plugins [[lein-environ "0.5.0"]
[lein-cljsbuild "1.0.3"]]
:cljsbuild {:builds [{:id "dev"
:source-paths ["src"]
:compiler {:optimizations :none
:output-to "public/dev/app.js"
:output-dir "public/dev/"
:source-map true}}
{:id "prod"
:source-paths ["src"]
:compiler {:optimizations :advanced
:output-to "public/js/app.js"
:pretty-print false}}
]}
:min-lein-version "2.0.0")
The index.html is
Reagent Starter Project
http://fb.me/react-0.12.1.min.js";>
goog.require("main.core");
I have not used anything but pure JS before so I'm not sure what to do to
get source maps working but as of now they are enabled in chrome but
exceptions are displayed in the console in cljs/reagent JS sources like
ratom.js and not in the cljs file
I read the wiki on source maps and tried using source-map-path but that
didn't work
does anyone have an example of source maps that works with a web server?
any pointers will be appreciated
very frustrating and nerve wrecking that we ca't debug cljs sources
help!
Thank you in advance
Marc
--
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] having trouble with source maps
I did some reading on enabling source maps for other languages (more
material exists for e.g. coffeescript) and I think the problem is that lein
cljsbuild is not adding that special comment to index.html to tell the
browser about the source map
//# sourceMappingURL=/path/to/file.js.map
in this case "dev/main/core.js.map"
http://fb.me/react-0.12.1.min.js"</a>;>
goog.require("main.core");
But shouldn't goog.require be smart enough to add that? I have no idea
since I've never used goog.* or the Closure compiler
It's it lein's job to put that special comment line or is it Google's
Closure's job? Or how does the line get added? We're definitely not sending
an X header for source maps, so we must have that special comment
(according to what I read)
What am I missing here?
On Sat, Jan 24, 2015 at 4:31 PM, David Nolen wrote:
> Are you sure the source maps are accessible to the browser? You should see
> them getting loaded in the Network tab.
>
> David
>
> On Sat, Jan 24, 2015 at 7:20 PM, Marc Fawzi wrote:
>
>>
>> at work, we've implemented a few features/pages in cljs without source
>> map support.. to me that's like using the force, but we know we will
>> eventually get stuck trying to fix a bug that we can't trace to the code
>> manually
>>
>> so we need source map support asap to smooth out the cljs adoption
>> process at our company
>>
>> the way we develop is by running "lein cljsbuild auto dev" and
>> refreshing the browser once we make changes (figwheel is on my list of
>> tools to investigate)
>>
>> anyway, the problem is with source maps
>>
>> We run node or python based web server to serve index.html (see below)
>> and we inherited this sample project.clj file
>>
>> (defproject CHANGE-ME-ME "0.1.0-SNAPSHOT"
>> :description "CHANGE-ME"
>> :url "https://CHANGE-ME";
>> :dependencies [[org.clojure/clojure "1.6.0"]
>> [org.clojure/clojurescript "0.0-2280"]
>> [reagent "0.4.2"]
>> [cljs-ajax "0.2.6"]]
>>
>> :plugins [[lein-environ "0.5.0"]
>> [lein-cljsbuild "1.0.3"]]
>>
>> :cljsbuild {:builds [{:id "dev"
>> :source-paths ["src"]
>> :compiler {:optimizations :none
>>:output-to "public/dev/app.js"
>>:output-dir "public/dev/"
>>:source-map true}}
>>{:id "prod"
>> :source-paths ["src"]
>> :compiler {:optimizations :advanced
>>:output-to "public/js/app.js"
>>:pretty-print false}}
>>]}
>>
>> :min-lein-version "2.0.0")
>>
>> The index.html is
>>
>>
>>
>>
>>
>> Reagent Starter Project
>>
>>
>>
>>
>>
>>
>>
>> http://fb.me/react-0.12.1.min.js"</a>;>
>>
>>
>> goog.require("main.core");
>>
>>
>>
>> I have not used anything but pure JS before so I'm not sure what to do to
>> get source maps working but as of now they are enabled in chrome but
>> exceptions are displayed in the console in cljs/reagent JS sources like
>> ratom.js and not in the cljs file
>>
>> I read the wiki on source maps and tried using source-map-path but that
>> didn't work
>>
>> does anyone have an example of source maps that works with a web server?
>>
>> any pointers will be appreciated
>>
>> very frustrating and nerve wrecking that we ca't debug cljs sources
>>
>> help!
>>
>> Thank you in advance
>>
>> Marc
>>
>>
>>
>>
>> --
>> 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.
>&g
Re: [ClojureScript] having trouble with source maps
David,
Thank you that worked like a charm!
With source maps the only inconvenience it seems that it points to the line
where the buggy function is being called, and not to the function's
definition
For example (sorry that this is a reagent sample, have yet to check out Om)
I would expect it to point to the line that reads: [:did.sample ]) since
there is no such HTML tag as 'did' ('div' is what it should be obviously)
but the console error (when i click at the last entry in the call stack --
the one before it is in Reagent somewhere) it points to the line that
reads: (reagent/render-component [app-view] (.getElementById js/document
"app"))
I suspect that either my brain is fried and that's how it works in regular
JS or it's a general issue with source maps
(ns main.core
(:require [reagent.core :as reagent :refer [atom]]
[ajax.core :as ajax]))
(defn app-view []
[:did.sample ])
(reagent/render-component [app-view] (.getElementById js/document "app"))
On Sun, Jan 25, 2015 at 6:25 AM, David Nolen wrote:
> The :source-map option is in the project.clj he pasted.
>
> Marc if the source-map url is missing from the end of the file it sounds
> like something went wrong with the compile. In these situations it's best
> to run a clean and then re-build. Have you tried that?
>
> On Sun, Jan 25, 2015 at 9:08 AM, Moritz Ulrich
> wrote:
>
>> Marc Fawzi writes:
>>
>> > I did some reading on enabling source maps for other languages (more
>> > material exists for e.g. coffeescript) and I think the problem is that
>> lein
>> > cljsbuild is not adding that special comment to index.html to tell the
>> > browser about the source map
>> >
>> > //# sourceMappingURL=/path/to/file.js.map
>> >
>> > in this case "dev/main/core.js.map"
>> >
>> >
>> > http://fb.me/react-0.12.1.min.js"</a>;>
>> >
>> >
>> > goog.require("main.core");
>> >
>> > But shouldn't goog.require be smart enough to add that? I have no idea
>> > since I've never used goog.* or the Closure compiler
>> >
>> > It's it lein's job to put that special comment line or is it Google's
>> > Closure's job? Or how does the line get added? We're definitely not
>> sending
>> > an X header for source maps, so we must have that special comment
>> > (according to what I read)
>> >
>> > What am I missing here?
>> >
>> >
>> > On Sat, Jan 24, 2015 at 4:31 PM, David Nolen
>> wrote:
>> >
>> >> Are you sure the source maps are accessible to the browser? You should
>> see
>> >> them getting loaded in the Network tab.
>> >>
>> >> David
>> >>
>> >> On Sat, Jan 24, 2015 at 7:20 PM, Marc Fawzi
>> wrote:
>> >>
>> >>>
>> >>> at work, we've implemented a few features/pages in cljs without source
>> >>> map support.. to me that's like using the force, but we know we will
>> >>> eventually get stuck trying to fix a bug that we can't trace to the
>> code
>> >>> manually
>> >>>
>> >>> so we need source map support asap to smooth out the cljs adoption
>> >>> process at our company
>> >>>
>> >>> the way we develop is by running "lein cljsbuild auto dev" and
>> >>> refreshing the browser once we make changes (figwheel is on my list of
>> >>> tools to investigate)
>> >>>
>> >>> anyway, the problem is with source maps
>> >>>
>> >>> We run node or python based web server to serve index.html (see below)
>> >>> and we inherited this sample project.clj file
>> >>>
>> >>> (defproject CHANGE-ME-ME "0.1.0-SNAPSHOT"
>> >>> :description "CHANGE-ME"
>> >>> :url "https://CHANGE-ME";
>> >>> :dependencies [[org.clojure/clojure "1.6.0"]
>> >>> [org.clojure/clojurescript "0.0-2280"]
>> >>> [reagent "0.4.2"]
>> >>> [cljs-ajax "0.2.6"]]
>> >>>
>> >>> :plugins [[lein-environ "0.5.0"]
>> >>> [lein-cljsbuild "1.0.3"]]
>> >>>
>> >>> :cljsbuild {:builds [{:id "dev"
>> >>> :source-pat
Re: [ClojureScript] having trouble with source maps
Unfortunately, the exception is caught by Reagent not my cljs code and so
enabling Pause on Caught Exceptions in Chrome takes me to template.cljs
(which I'm assuming is part of the Reagent implementation)
I tried setting a breakpoint on the offending line and stepping thru and
the same thing happened: I ended up in template.cljs at the end.
But source maps are heaven sent because at least I know where the bug is
coming from even if it does not point to the offending line in the function
being called (it points at the line where that function itself is being
called)
Having said that, I'm just curious now, not blocked or anything
Love the clarity of the language/programming model
On Sun, Jan 25, 2015 at 8:52 AM, David Nolen wrote:
> That's just how JavaScript error stack traces & source mapping works. If
> you need to drill down then it's best to enable the exception catching mode
> of the browser JavaScript debugger. When the error occurs you'll be taken
> to the offending ClojureScript file. You can navigate the ClojureScript
> source mapped stack using the standard debugging tools provided by the
> browser.
>
> David
>
> On Sun, Jan 25, 2015 at 11:47 AM, Marc Fawzi wrote:
>
>> David,
>>
>> Thank you that worked like a charm!
>>
>> With source maps the only inconvenience it seems that it points to the
>> line where the buggy function is being called, and not to the function's
>> definition
>>
>> For example (sorry that this is a reagent sample, have yet to check out
>> Om) I would expect it to point to the line that reads: [:did.sample ])
>> since there is no such HTML tag as 'did' ('div' is what it should be
>> obviously) but the console error (when i click at the last entry in the
>> call stack -- the one before it is in Reagent somewhere) it points to the
>> line that reads: (reagent/render-component [app-view] (.getElementById
>> js/document "app"))
>>
>> I suspect that either my brain is fried and that's how it works in
>> regular JS or it's a general issue with source maps
>>
>> (ns main.core
>> (:require [reagent.core :as reagent :refer [atom]]
>> [ajax.core :as ajax]))
>>
>> (defn app-view []
>> [:did.sample ])
>>
>> (reagent/render-component [app-view] (.getElementById js/document "app"))
>>
>>
>>
>> On Sun, Jan 25, 2015 at 6:25 AM, David Nolen
>> wrote:
>>
>>> The :source-map option is in the project.clj he pasted.
>>>
>>> Marc if the source-map url is missing from the end of the file it sounds
>>> like something went wrong with the compile. In these situations it's best
>>> to run a clean and then re-build. Have you tried that?
>>>
>>> On Sun, Jan 25, 2015 at 9:08 AM, Moritz Ulrich
>>> wrote:
>>>
>>>> Marc Fawzi writes:
>>>>
>>>> > I did some reading on enabling source maps for other languages (more
>>>> > material exists for e.g. coffeescript) and I think the problem is
>>>> that lein
>>>> > cljsbuild is not adding that special comment to index.html to tell the
>>>> > browser about the source map
>>>> >
>>>> > //# sourceMappingURL=/path/to/file.js.map
>>>> >
>>>> > in this case "dev/main/core.js.map"
>>>> >
>>>> >
>>>> > http://fb.me/react-0.12.1.min.js"</a>;>
>>>> >
>>>> >
>>>> > goog.require("main.core");
>>>> >
>>>> > But shouldn't goog.require be smart enough to add that? I have no idea
>>>> > since I've never used goog.* or the Closure compiler
>>>> >
>>>> > It's it lein's job to put that special comment line or is it Google's
>>>> > Closure's job? Or how does the line get added? We're definitely not
>>>> sending
>>>> > an X header for source maps, so we must have that special comment
>>>> > (according to what I read)
>>>> >
>>>> > What am I missing here?
>>>> >
>>>> >
>>>> > On Sat, Jan 24, 2015 at 4:31 PM, David Nolen
>>>> wrote:
>>>> >
>>>> >> Are you sure the source maps are accessible to the browser? You
>>>> should see
>>>> >> them getting loaded in the Network tab.
>>>> >>
>>>> >> David
>>>> >>
>&
Re: [ClojureScript] having trouble with source maps
<<
I tried setting a breakpoint on the offending line and stepping thru and
the same thing happened: I ended up in template.cljs at the end.
>>
correction:
I actually set the breakpoint on the line where the function with the
offending line is being called, not on the offending line itself as Chrome
kept removing the breakpoint when I put it next to the offending line
(right after I set it)
Visually:
(ns main.core
(:require [reagent.core :as reagent :refer [atom]]
[ajax.core :as ajax]))
(defn app-view []
*--> tried to put the break point right here but I guess I can't break
here as chrome kept removing it... the syntax is foreign to me still
so it **probably
makes sense*
[:did.sample "..."])
*---> the next line is where the chrome web console shows the error
(without pause on exceptions being enabled) and if I set a break point here
I end up in template.cljs, and doesn't come back to the offending line
above *
(reagent/render-component [app-view] (.getElementById js/document "app"))
I'm sure all of this makes sense since this gets compiled to JS and if I
was to debug the JS then it would all make sense !
On Sun, Jan 25, 2015 at 5:46 PM, Marc Fawzi wrote:
> Unfortunately, the exception is caught by Reagent not my cljs code and so
> enabling Pause on Caught Exceptions in Chrome takes me to template.cljs
> (which I'm assuming is part of the Reagent implementation)
>
> I tried setting a breakpoint on the offending line and stepping thru and
> the same thing happened: I ended up in template.cljs at the end.
>
> But source maps are heaven sent because at least I know where the bug is
> coming from even if it does not point to the offending line in the function
> being called (it points at the line where that function itself is being
> called)
>
> Having said that, I'm just curious now, not blocked or anything
>
> Love the clarity of the language/programming model
>
> On Sun, Jan 25, 2015 at 8:52 AM, David Nolen
> wrote:
>
>> That's just how JavaScript error stack traces & source mapping works. If
>> you need to drill down then it's best to enable the exception catching mode
>> of the browser JavaScript debugger. When the error occurs you'll be taken
>> to the offending ClojureScript file. You can navigate the ClojureScript
>> source mapped stack using the standard debugging tools provided by the
>> browser.
>>
>> David
>>
>> On Sun, Jan 25, 2015 at 11:47 AM, Marc Fawzi
>> wrote:
>>
>>> David,
>>>
>>> Thank you that worked like a charm!
>>>
>>> With source maps the only inconvenience it seems that it points to the
>>> line where the buggy function is being called, and not to the function's
>>> definition
>>>
>>> For example (sorry that this is a reagent sample, have yet to check out
>>> Om) I would expect it to point to the line that reads: [:did.sample
>>> ]) since there is no such HTML tag as 'did' ('div' is what it should be
>>> obviously) but the console error (when i click at the last entry in the
>>> call stack -- the one before it is in Reagent somewhere) it points to the
>>> line that reads: (reagent/render-component [app-view] (.getElementById
>>> js/document "app"))
>>>
>>> I suspect that either my brain is fried and that's how it works in
>>> regular JS or it's a general issue with source maps
>>>
>>> (ns main.core
>>> (:require [reagent.core :as reagent :refer [atom]]
>>> [ajax.core :as ajax]))
>>>
>>> (defn app-view []
>>> [:did.sample ])
>>>
>>> (reagent/render-component [app-view] (.getElementById js/document "app"))
>>>
>>>
>>>
>>> On Sun, Jan 25, 2015 at 6:25 AM, David Nolen
>>> wrote:
>>>
>>>> The :source-map option is in the project.clj he pasted.
>>>>
>>>> Marc if the source-map url is missing from the end of the file it
>>>> sounds like something went wrong with the compile. In these situations it's
>>>> best to run a clean and then re-build. Have you tried that?
>>>>
>>>> On Sun, Jan 25, 2015 at 9:08 AM, Moritz Ulrich
>>>> wrote:
>>>>
>>>>> Marc Fawzi writes:
>>>>>
>>>>> > I did some reading on enabling source maps for other languages (more
>>>>> > material exists for e.g. coffeescript) and I think the problem is
>>>>> that lein
>>>>> > cljsbuild is not adding that sp
Re: [ClojureScript] Server side reagent example
Will run it tonight or by tomorrow night the latest with something substantial (in terms of DOM manipulation) and let you know :) Would be fun to try and throw in a D3 component (HTML container element managed by Reagent but DOM subtree by D3 directly) and see if we can have our ClojureScript and eat it http://www.smashingmagazine.com/2014/05/26/love-generating-svg-javascript-move-to-server/ On Mon, Jan 26, 2015 at 3:16 PM, Matt Ho wrote: > After trying to work through some examples of how to get reagent running > on the server side, I opted to create a small project PoC. Here's a first > cut. > > https://github.com/savaki/reagent-nodejs > > Any comments or suggestions would be greatly appreciated. > > Thanks! > > M > > -- > 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] I made this SPA before I knew about React and ClojureScript (gasp!)
So I was supposed to have done this one the weekend but my 20 month old baby girl objected. I've finally managed to clean up the project and comments so that it is understandable to others. It's a learning project that has taught me: 1) the importance of Real FP (as opposed to sprinkling FP patterns through out, and missing our on core essential concepts) 2) the risks of over thinking the problem 3) the risks of under thinking the problem 4) stepping out of your own [frame]work every now and then and getting some fresh air (in this case ClojureScript + Reagent) Here is my in-retrospect-embarrassing attempt at state driven polyglot rendering Github: https://github.com/idibidiart/stateful Youtube: << WATCH ME FIRST >> https://www.youtube.com/watch?v=UacbvV4GpYk What the video demonstrates: 1. Single Page App (SPA) framework based that supports stateful UI components with independenlty developed HTML/CSS/JS, D3/SVG, Canvas or WebGL widgets (the code has a D3 widget example used in a stateful component) It stores all UI state as well as all derived data (e.g. data that has been transformed and made consuable by some widget) which can be accessed by value (immutable) or by reference (mutable) It remembers the entire state of each page, thus allowing for things such as state transfer (between users at the component or page scope) as well as recording and replay of user interaction. 2. Parallel fetching data and storing in state model prior to rendering the entire page all at once upon page transition, so new and old pages appear instantly. Usually, SPAs transition to the page then render it in piecemeal fashion after the page has already been transitioned to, leading to an ugly experience. The key is that everything appears instantly in both forward and back directions (new pages and previous pages are rendered from optimized state object data structure that has already been populated with data) What the video doesn't show but is already implemented and can be seen in the code: 1. You may choose HTML, SVG, Canvas, WebGL or any technology available from the Javascript environment with Stateful.JS and get the benefits of stateful rendering for free. In other words, using Stateful.JS you only work with the app's state via an optimized state object, and not directly embedding state into the DOM (HTML or SVG), or individual data structures in case of Canvas and WebGL. The UI components, which can include independently developed widgets (in any technology, e.g. SVG or WebGL) are rendered onto the DOM from the state object (the root HTML elements in case of Canvas, SVG and WebGL), so the main architectural advantage here is not only the separation of state from the DOM but also the separation of state from the rendering technology. This is achieved at the developer level by specifying Rendering Scheme that may use whatever technology to draw on the screen and handle UI events while having the state of the app in one data structure outside of the view and independent of the rendering technology. Stateful.JS was designed for real world scenarios where UI components built in a completely different technology, not just different component model, may be utilized, with the benefit of retaining state outside of the view (the view will still have its own state in the HTML or SVG DOM, Canvas, or WebGL, but it flows in one direction from the state object to the DOM and widgets attached to the view's DOM tree. Stateful.JS does not have "data models" like in Backbone, but an optimized data structure for storing state and derived data. The raw data received from the server would be stored in a caching layer like IndexedDB with user developed NoSQL query API [I have something in the works, too]) 2. StatefulJS llows Designers to work with HTML or SVG DOM tree prototypes which are then expanded into the actual rendered structures. The renderer is blazing fast and does not use string concatenation. Use pre-existing framework-independent HTML/SVG/Canvas/WebGL widgets in Stateful.JS components: See the D3-powered chartWidget.js and the ListView Stateful.JS component in components.js for an example of using pre-existing, framework-indepedent D3 widget inside of Stateful.JS components. Similarly, framework-independent HTML, Canvas and WebGL components (developed with any library) maybe used inside of Stateful.JS components. What is next: Implementing the current persistent chart widget example with Canvas and WebGL (click more in search results to see current example using a D3 widget) -- 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
Re: [ClojureScript] Conceptual question re: utility of virtual DOM in ClojureScript apps
So I was supposed to have done this one the weekend but my 20 month old baby girl objected. I've finally managed to clean up the project and comments so that it is understandable to others. It's a learning project that has taught me: 1) the importance of Real FP (as opposed to sprinkling FP patterns through out, and missing our on core essential concepts) 2) the risks of over thinking the problem 3) the risks of under thinking the problem 4) stepping out of your own [frame]work every now and then and getting some fresh air (in this case ClojureScript + Reagent) Here is my in-retrospect-embarrassing attempt at state driven polyglot rendering Github: https://github.com/idibidiart/stateful Youtube: << WATCH ME FIRST >> https://www.youtube.com/watch?v=UacbvV4GpYk What the video demonstrates: Single Page App (SPA) framework based that supports stateful UI components with independenlty developed HTML/CSS/JS, D3/SVG, Canvas or WebGL widgets (the code has a D3 widget example used in a stateful component) It stores all UI state as well as all derived data (e.g. data that has been transformed and made consuable by some widget) which can be accessed by value (immutable) or by reference (mutable) It remembers the entire state of each page, thus allowing for things such as state transfer (between users at the component or page scope) as well as recording and replay of user interaction. Parallel fetching data and storing in state model prior to rendering the entire page all at once upon page transition, so new and old pages appear instantly. Usually, SPAs transition to the page then render it in piecemeal fashion after the page has already been transitioned to, leading to an ugly experience. The key is that everything appears instantly in both forward and back directions (new pages and previous pages are rendered from optimized state object data structure that has already been populated with data) What the video doesn't show but is already implemented and can be seen in the code: You may choose HTML, SVG, Canvas, WebGL or any technology available from the Javascript environment with Stateful.JS and get the benefits of stateful rendering for free. In other words, using Stateful.JS you only work with the app's state via an optimized state object, and not directly embedding state into the DOM (HTML or SVG), or individual data structures in case of Canvas and WebGL. The UI components, which can include independently developed widgets (in any technology, e.g. SVG or WebGL) are rendered onto the DOM from the state object (the root HTML elements in case of Canvas, SVG and WebGL), so the main architectural advantage here is not only the separation of state from the DOM but also the separation of state from the rendering technology. This is achieved at the developer level by specifying Rendering Scheme that may use whatever technology to draw on the screen and handle UI events while having the state of the app in one data structure outside of the view and independent of the rendering technology. Stateful.JS was designed for real world scenarios where UI components built in a completely different technology, not just different component model, may be utilized, with the benefit of retaining state outside of the view (the view will still have its own state in the HTML or SVG DOM, Canvas, or WebGL, but it flows in one direction from the state object to the DOM and widgets attached to the view's DOM tree. Stateful.JS does not have "data models" like in Backbone, but an optimized data structure for storing state and derived data. The raw data received from the server would be stored in a caching layer like IndexedDB with user developed NoSQL query API [I have something in the works, too]) StatefulJS llows Designers to work with HTML or SVG DOM tree prototypes which are then expanded into the actual rendered structures. The renderer is blazing fast and does not use string concatenation. Use pre-existing framework-independent HTML/SVG/Canvas/WebGL widgets in Stateful.JS components: See the D3-powered chartWidget.js and the ListView Stateful.JS component in components.js for an example of using pre-existing, framework-indepedent D3 widget inside of Stateful.JS components. Similarly, framework-independent HTML, Canvas and WebGL components (developed with any library) maybe used inside of Stateful.JS components. What is next: Implementing the current persistent chart widget example with Canvas and WebGL (click more in search results to see current example using a D3 widget) On Friday, 23 January 2015 11:27:50 UTC-8, marc fawzi wrote: > actually I realize now why the virtual dom is so cool in an FP paradigm like > ClojureScript: it simply orients you toward data and UI state and you never > have to even map back to the DOM ... > > > having said that, I bet that I can find a similar way to ach
Re: [ClojureScript] Conceptual question re: utility of virtual DOM in ClojureScript apps
I look forward to further understanding from my mistakes :) Thank you. ClojureScript+Reagent combination is a whole new level of thinking. Absolutely convinced there is something big happening here with front end development. On Wed, Jan 28, 2015 at 2:29 PM, Mike Haney wrote: > Don't be embarrassed- even if you think it's over engineered or won't work > out or whatever, you still tried something different - that's more than 90% > of people can say. I've been curious about your approach since you first > mentioned it, even though I wondered about its feasibility. I'm glad you > followed through and had the guts to post it, and I look forward to > checking it out. > > -- > 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] ANN: ClojureScript Jobs group
>From the welcome message: As the community of ClojureScript developers grows in size companies and recruiters from all places will want to communicate job opportunities to potential job seekers. While the members of ClojureScript google group may tolerable that when the volume of such posts is low it can get annoying over time. This group was started as a place for recruiters and companies to reach job seekers without polluting the technical discussions space on the main ClojureScript google group. Link to join: https://groups.google.com/forum/?fromgroups#!forum/clojurescript-jobs Once joined, you may post jobs by emailing to: clojurescript-j...@googlegroups.com My previous experience comes from being an early member of the D3 community. At first we had a very small community, then it exploded in size and a lot of people joined including and we started seeing job posts on the main thread which were often disruptive to ongoing discussions. Thus, the D3 jobs group was created. I'm siply replicating that pattern in anticipation of the same issue coming up as the community grows. Marc -- 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] [ANN] Cuttle - a ClojureScript user tool
Awesome, especially the choice of Atom Shell! Will log any issues on the repo. On Fri, Jan 30, 2015 at 10:25 AM, Chris Oakman wrote: > We are excited to announce the first release of Cuttle: > https://github.com/oakmac/cuttle/ > > Cuttle is a standalone application for Linux, Mac, and Windows that aims > to be the simplest way to use ClojureScript. > > We look forward to your feedback :) > > Thanks, > Chris & Shaun > > -- > 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] React.js Relay
At a very high level, if I understood correctly from a super fast glance :) each component would be responsible for fetching its data. If that is true (even if not the main point) then it means that the component is rendered (does not mean in a visible state) first before the data is fetched then how is that state-driven rendering? There is a lot of power in working with state and then having things render from there as opposed to rendering things first then building state. It seems flawed to me, but if my understanding is wrong then please ignore me. Sent from my iPhone > On Jan 31, 2015, at 12:57 PM, Mike Haney wrote: > > I'm not really interested in their specific implementation, but the overall > approach is interesting. I'm not interested in using GraphQL - we already > have good options for describing the shape of our data, like Herbert and > Schema. If you use Datomic, there's even the option to build your queries > dynamically on the client. > > So the approach is interesting, but we have even better tools to do this in > Clojure. > > -- > 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] React.js Relay
That is interesting, but doesn't the model where components declare what data they fail in cases where the decision of which component to display is driven by the data? In other ways, it may satisfy 98% of all scenarios but fail when the UI is not only data driven but data generated. On Sat, Jan 31, 2015 at 9:52 PM, Dave Sann wrote: > Marc, > > I believe that the core idea is that to component specifies the data it > needs - via a query (this is static). This is then composed up the > hierarchy to generate the overall data query and to ensure that data passed > back down the hierarchy contains required data in the required structure. > > The aim is to stop cascading code changes in nested components when data > needs change. > > They also suggest that these definitions of required data can allow global > optimisation of what data is fetched when. > > I think that these are interesting ideas and may have wider applicability > > Dave > > -- > 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] React.js Relay
I've had cases in data visualization/analytics apps where the server was in charge of interpreting user intent (via NLP input) and so the client didn't know what to request in terms of data. The server threw data at it and described the user intent along with it and based on both data types and intent the client decided what to render. This I consider a very rare situation in UI development, but it would be hard to reason about and/or implement efficiently using the concept if Relays as I understand it from your nice summary ... Sent from my iPhone > On Jan 31, 2015, at 11:24 PM, Dave Sann wrote: > > Does the client have a priori knowledge of the server data? Or, is it just > requesting the data it requires? > > On data driven UI's, Is there anything in the model that prevents you making > decisions on what to render based on the data (or data merged with other > particular application state)? Is this so different from the way components > are already composed with React/OM? I currently don't use om/react so not > sure. > > Dave > > -- > 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] React.js Relay
Yeah I was going to ask at which point will projects like Om and Reagent decide to fork React... Sent from my iPhone > On Feb 1, 2015, at 6:28 AM, gvim wrote: > >> On 01/02/2015 07:24, Dave Sann wrote: >> Does the client have a priori knowledge of the server data? Or, is it just >> requesting the data it requires? >> >> On data driven UI's, Is there anything in the model that prevents you making >> decisions on what to render based on the data (or data merged with other >> particular application state)? Is this so different from the way components >> are already composed with React/OM? I currently don't use om/react so not >> sure. >> >> Dave > > Whilst Facebook's fountain of new technologies (React, Flux, Relay) solves > some problems they move development further and further away from Rich > Hickey's simplicity principle with every addition which is why I'm wondering > how long the React-based approaches will remain relevant to Clojurescript. At > what point will a pure-Clojurescript approach prevail? Front-end JS > development is falling down a black of hole of over-engineering - or maybe > it's just Facebook/React. Either way Clojurescript is in a unique position to > cut through all this using it's killer feature - macros. Maybe it's time for > Clojurescript to stand up and say "We can make it simpler than React + Flux + > Relay + ". > > 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. -- 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] React.js Relay
If you fork React today before Relays are added, wouldn't you get the benefits that React has to offer up till this point? Even Node got forked, but for completely different reasons. On Sun, Feb 1, 2015 at 6:54 AM, Kyle Cordes wrote: > On Sunday, February 1, 2015 at 8:50 AM, Marc Fawzi wrote: > > Yeah I was going to ask at which point will projects like Om and Reagent > decide to fork React... > > > > I believe there is already a similar project that takes this approach. But > it has a significant challenge, it means not reusing the extensive work of > React to work correctly across the long history of semi-broken browsers. > Understanding and implementing dumb manipulation correctly across every > edge case is not the most fun work. > > > -- > Kyle Cordes > http://kylecordes.com > > > > -- > 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] React.js Relay
Not that the idea behind Relay does not make sense. It does, but there is at least one class of scenarios where it doesn't, or does not make *complete* sense. Just saying that it if the React team decides to add Relay into React as opposed to having it as an optional part of the "framework" then it might be worth looking into forking React to keep things simple. And of course I could be very wrong. On Sun, Feb 1, 2015 at 7:10 AM, Marc Fawzi wrote: > If you fork React today before Relays are added, wouldn't you get the > benefits that React has to offer up till this point? > > Even Node got forked, but for completely different reasons. > > On Sun, Feb 1, 2015 at 6:54 AM, Kyle Cordes wrote: > >> On Sunday, February 1, 2015 at 8:50 AM, Marc Fawzi wrote: >> > Yeah I was going to ask at which point will projects like Om and >> Reagent decide to fork React... >> > >> >> I believe there is already a similar project that takes this approach. >> But it has a significant challenge, it means not reusing the extensive work >> of React to work correctly across the long history of semi-broken browsers. >> Understanding and implementing dumb manipulation correctly across every >> edge case is not the most fun work. >> >> >> -- >> Kyle Cordes >> http://kylecordes.com >> >> >> >> -- >> 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] React.js Relay
So then back to you point about Transit ... I wonder why they're not looking at ClojureScript for inspiration and alignment. It seems to me that the best use of React is happening in the CLJS community. But maybe they are! Lee Byron presented on a React-like architecture for FB's iOS app at the last CLJS meetup less than 24 ours before the React Native announcement I hope they are warming up to the idea of closer cooperation with the CLJS ecosystem. I like that they're keeping new optional features optional, unlike other framework that keep adding bloat. And I'd love to see someone from the cljs community present at the next React Conference (hint! :) On Sun, Feb 1, 2015 at 7:17 AM, David Nolen wrote: > There is no intention as far as I could tell to add Relay to React as > anything other than an optional thing, same as JSX. > > Forking React or starting from scratch has less and less value each > passing day - React Native is a good example of the benefits of sticking > with a solid platform. > > David > > On Sun, Feb 1, 2015 at 10:14 AM, Marc Fawzi wrote: > >> Not that the idea behind Relay does not make sense. It does, but there is >> at least one class of scenarios where it doesn't, or does not make >> *complete* sense. >> >> Just saying that it if the React team decides to add Relay into React as >> opposed to having it as an optional part of the "framework" then it might >> be worth looking into forking React to keep things simple. >> >> And of course I could be very wrong. >> >> On Sun, Feb 1, 2015 at 7:10 AM, Marc Fawzi wrote: >> >>> If you fork React today before Relays are added, wouldn't you get the >>> benefits that React has to offer up till this point? >>> >>> Even Node got forked, but for completely different reasons. >>> >>> On Sun, Feb 1, 2015 at 6:54 AM, Kyle Cordes wrote: >>> >>>> On Sunday, February 1, 2015 at 8:50 AM, Marc Fawzi wrote: >>>> > Yeah I was going to ask at which point will projects like Om and >>>> Reagent decide to fork React... >>>> > >>>> >>>> I believe there is already a similar project that takes this approach. >>>> But it has a significant challenge, it means not reusing the extensive work >>>> of React to work correctly across the long history of semi-broken browsers. >>>> Understanding and implementing dumb manipulation correctly across every >>>> edge case is not the most fun work. >>>> >>>> >>>> -- >>>> Kyle Cordes >>>> http://kylecordes.com >>>> >>>> >>>> >>>> -- >>>> 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. >> > > -- > 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] React.js Relay
I think it's actually one of those discussions that can help those new to CLJS to understand the state of CLJS better by comparison with approaches like Relay. It should not marginalize scenarios that would be complicated, not simplified, by the use of the Relay approach, even if those scenarios are less common in practice. I think i's fair to cover all grounds when a new approach is brought up. I'm learning a lot from the debate here, and I'm sure others are, too :) On Sun, Feb 1, 2015 at 7:45 AM, Brendan Younger wrote: > There seems to be a strong strain of Lisp exceptionalism underlying a lot > of the responses in this thread. I don't think its profitable to assume > that ClojureScript is a superior language, therefore React and Relay must > be brought closer to ClojureScript, therefore we must fork them to make > them that way. I think that's the surest way to marginalize ClojureScript. > > There are some very interesting architectural points made by Relay's > architecture which I don't think are anywhere near "solved" in the current > ClojureScript ecosystem. > > * GraphQL is close to Datomic's new Pull sublanguage, but GraphQL has been > designed so that the backend code can easily transform its queries into > calls to a variety of datastores. I think it would be a great boon to the > Clojure community to have a unified library that understood something like > GraphQL/Datomic Pull and was easy to write adaptors for other data stores > as well. Implicit in this would be a way to manage access control for all > the levels of data. > > * Placing the queries inside the component itself at first seems > complected, but I currently live the "tab" example where I want new fields > on the front end, so I write some code to display them, then open a > different file to fetch them from the server, then open a different file to > provide them on the server. Ugh. > > * Although they didn't show any code, handling a mutation by sending the > new data along with a "refresher" query is about the best way I've yet come > up with to deal with mutated data. Think about it: let's say you insert a > row at index 2,000 in a large table view. The server can probably > calculate that the entire set of rows has changed, but how is it to know > which ones you're currently showing to the user? You could try to manage > subscriptions for views on your data, but that requires syncing more state, > or you could just punt and have the frontend explicitly calculate what it > expects to change and needs to know about and specifically ask for that. > > Anyway, that's my $0.02 from watching the presentation. > > Brendan Younger > > On Sunday, February 1, 2015 at 10:17:58 AM UTC-5, David Nolen wrote: > > There is no intention as far as I could tell to add Relay to React as > anything other than an optional thing, same as JSX. > > > > > > Forking React or starting from scratch has less and less value each > passing day - React Native is a good example of the benefits of sticking > with a solid platform. > > > > > > > > David > > > > > > On Sun, Feb 1, 2015 at 10:14 AM, Marc Fawzi wrote: > > > > Not that the idea behind Relay does not make sense. It does, but there > is at least one class of scenarios where it doesn't, or does not make > *complete* sense. > > > > > > Just saying that it if the React team decides to add Relay into React as > opposed to having it as an optional part of the "framework" then it might > be worth looking into forking React to keep things simple. > > > > > > And of course I could be very wrong. > > > > > > > > > > On Sun, Feb 1, 2015 at 7:10 AM, Marc Fawzi wrote: > > > > If you fork React today before Relays are added, wouldn't you get the > benefits that React has to offer up till this point? > > > > > > Even Node got forked, but for completely different reasons. > > > > > > > > > > On Sun, Feb 1, 2015 at 6:54 AM, Kyle Cordes > wrote: > > On Sunday, February 1, 2015 at 8:50 AM, Marc Fawzi wrote: > > > > > Yeah I was going to ask at which point will projects like Om and > Reagent decide to fork React... > > > > > > > > > > > > > I believe there is already a similar project that takes this approach. > But it has a significant challenge, it means not reusing the extensive work > of React to work correctly across the long history of semi-broken browsers. > Understanding and implementing dumb manipulation correctly across every > edge case is not the most fun
Re: [ClojureScript] React.js Relay
So to summarize: 1. There is no need to fork React now or in the future because React is a library specified for one purpose, not a framework that can get bloated over time. 2. Relay is both interesting and useful 3. Scenarios where Relay would be counter productive? I mentioned one, and if it's not correct that Relay would complicate that scenario then I'd appreciate an explanation, to better understand how Relay works in that scenario. On Mon, Feb 2, 2015 at 3:06 PM, Mike Haney wrote: > Brendan makes some good points. Obviously I have a strong preference for > Clojurescript (and this IS a CLJS list), but my intention was not to > promote "exceptionalism" and I apologize if it came across that way. > > I have always viewed the relationship between React and Clojurescript as > symbiotic and complementary to each other. There is a clear overlap of > ideas and values, and I think both communities can and have learned from > each other. I think talks about forking React and such are very > misguided. React itself is focused on one thing and very compatible with > the Clojurescript approach. All this other stuff is not part of React > itself, so I'm not sure where this idea of React moving away from > simplicity comes from. > > Back to Relay - my point was more about focusing on the ideas than the > underlying implementation. This is all relatively new, and people are > still figuring out how to best use all these technologies to solve bigger > problems. The approach has evolved considerably over the last year, and it > will continue to. Take Flux for example - many people in the CLJS > community were already using the same approach with say Om and core.async > before anyone outside of Facebook knew about Flux. When it was revealed, I > was more interested in the idea and how it more or less validated we were > on the right track. The actual implementation was less interesting, > because we already had better tools to implement that approach (better as > in more compatible with Clojurescript, not as an absolute measure). I see > Relay as the same thing - maybe some of the actual libraries will be > useful, maybe not, but the ideas are worth considering. > > One retraction I will make - GraphQL may be more interesting than I > originally thought. When I first posted, I had only watched the video and > my impression was that GraphQL was some proprietary wrapper over Facebooks > API. Apparently it is more than that, and if you can indeed plug in back > end data stores, it could be useful as a general query language for doing > this kind of thing. > > -- > 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] [ANN] Rum: new ClojureScript wrapper for React. Decomplected, extensible, simple
Is there anything similar to TodoMVC that compares the different approaches to using React from CLJS? I think if there was then comparing and contrasting would be a great way for some of us to learn the pros and cons of each and maybe et us thinking... -- 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] React.js Relay
I think everyone here agrees w your last point! I think making Relay more efficiently or more easily usable in CLJS is what DN was talking about, if I'm not mistaken. Would love to give it a try. Seems like it could fit naturally with something like Regent... But too early for me to tell as I'm barely scratching the surface of this new world. Sent from my iPhone On Feb 2, 2015, at 6:02 PM, Mike Haney wrote: >> 1. There is no need to fork React now or in the future because React is a >> library specified for one purpose, not a framework that can get bloated over >> time. > > Now - I don't see any benefit that would justify that. > > Future - Who knows? I never claimed to have a crystal ball. My 2 cents is > that the React team appears to share many common values with the > Clojurescript community, among those a preference for small focused libraries > that do one thing well. So it's logical to assume that won't change any time > soon, and if it does then we address it then. > >> 2. Relay is both interesting and useful > > The ideas are interesting, too early to say how useful. > >> 3. Scenarios where Relay would be counter productive? I mentioned one, and >> if it's not correct that Relay would complicate that scenario then I'd >> appreciate an explanation, to better understand how Relay works in that >> scenario. > > I don't think anyone is claiming that Relay is the right approach in every > use case (or even any use case - like I said, it's too soon to tell). For > the example you gave, it doesn't seem to be appropriate. > > But this goes towards my point - not focusing on this monolithic thing called > "Relay" and instead focus on the underlying ideas, such as: > > - components that declare their data requirements > - aggregating component data requirements in order to optimize what data is > queried for > - providing a service endpoint that allows these types of queries > - using the knowledge of component data requirements to optimize re-rendering > when new data is received from the server > > That's just off the top of my head. Some, all, or none of those ideas may > apply to your particular app. Even if the entire Relay approach is a perfect > fit, there are other choices to be made, like using GraphQL or Datalog for > queries. > > But the bigger question is "why?". Their rationale is keeping the data > specification co-located with the components, rather than spread out across > multiple locations. Great idea! Then the next question is - what are the > tradeoffs? Do the benefits outweigh the increased complexity? Every app and > every team will have different answers to these questions - that's why small, > composible libraries and good abstractions are more useful than "one side > fits all" frameworks. > > -- > 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] Feedback on an article I am trying to write (React JSX, Reagent)
Hi John, Thank you for sharing your work in progress. Tomorrow I'll dedicate a couple hours to go over this, and I'll review it as a brand new user of CLJS/Reagent/React, and at least give you feedback about clarity. I don't think we'll be using JSX but I'm very open minded to see what you've worked out! Thank you Marc On Tue, Feb 3, 2015 at 2:38 AM, John wrote: > Hi everybody! > > I am trying to write an article about a topic I find interesting: embedded > templates. > > Please, read and give me feedback, if you find the topic interesting. > English is not my first language, and I would appreciate all help to make > it clearer. > > Does it make sense? Or should I try to make the examples better? Does > anyone agree with me? > > https://medium.com/@johanberling/embedded-templates-in-react-12ca529df234 > > -- > 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] Feedback on an article I am trying to write (React JSX, Reagent)
At last SF CLJS meetup Sean Grove mentioned to me a framework called Kioo https://github.com/ckirkendall/kioo which is for Om which introduces another kind templates In our team, we create the HTML markup and assign CSS classes the designers make visual mock ups, so "templating" is not necessary to expose markup to designers etc, and I find the hiccup syntax (I'm familiar with Jade) pleasant. I've asked others who are more conversant in Reagent/CLJS to take a look too, Will let you know of any input! Marc On Tue, Feb 3, 2015 at 8:12 AM, Johan Berling wrote: > Hi Marc! > > Don't expect it to be a good introduction to Reagent. > > By the way, I think your choice is a wise one. Reagent is really nice to > work with. > > > On Tue, Feb 3, 2015 at 4:33 PM, Marc Fawzi wrote: > >> Hi John, >> >> Thank you for sharing your work in progress. >> >> Tomorrow I'll dedicate a couple hours to go over this, and I'll review it >> as a brand new user of CLJS/Reagent/React, and at least give you feedback >> about clarity. >> >> I don't think we'll be using JSX but I'm very open minded to see what >> you've worked out! >> >> Thank you >> >> Marc >> >> On Tue, Feb 3, 2015 at 2:38 AM, John wrote: >> >>> Hi everybody! >>> >>> I am trying to write an article about a topic I find interesting: >>> embedded templates. >>> >>> Please, read and give me feedback, if you find the topic interesting. >>> English is not my first language, and I would appreciate all help to make >>> it clearer. >>> >>> Does it make sense? Or should I try to make the examples better? Does >>> anyone agree with me? >>> >>> https://medium.com/@johanberling/embedded-templates-in-react-12ca529df234 >>> >>> -- >>> 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 a topic in the >> Google Groups "ClojureScript" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojurescript/huTCgQic1wc/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. >> > > > > -- > Hälsningar > Johan > > -- > 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] Feedback on an article I am trying to write (React JSX, Reagent)
Some semantic confusion on my part. Sorry.
I use the word "template" to refer strictly to out-of-language templates
like HTML markup prototypes that can be cloned, augmented and populated
based on data, or the old string substitution and innerHTML type templates.
I have not yet started referring to DSLs as templating systems, but you're
right they are.
For me, being new to ClojureScript, all the code pasted below looks just
like ClojureScript. If I didn't know about Reagent I would think that
ClojureScripts came with HAML/Jade like support built-in.
The Kioo project is interesting but just like your imagined future version
of Javascript and just like JSX it does not gel/jell well with the host
language. Visually and mentally, it's hard for me to read anything other
than the Jade/Reagent style code.
I love Reagent for the simple reason that when I read the stuff below I
simply do not get STRESSED out
(defn form [field-wrapper fields]
[:form (map field-wrapper fields)
[:button {:type "submit"}])
(defn wrapper [{:keys [label-text input]}]
[:label
[:span label-text]
input])
[form wrapper
[{:label-text "Name", :input [:input {:type "text"}]}
{:label-text "City", :input [:input {:type "text"}]}
{:label-text "Age" , :input [:input {:type "text"}]}]]
It's very pretty and clear from a symbolic/cognitive point of view.
But I have to say I fail to zoom in on the point of the article. What is
the argument you're making? If it's that JSX is like Reagent then I
strongly disagree, even if they are logically doing the same thing. It's
just that when I look I JSX I want to run away and when I look at Reagent I
have that pleasant feeling you mentioned. They're a world apart in terms of
the intangible feel.
On Tue, Feb 3, 2015 at 10:20 AM, Marc Fawzi wrote:
>
> At last SF CLJS meetup Sean Grove mentioned to me a framework called Kioo
> https://github.com/ckirkendall/kioo which is for Om which introduces
> another kind templates
>
> In our team, we create the HTML markup and assign CSS classes the
> designers make visual mock ups, so "templating" is not necessary to expose
> markup to designers etc, and I find the hiccup syntax (I'm familiar with
> Jade) pleasant.
>
> I've asked others who are more conversant in Reagent/CLJS to take a look
> too,
>
> Will let you know of any input!
>
> Marc
>
> On Tue, Feb 3, 2015 at 8:12 AM, Johan Berling
> wrote:
>
>> Hi Marc!
>>
>> Don't expect it to be a good introduction to Reagent.
>>
>> By the way, I think your choice is a wise one. Reagent is really nice to
>> work with.
>>
>>
>> On Tue, Feb 3, 2015 at 4:33 PM, Marc Fawzi wrote:
>>
>>> Hi John,
>>>
>>> Thank you for sharing your work in progress.
>>>
>>> Tomorrow I'll dedicate a couple hours to go over this, and I'll review
>>> it as a brand new user of CLJS/Reagent/React, and at least give you
>>> feedback about clarity.
>>>
>>> I don't think we'll be using JSX but I'm very open minded to see what
>>> you've worked out!
>>>
>>> Thank you
>>>
>>> Marc
>>>
>>> On Tue, Feb 3, 2015 at 2:38 AM, John wrote:
>>>
>>>> Hi everybody!
>>>>
>>>> I am trying to write an article about a topic I find interesting:
>>>> embedded templates.
>>>>
>>>> Please, read and give me feedback, if you find the topic interesting.
>>>> English is not my first language, and I would appreciate all help to make
>>>> it clearer.
>>>>
>>>> Does it make sense? Or should I try to make the examples better? Does
>>>> anyone agree with me?
>>>>
>>>>
>>>> https://medium.com/@johanberling/embedded-templates-in-react-12ca529df234
>>>>
>>>> --
>>>> 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
Re: [ClojureScript] Feedback on an article I am trying to write (React JSX, Reagent)
Yes! totally agreed, and I'd like to see the article making that clear, and
then it'll be an insightful article my opinion, especially for those who
may not have seen jade/haml style templating.
On Wed, Feb 4, 2015 at 11:28 PM, Johan Berling wrote:
> Thanks for the feedback. I think you are right, it is an unfocused
> article. I understand if you do not get my point, and I will not publish it.
>
> What I tried to say, was that embedded templates makes it easier to
> structure our application code, than templates written in a more
> traditional way.
>
>
>
> On Tue, Feb 3, 2015 at 10:55 PM, Marc Fawzi wrote:
>
>> Some semantic confusion on my part. Sorry.
>>
>> I use the word "template" to refer strictly to out-of-language templates
>> like HTML markup prototypes that can be cloned, augmented and populated
>> based on data, or the old string substitution and innerHTML type templates.
>> I have not yet started referring to DSLs as templating systems, but you're
>> right they are.
>>
>> For me, being new to ClojureScript, all the code pasted below looks just
>> like ClojureScript. If I didn't know about Reagent I would think that
>> ClojureScripts came with HAML/Jade like support built-in.
>>
>> The Kioo project is interesting but just like your imagined future
>> version of Javascript and just like JSX it does not gel/jell well with the
>> host language. Visually and mentally, it's hard for me to read anything
>> other than the Jade/Reagent style code.
>>
>> I love Reagent for the simple reason that when I read the stuff below I
>> simply do not get STRESSED out
>>
>> (defn form [field-wrapper fields]
>> [:form (map field-wrapper fields)
>> [:button {:type "submit"}])
>>
>> (defn wrapper [{:keys [label-text input]}]
>> [:label
>> [:span label-text]
>> input])
>>
>> [form wrapper
>> [{:label-text "Name", :input [:input {:type "text"}]}
>>{:label-text "City", :input [:input {:type "text"}]}
>>{:label-text "Age" , :input [:input {:type "text"}]}]]
>>
>> It's very pretty and clear from a symbolic/cognitive point of view.
>>
>> But I have to say I fail to zoom in on the point of the article. What is
>> the argument you're making? If it's that JSX is like Reagent then I
>> strongly disagree, even if they are logically doing the same thing. It's
>> just that when I look I JSX I want to run away and when I look at Reagent I
>> have that pleasant feeling you mentioned. They're a world apart in terms of
>> the intangible feel.
>>
>>
>>
>>
>>
>> On Tue, Feb 3, 2015 at 10:20 AM, Marc Fawzi wrote:
>>
>>>
>>> At last SF CLJS meetup Sean Grove mentioned to me a framework called
>>> Kioo https://github.com/ckirkendall/kioo which is for Om which
>>> introduces another kind templates
>>>
>>> In our team, we create the HTML markup and assign CSS classes the
>>> designers make visual mock ups, so "templating" is not necessary to expose
>>> markup to designers etc, and I find the hiccup syntax (I'm familiar with
>>> Jade) pleasant.
>>>
>>> I've asked others who are more conversant in Reagent/CLJS to take a look
>>> too,
>>>
>>> Will let you know of any input!
>>>
>>> Marc
>>>
>>> On Tue, Feb 3, 2015 at 8:12 AM, Johan Berling
>>> wrote:
>>>
>>>> Hi Marc!
>>>>
>>>> Don't expect it to be a good introduction to Reagent.
>>>>
>>>> By the way, I think your choice is a wise one. Reagent is really nice
>>>> to work with.
>>>>
>>>>
>>>> On Tue, Feb 3, 2015 at 4:33 PM, Marc Fawzi
>>>> wrote:
>>>>
>>>>> Hi John,
>>>>>
>>>>> Thank you for sharing your work in progress.
>>>>>
>>>>> Tomorrow I'll dedicate a couple hours to go over this, and I'll review
>>>>> it as a brand new user of CLJS/Reagent/React, and at least give you
>>>>> feedback about clarity.
>>>>>
>>>>> I don't think we'll be using JSX but I'm very open minded to see what
>>>>> you've worked out!
>>>>>
>>>>> Thank you
>>>>>
>>>>> Marc
>>>>>
>>>>> On Tue, Feb 3, 2015 at 2:38 AM, John
[ClojureScript] missing stuff in Mies generated Readme.md
Being a noob, I'm not sure this is all correct, but without it I couldn't use the REPL Basically, instructions for using the REPL from the browser/app environment were missing https://github.com/swannodette/mies/pull/16 -- 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] React.js Relay
As an engineer, you have to make compromises. You can't cover all edge cases and scenarios. It's more likely that your system will fail because it's too complex and not because it's too specific to a common set of scenarios. There is one class of scenarios where Relay would over complicate things and fail from an architecture point of view. On Mon, Feb 9, 2015 at 3:19 AM, Ivan Kleshnin wrote: > > The client having heavy a priori knowledge of the server's data > structure seems particularly opposed to REST's HATEOAS principle, though I > know they explicitly said Relay operates off a GraphQL endpoint, not a > RESTful API. > > > > http://en.wikipedia.org/wiki/HATEOAS > > http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven > > Noone seems to build their APIs upon HATEOAS principles (FB, Twitter, > Google, Amazon... all just use "normal" old school REST 2-3 layer. Yeah, > yeah... "they don't understand REST"... > I personally consider HATEOAS as worthless hype, promoted mainly by > idealistic fanboys. > They want to talk only about benefits (moslty virtual) of HATEOAS, being > in total ignorance of HATEOAS drawbacks (there are many). > > -- > 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] Parallel data processing and CLJS
Potentially naive question, but I thought I should get it out of the way :) Since in Javascript, there are no threads with shared memory, is there any performance advantage to using CLJS (vs JS, or Immutable.js vs mutable data structures) when it comes to parallel data processing? If so, are there any example specific to CLJS? Curious. -- 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] Parallel data processing and CLJS
right, concurrent, omitting the web worker stuff which relies on messaging, I see improvements to code clarity and maintainability with core.async but I'm trying to find if CLJS' immutable data structures give it a performance advantage where normally expensive copying/cloning would be required for isolating the working memory of two or more processes On Mon, Feb 9, 2015 at 12:03 PM, Gary Trakhman wrote: > Core.async on clojurescript gives a huge advantage for concurrent data > processing, maybe not parallel. > > On Mon Feb 09 2015 at 3:01:16 PM Marc Fawzi wrote: > >> >> Potentially naive question, but I thought I should get it out of the way >> :) >> >> Since in Javascript, there are no threads with shared memory, is there >> any performance advantage to using CLJS (vs JS, or Immutable.js vs mutable >> data structures) when it comes to parallel data processing? If so, are >> there any example specific to CLJS? >> >> Curious. >> >> >> >> -- >> 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. > -- 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] Parallel data processing and CLJS
by processes in my previous reply, I mean async data processing loops running concurrently, i.e. a function called via setImmediate that keeps calling itself, and where you can have multiple of those running concurrently and operating on the same data structure In JS world, we'd make copies of the data structure. In CLJS, there are immutable types and immutability is achieved without cloning... so all I'm looking for is an example of using immutability in CLJS as a performance advantage in such a scenario... is there one? On Mon, Feb 9, 2015 at 12:23 PM, Marc Fawzi wrote: > right, concurrent, omitting the web worker stuff which relies on > messaging, > > I see improvements to code clarity and maintainability with core.async but > I'm trying to find if CLJS' immutable data structures give it a performance > advantage where normally expensive copying/cloning would be required for > isolating the working memory of two or more processes > > > On Mon, Feb 9, 2015 at 12:03 PM, Gary Trakhman > wrote: > >> Core.async on clojurescript gives a huge advantage for concurrent data >> processing, maybe not parallel. >> >> On Mon Feb 09 2015 at 3:01:16 PM Marc Fawzi wrote: >> >>> >>> Potentially naive question, but I thought I should get it out of the way >>> :) >>> >>> Since in Javascript, there are no threads with shared memory, is there >>> any performance advantage to using CLJS (vs JS, or Immutable.js vs mutable >>> data structures) when it comes to parallel data processing? If so, are >>> there any example specific to CLJS? >>> >>> Curious. >>> >>> >>> >>> -- >>> 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. >> > > -- 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] Parallel data processing and CLJS
Answering my question with potential blind spots: The time it takes to populate data into an immutable tree (say an interval tree data structure or whatever kind) and the cost of updates to that immutable structure may be higher than the cost of copying. So I'm leaning toward the belief that immutable data structures help make concurrency simpler and easier to debug but they may actually be less performant than the mutable approach, and that's true either depending on the type of data structure or always... Have not done the detailed thinking or benchmarking... But I feel like I answered my own question in that immutability is simply a basic requirement for functional programming but while it makes concurrency easier even in single thread environments with async loops running concurrently the impact on performance is likely negative. If that's wrong or partly wrong conclusion I would love to hear it and have some examples. Thanks Marc Sent from my iPhone > On Feb 9, 2015, at 1:29 PM, Marc Fawzi wrote: > > by processes in my previous reply, I mean async data processing loops running > concurrently, i.e. a function called via setImmediate that keeps calling > itself, and where you can have multiple of those running concurrently and > operating on the same data structure In JS world, we'd make copies of the > data structure. In CLJS, there are immutable types and immutability is > achieved without cloning... so all I'm looking for is an example of using > immutability in CLJS as a performance advantage in such a scenario... is > there one? > >> On Mon, Feb 9, 2015 at 12:23 PM, Marc Fawzi wrote: >> right, concurrent, omitting the web worker stuff which relies on messaging, >> >> I see improvements to code clarity and maintainability with core.async but >> I'm trying to find if CLJS' immutable data structures give it a performance >> advantage where normally expensive copying/cloning would be required for >> isolating the working memory of two or more processes >> >> >>> On Mon, Feb 9, 2015 at 12:03 PM, Gary Trakhman >>> wrote: >>> Core.async on clojurescript gives a huge advantage for concurrent data >>> processing, maybe not parallel. >>> >>>> On Mon Feb 09 2015 at 3:01:16 PM Marc Fawzi wrote: >>>> >>>> Potentially naive question, but I thought I should get it out of the way :) >>>> >>>> Since in Javascript, there are no threads with shared memory, is there any >>>> performance advantage to using CLJS (vs JS, or Immutable.js vs mutable >>>> data structures) when it comes to parallel data processing? If so, are >>>> there any example specific to CLJS? >>>> >>>> Curious. >>>> >>>> >>>> >>>> -- >>>> 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. > -- 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] Parallel data processing and CLJS
Wow, That *may be* super useful in places where "persistent data structures would allocate too many objects, especially in applications such as games that are sensitive to garbage collection" (googled around, and ingested) check this out http://theatticlight.net/posts/Conways-Game-of-Life-in-Clojurescript/ IN LOVE <3 On Tue, Feb 10, 2015 at 2:00 PM, Jamie Orchard-Hays wrote: > Dunno how CLJS compares with CLJ WRT to this, but reading about how > Clojure gains performance under the covers (and exposes these fns to use) > is illuminating: > > http://clojure.org/transients > > Jamie > > On Feb 10, 2015, at 12:49 PM, Gary Trakhman > wrote: > > Yea, I think the general clojure advice has been to not early-optimize, > much work has been done to make the immutable data structures as fast as > possible, though I'm not sure where the CLJS ones are at perf-wise these > days. > > If you ever reach a bottleneck in your app, it should be relatively easier > and less of a maintenance headache to make a fast/mutable/isolated > implementation compared to the cost of having to decouple mutable code > after it's already been written. > > In terms of the performance of immutable data structures, you'll always be > creating more garbage than a mutable bash-in-place version, so that might > dominate your performance for different types of workloads. > > On Tue Feb 10 2015 at 11:34:06 AM Marc Fawzi wrote: > >> Answering my question with potential blind spots: >> >> The time it takes to populate data into an immutable tree (say an >> interval tree data structure or whatever kind) and the cost of updates to >> that immutable structure may be higher than the cost of copying. >> >> So I'm leaning toward the belief that immutable data structures help make >> concurrency simpler and easier to debug but they may actually be less >> performant than the mutable approach, and that's true either depending on >> the type of data structure or always... Have not done the detailed thinking >> or benchmarking... But I feel like I answered my own question in that >> immutability is simply a basic requirement for functional programming but >> while it makes concurrency easier even in single thread environments with >> async loops running concurrently the impact on performance is likely >> negative. >> >> If that's wrong or partly wrong conclusion I would love to hear it and >> have some examples. >> >> Thanks >> >> Marc >> >> >> Sent from my iPhone >> >> On Feb 9, 2015, at 1:29 PM, Marc Fawzi wrote: >> >> by processes in my previous reply, I mean async data processing loops >> running concurrently, i.e. a function called via setImmediate that keeps >> calling itself, and where you can have multiple of those running >> concurrently and operating on the same data structure In JS world, we'd >> make copies of the data structure. In CLJS, there are immutable types and >> immutability is achieved without cloning... so all I'm looking for is an >> example of using immutability in CLJS as a performance advantage in such a >> scenario... is there one? >> >> On Mon, Feb 9, 2015 at 12:23 PM, Marc Fawzi wrote: >> >>> right, concurrent, omitting the web worker stuff which relies on >>> messaging, >>> >>> I see improvements to code clarity and maintainability with core.async >>> but I'm trying to find if CLJS' immutable data structures give it a >>> performance advantage where normally expensive copying/cloning would be >>> required for isolating the working memory of two or more processes >>> >>> >>> On Mon, Feb 9, 2015 at 12:03 PM, Gary Trakhman >>> wrote: >>> >>>> Core.async on clojurescript gives a huge advantage for concurrent data >>>> processing, maybe not parallel. >>>> >>>> On Mon Feb 09 2015 at 3:01:16 PM Marc Fawzi >>>> wrote: >>>> >>>>> >>>>> Potentially naive question, but I thought I should get it out of the >>>>> way :) >>>>> >>>>> Since in Javascript, there are no threads with shared memory, is there >>>>> any performance advantage to using CLJS (vs JS, or Immutable.js vs mutable >>>>> data structures) when it comes to parallel data processing? If so, are >>>>> there any example specific to CLJS? >>>>> >>>>> Curious. >>>>> >>>>> >>>>> >>>>> >>>>> -- &
Re: [ClojureScript] Parallel data processing and CLJS
Thank you Jamie It does seem to work in CLJS and have a very major effect (defn vrange [n] (loop [i 0 v []] (if (< i n) (recur (inc i) (conj v i)) v))) (defn vrange2 [n] (loop [i 0 v (transient [])] (if (< i n) (recur (inc i) (conj! v i)) (persistent! v (time (def v (vrange 100))) (time (def v2 (vrange2 100))) "Elapsed time: 453 msecs" "Elapsed time: 81 msecs" It's very well reasoned as far as language features go, especially in a tricky context like this On Tue, Feb 10, 2015 at 2:21 PM, Marc Fawzi wrote: > Wow, > > That *may be* super useful in places where "persistent data structures > would allocate too many objects, especially in applications such as games > that are sensitive to garbage collection" (googled around, and ingested) > > check this out > > http://theatticlight.net/posts/Conways-Game-of-Life-in-Clojurescript/ > > IN LOVE <3 > > > > On Tue, Feb 10, 2015 at 2:00 PM, Jamie Orchard-Hays > wrote: > >> Dunno how CLJS compares with CLJ WRT to this, but reading about how >> Clojure gains performance under the covers (and exposes these fns to use) >> is illuminating: >> >> http://clojure.org/transients >> >> Jamie >> >> On Feb 10, 2015, at 12:49 PM, Gary Trakhman >> wrote: >> >> Yea, I think the general clojure advice has been to not early-optimize, >> much work has been done to make the immutable data structures as fast as >> possible, though I'm not sure where the CLJS ones are at perf-wise these >> days. >> >> If you ever reach a bottleneck in your app, it should be relatively >> easier and less of a maintenance headache to make a fast/mutable/isolated >> implementation compared to the cost of having to decouple mutable code >> after it's already been written. >> >> In terms of the performance of immutable data structures, you'll always >> be creating more garbage than a mutable bash-in-place version, so that >> might dominate your performance for different types of workloads. >> >> On Tue Feb 10 2015 at 11:34:06 AM Marc Fawzi >> wrote: >> >>> Answering my question with potential blind spots: >>> >>> The time it takes to populate data into an immutable tree (say an >>> interval tree data structure or whatever kind) and the cost of updates to >>> that immutable structure may be higher than the cost of copying. >>> >>> So I'm leaning toward the belief that immutable data structures help >>> make concurrency simpler and easier to debug but they may actually be less >>> performant than the mutable approach, and that's true either depending on >>> the type of data structure or always... Have not done the detailed thinking >>> or benchmarking... But I feel like I answered my own question in that >>> immutability is simply a basic requirement for functional programming but >>> while it makes concurrency easier even in single thread environments with >>> async loops running concurrently the impact on performance is likely >>> negative. >>> >>> If that's wrong or partly wrong conclusion I would love to hear it and >>> have some examples. >>> >>> Thanks >>> >>> Marc >>> >>> >>> Sent from my iPhone >>> >>> On Feb 9, 2015, at 1:29 PM, Marc Fawzi wrote: >>> >>> by processes in my previous reply, I mean async data processing loops >>> running concurrently, i.e. a function called via setImmediate that keeps >>> calling itself, and where you can have multiple of those running >>> concurrently and operating on the same data structure In JS world, we'd >>> make copies of the data structure. In CLJS, there are immutable types and >>> immutability is achieved without cloning... so all I'm looking for is an >>> example of using immutability in CLJS as a performance advantage in such a >>> scenario... is there one? >>> >>> On Mon, Feb 9, 2015 at 12:23 PM, Marc Fawzi >>> wrote: >>> >>>> right, concurrent, omitting the web worker stuff which relies on >>>> messaging, >>>> >>>> I see improvements to code clarity and maintainability with core.async >>>> but I'm trying to find if CLJS' immutable data structures give it a >>>> performance advantage where normally expensive copying/cloning would be >>>> required for isolating the working memory of two or more processes >>>> >>>> >>
Re: [ClojureScript] Server-side rendering of reagent components.
<<
I found that I had to stub the setTimeout function in google Closure to
make core.async channels work:
goog.global.setTimeout = function(cb, t) {
cb();
}
After that, they seem to work correctly under Nashorn (for a simple Om
server-side app)
>>
More on this here:
http://dev.clojure.org/jira/browse/ASYNC-110?focusedCommentId=37628&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
On Wed, Feb 11, 2015 at 1:19 AM, Pieter van Prooijen
wrote:
> Hi,
>
> I found that I had to stub the setTimeout function in google Closure to
> make core.async channels work:
>
> goog.global.setTimeout = function(cb, t) {
> cb();
> }
>
> After that, they seem to work correctly under Nashorn (for a simple Om
> server-side app)
>
> Regards,
>
> Pieter
>
> --
> 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] Why does ClojureScript keeps the convention to replace _ with - in namespaces ?
wild guess is because when translated to JS the name.name.na-me would be invalid in JS? On Wed, Feb 11, 2015 at 11:08 AM, Roger Gilliar < roger.gill...@googlemail.com> wrote: > I know that Clojure does the same, just because Java does not support - > inside package names. Are there any technical reasons that ClojureScript > does the same ? Or is it just to be compatible to Clojure ? > > -- > 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] Reagent port of the Om tutorial
We use this Reagent cursor https://github.com/dustingetz/cljs-cursor But will switch to Reagent cursor once it's stable, e.g. this issue https://github.com/reagent-project/reagent/issues/99 Enlightenment is always welcome. On Wed, Feb 11, 2015 at 2:09 PM, Val Waeselynck wrote: > Le samedi 25 janvier 2014 15:57:16 UTC+1, Moritz Ulrich a écrit : > > Jonas Enlund writes: > > > > > On Saturday, January 25, 2014 9:49:56 AM UTC+2, David Nolen wrote: > > >> Nice. I do consider the non-modularity of `update-contacts!` here to > be one of the big things I try to address in Om. The Reagent > `update-contacts!` knows too much. In Om, it doesn't matter at all where > :contacts lives in the app state, the Om contacts-view can still update it. > > > > > > So if I understand correctly the 'app' arg in (defn contacts-view [app > owner] ...) doesn't have to be the root of the app-state atom? > > > > You understand correctly. Om implements a cursor data-structure which > > allows you to pass a 'subset' (for example (:contacts state) of the > > components. om/update! will update as expected (it will just see the > > :contacts part of the state). > > If I may, Reagent has cursors too: > https://github.com/reagent-project/reagent-cursor, that allow exactly > that. > > -- > 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] Reagent port of the Om tutorial
correction: was referring to a 3rd party cursor, not one that comes with Reagent, but we do like to move to the Reagent cursor once it's stable On Wed, Feb 11, 2015 at 3:15 PM, Marc Fawzi wrote: > We use this Reagent cursor > > https://github.com/dustingetz/cljs-cursor > > But will switch to Reagent cursor once it's stable, e.g. this issue > https://github.com/reagent-project/reagent/issues/99 > > Enlightenment is always welcome. > > > > On Wed, Feb 11, 2015 at 2:09 PM, Val Waeselynck > wrote: > >> Le samedi 25 janvier 2014 15:57:16 UTC+1, Moritz Ulrich a écrit : >> > Jonas Enlund writes: >> > >> > > On Saturday, January 25, 2014 9:49:56 AM UTC+2, David Nolen wrote: >> > >> Nice. I do consider the non-modularity of `update-contacts!` here to >> be one of the big things I try to address in Om. The Reagent >> `update-contacts!` knows too much. In Om, it doesn't matter at all where >> :contacts lives in the app state, the Om contacts-view can still update it. >> > > >> > > So if I understand correctly the 'app' arg in (defn contacts-view >> [app owner] ...) doesn't have to be the root of the app-state atom? >> > >> > You understand correctly. Om implements a cursor data-structure which >> > allows you to pass a 'subset' (for example (:contacts state) of the >> > components. om/update! will update as expected (it will just see the >> > :contacts part of the state). >> >> If I may, Reagent has cursors too: >> https://github.com/reagent-project/reagent-cursor, that allow exactly >> that. >> >> -- >> 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] ANN: ClojureScript 0.0-2843, Node, Node, Node
does it solve this? http://dev.clojure.org/jira/browse/ASYNC-110?focusedCommentId=37628&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel On Thu, Feb 12, 2015 at 9:08 AM, David Nolen wrote: > ClojureScript, the Clojure compiler that emits JavaScript source code. > > README and source code: https://github.com/clojure/clojurescript > > New release version: 0.0-2843 > > Leiningen dependency information: > > [org.clojure/clojurescript "0.0-2843"] > > This release is primarily about outstanding Node.js target > issues. Further changes have been made to support Node.js v0.12 > specifically around the deprecation of util.print. Node.js target now > supports :main same as browser based :none builds. Node.js :simple and > :advanced builds now set goog.global correctly ensuring that > core.async works properly. The Node.js REPL should now work on slower > machines. And all of these enhancements have been made with the > Windows platform in mind. > > We've also solidified and documented the new generic source mapping > infrastructure for custom REPLs. Figwheel and Ambly are already taking > advantage of this to great effect. > > Printing is now customizable in order to support custom printing in > Chrome DevTools, there's some prototype work based on this happening > here: https://github.com/binaryage/cljs-devtools-sample. > > cljs.test now supports macro inference simplifying testing at a REPL. > > Full list of changes, fixes, and enhancements follows. > > Feedback welcome! > > ## 0.0-2843 > > ### Enhancements > * CLJS-1032: Node.js target should support :main > * require cljs.test macro ns in cljs.test to get macro inference goodness > * include :url entries to original sources in mapped stacktraces if it can > be determined from the classpath > * support custom mapped stacktrace printing > * provide data oriented stacktrace mapping api > * CLJS-1025: make REPL source mapping infrastructure generic > * CLJS-1010: Printing hook for cljs-devtools > * CLJS-1016: make "..." marker configurable > > ### Changes > * CLJS-887: browser repl should serve CSS > * CLJS-1031: Get Closure Compiler over https in the bootstrap script > > ### Fixes > * cljs.nodejscli ns needs to set `goog.global` when `COMPILED` is true, > this fixes the fundamental issues for ASYNC-110 > * CLJS-967: "java.net.ConnectException: Connection refused" when running > node repl > * pass relevant source map options in the incremental compile case > * add some missing source-map customization flags to optimized builds > * fix missed Rhino REPL regression, the surrounding REPL infrastructure > creates cljs.user for us > * util.print has been deprecated in Node.js v0.12. Switch to console.log > in Node.js REPLs. > * change `cljs.closure/watch` so it correctly watches all subdirectories > do not recompile unless changed path is a file with .cljs or .js extension > > -- > 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] ANN: ClojureScript 0.0-2843, Node, Node, Node
sorry, sent before looking at latest comments, it does! thanks On Thu, Feb 12, 2015 at 3:28 PM, Marc Fawzi wrote: > does it solve this? > > > http://dev.clojure.org/jira/browse/ASYNC-110?focusedCommentId=37628&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel > > On Thu, Feb 12, 2015 at 9:08 AM, David Nolen > wrote: > >> ClojureScript, the Clojure compiler that emits JavaScript source code. >> >> README and source code: https://github.com/clojure/clojurescript >> >> New release version: 0.0-2843 >> >> Leiningen dependency information: >> >> [org.clojure/clojurescript "0.0-2843"] >> >> This release is primarily about outstanding Node.js target >> issues. Further changes have been made to support Node.js v0.12 >> specifically around the deprecation of util.print. Node.js target now >> supports :main same as browser based :none builds. Node.js :simple and >> :advanced builds now set goog.global correctly ensuring that >> core.async works properly. The Node.js REPL should now work on slower >> machines. And all of these enhancements have been made with the >> Windows platform in mind. >> >> We've also solidified and documented the new generic source mapping >> infrastructure for custom REPLs. Figwheel and Ambly are already taking >> advantage of this to great effect. >> >> Printing is now customizable in order to support custom printing in >> Chrome DevTools, there's some prototype work based on this happening >> here: https://github.com/binaryage/cljs-devtools-sample. >> >> cljs.test now supports macro inference simplifying testing at a REPL. >> >> Full list of changes, fixes, and enhancements follows. >> >> Feedback welcome! >> >> ## 0.0-2843 >> >> ### Enhancements >> * CLJS-1032: Node.js target should support :main >> * require cljs.test macro ns in cljs.test to get macro inference goodness >> * include :url entries to original sources in mapped stacktraces if it >> can be determined from the classpath >> * support custom mapped stacktrace printing >> * provide data oriented stacktrace mapping api >> * CLJS-1025: make REPL source mapping infrastructure generic >> * CLJS-1010: Printing hook for cljs-devtools >> * CLJS-1016: make "..." marker configurable >> >> ### Changes >> * CLJS-887: browser repl should serve CSS >> * CLJS-1031: Get Closure Compiler over https in the bootstrap script >> >> ### Fixes >> * cljs.nodejscli ns needs to set `goog.global` when `COMPILED` is true, >> this fixes the fundamental issues for ASYNC-110 >> * CLJS-967: "java.net.ConnectException: Connection refused" when running >> node repl >> * pass relevant source map options in the incremental compile case >> * add some missing source-map customization flags to optimized builds >> * fix missed Rhino REPL regression, the surrounding REPL infrastructure >> creates cljs.user for us >> * util.print has been deprecated in Node.js v0.12. Switch to console.log >> in Node.js REPLs. >> * change `cljs.closure/watch` so it correctly watches all subdirectories >> do not recompile unless changed path is a file with .cljs or .js extension >> >> -- >> 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] Learning: CLJS recur and stack overflow
In Javascript, ES5, the standard way to deal with stack overflow from "too
much recursion" is to convert the recursive function to its tail call
recursion form and then use trampoline or some other tco technique
Factorial not written for tail call optimization:
function factorial(n) {
if (n == 0) {
return 1;
} else {
return n * factorial(n-1);
}
}
The factorial function invokes * last, not factorial. This implementation
cannot be optimized.
Factorial written for tail call optimization:
function factorial(n) {
function recur(n, acc) {
if (n == 0) {
return acc;
} else {
return recur(n-1, n*acc);
}
}
return recur(n, 1);
}
running either busts the stack
factorial(56787)
Uncaught RangeError: Maximum call stack size exceeded
So far from what I read I think every loop in cljs is done via recursion
(or "recur" to be exact) so does cljs automatically converts a recursive
function to its tail call form and optimizes it via google closure (does
that have tco?) or converts to iterative JS?
Also, is their a branch of cljs that outputs ES6 code and maybe takes care
of tco?
More importantly, am i missing something bout how recur works in cljs?
This is just exploratory. I don't have a use case, but it's such a basic
thing to get out of the way.
Thanks,
Marc
--
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: Learning: CLJS recur and stack overflow
Oh thank you. So CLJS has been ahead of ES5 on this front too! and ahead of ES7 I would say ;) On Fri, Feb 13, 2015 at 8:41 AM, Ivan L wrote: > iirc recur converts a recursive looking form into a standard loop. it > also does a few checks to see that it was coded in tail recursive manner so > that's a plus. > > -- > 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] Re: ClojureScript in Existing Web Application
Install Leinigen either in local project folder or in your path somewhere I use IntelliJ with La Clojure plugin. Reagent is in flux but I feel like it's headed in the right direction. I'd use the latest alpha! and try Figwheel too. Might be good to start with a simple non-SPA Reagent template. Feel free to post noob questions. Many of us are new to the whole thing, so an opportunity to learn together. ClojureScript+Reagent is a good choice imo but beware of the fact that this is all bleeding edgel, not anything mature/stable except for the Google Closure compiler and Leinigen. Having said that, a bunch of incredible people and companies putting their weight behind this stuff, so I wouldn't be worried. Marc On Mon, Feb 16, 2015 at 3:13 PM, David Boyer wrote: > On Monday, February 16, 2015 at 5:46:53 PM UTC-5, David Boyer wrote: > > I have an existing maven built J2EE web application. Some JSP/Struts, > then jquery, a little GWT, and recently backbone/bootstrap/dustjs. I'm > really interested in adding a ClojureScript beachhead into my web > application, so that I can start experimenting with Reagent/React. > > > > Any suggestions on how to set up a development/deployment workflow that > would make this easy to do? > > > > The project is one web application bundle + a set of Java maven projects > that implement various server technologies. > > And I inherited a 6 year old project a year ago. I didn't decide this was > an intelligent evolution of a product. > > -- > 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] Clojure/Java Interop errors in the browser?!
As a new user to ClojureScript who has not programmed in Clojure or any
JVM-to-JS environment this comes to me as a huge surprise!
(it shouldn't if I had thought things more deeply, but don't have the
luxury of infinite ramp up time)
user=> (def f {"a" "1" "b" "2"})
user=> (map #((name (key %))) f)
ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
user/eval1212/fn--1213 (b43f5f5d46b2bd87480559901c3a9d087879416a-init.clj:1)
>>> Is that a Java/Clojure Interop error? I suppose if the REPL throws then
I'll also see this error or a variant of it IN THE BROWSER ?
The error is resolved if I do this
(map #(str (name (key %))) f)
I thought Clojure is dynamically typed and I understand for Java interop on
the server if we have to do this but why couldn't we get away with it in
the browser environment?
My limited understanding is that str here is like String(val) in JS, which
is almost never needed.
Please enlighten, whomever understands the interop stuff and why as front
end developers we have to carry that burden?
--
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] Clojure/Java Interop errors in the browser?!
Oh!
I guess the REPL message was saying that it can't cast a Java string as a
Clojure function.
The parenthesis. I was trying to invoke a string. How dumb of me.
Lesson learned. Also, learned to try it in the browser for a more familiar
type error message.
I wonder how ClojureScript would be like if it didn't have the Lisp style
syntax. I think it's been the biggest part of the learning curve.
Thank you :)
On Mon, Feb 16, 2015 at 7:44 PM, Dave Della Costa
wrote:
> Hi Marc,
>
> This isn't an interop issue but simply is arising from the fact that you
> are attempting to call a string as though it were a function, and it is
> getting caught at runtime.
>
> To compare, I tried the same code in ClojureScript and I saw: "Uncaught
> TypeError: undefined is not a function" which is roughly the same
> (although I'm a bit surprised by the "undefined" and would have expected
> that to be a string).
>
> In any case, I'm not sure what your original goal was, but maybe this
> was what you were looking for?
>
> > (map #(name (key %)) f)
>
> That is, you don't need to wrap this in a call to 'str,' name already
> returns a string.
>
> DD
>
> On 2015/02/17 11:15, Marc Fawzi wrote:
> > As a new user to ClojureScript who has not programmed in Clojure or any
> > JVM-to-JS environment this comes to me as a huge surprise!
> >
> > (it shouldn't if I had thought things more deeply, but don't have the
> > luxury of infinite ramp up time)
> >
> > user=> (def f {"a" "1" "b" "2"})
> >
> > user=> (map #((name (key %))) f)
> >
> > ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
> > user/eval1212/fn--1213
> (b43f5f5d46b2bd87480559901c3a9d087879416a-init.clj:1)
> >
> >>>> Is that a Java/Clojure Interop error? I suppose if the REPL throws
> > then I'll also see this error or a variant of it IN THE BROWSER ?
> >
> > The error is resolved if I do this
> >
> > (map #(str (name (key %))) f)
> >
> > I thought Clojure is dynamically typed and I understand for Java interop
> > on the server if we have to do this but why couldn't we get away with it
> > in the browser environment?
> >
> > My limited understanding is that str here is like String(val) in JS,
> > which is almost never needed.
> >
> >
> > Please enlighten, whomever understands the interop stuff and why as
> > front end developers we have to carry that burden?
> >
> >
> >
> >
> > --
> > 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
> > <mailto:clojurescript+unsubscr...@googlegroups.com>.
> > To post to this group, send email to clojurescript@googlegroups.com
> > <mailto: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.
>
--
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: ClojureScript in Existing Web Application
I did try it! and I was impressed, but one thing it did wasn't right for me. Here is my story: I had to give it up because, being a noob, I wanted to be able to accidentally type extra parenthesis and see that I did make a mistake (red underline or something like that) as opposed to being prevented from typing the extra parenthesis. It's a somewhat surprising approach to disable keyboard input, although I admit I did take the same approach in my self built special-purpose editor, but then learned that it wasn't the best way. I thought IntelliJ died on me and wasn't responding, so I restarted it and still couldn't type that extra parenthesis. Being a noob I had no idea that wat I was trying to do was wrong. Cursive is preemptive like that and it can be surprising and even interruptive if your style is to paint with a think brush then refine/remove errors. Is that a configurable thing? Also, when I had functions defined within a main function (I am still thinking in JS way and it's probably not best practice to do that in Clojure but I wanted to make some functions private in a library I was building) and Cursive was not able to detect the definitions of the inner functions so somewhere below the definitions where I actually call the functions they were getting highlighted as unknown. That's what I had tweeted @cursiveclojure about on Friday, but I failed to floow up (sorry) I'd rather use locally produced software and tools :) but that's my feedback and I hope to reevaluate based on your response. Thanks for the good work and for sharing it! Marc On Tue, Feb 17, 2015 at 7:53 AM, Colin Yates wrote: > I think you mean https://cursiveclojure.com/ :) > > On 17 February 2015 at 15:28, Alan Moore wrote: > > Marc, > > > > You mention using La Clojure - while I have nothing against it you > should really check out Cursive. Colin has done a fantastic job with it. > See: > > > > www.cursiveclijure.com > > > > Just be sure to uninstall La Clojure first. If you have questions there > is a mailing list for it: > > > > https://cursiveclojure.com/mailinglist.html > > > > Alan > > > > -- > > 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. > -- 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: ClojureScript in Existing Web Application
Hi Colin, Thanks for your explanation and tips! I'd totally use it now if I had a haptic feedback keyboard where it vibrated under my finger every time I attempted to type an extra parenthesis. That would make it feel natural, but yes with time I may get used to the structure it enforces and it should contribute to higher level of recognition. It's a pretty interesting concept if applied consistently. On Tue, Feb 17, 2015 at 8:26 AM, Colin Yates wrote: > Hi Marc, > > The prevention of typing brackets is related to the concept of > "structural editing". You aren't editing text you are editing > s-expressions (e.g. lists). The most common implementation of this is > called "paredit", Cursive calls it "structural editing". It is > incredibly frustrating and annoying until it clicks and then it is > invaluable :). > > However, to turn it off you can click on the toolbar at the bottom > right which says "Structural: On". To 'work around' it you can always > type the opening bracket which will insert the closing bracket, then > highlight and delete the closing bracket. The whole point of > structural editing however is that you never need to do this as it > won't ever let you get out of balance. > > In terms of nested defns - yeah, Clojure really wants you to define > them at the top level. You can have lexically scoped functions using > (letfn [...]) or (let [my-fn (fn...)]) but nested defs/defns is bad > form. > > Give structural editing a go - it really does make things a whole lot > easier ;). > > On 17 February 2015 at 16:19, Marc Fawzi wrote: > > > > I did try it! and I was impressed, but one thing it did wasn't right for > me. > > Here is my story: > > > > I had to give it up because, being a noob, I wanted to be able to > > accidentally type extra parenthesis and see that I did make a mistake > (red > > underline or something like that) as opposed to being prevented from > typing > > the extra parenthesis. It's a somewhat surprising approach to disable > > keyboard input, although I admit I did take the same approach in my self > > built special-purpose editor, but then learned that it wasn't the best > way. > > I thought IntelliJ died on me and wasn't responding, so I restarted it > and > > still couldn't type that extra parenthesis. Being a noob I had no idea > that > > wat I was trying to do was wrong. Cursive is preemptive like that and it > can > > be surprising and even interruptive if your style is to paint with a > think > > brush then refine/remove errors. Is that a configurable thing? > > > > Also, when I had functions defined within a main function (I am still > > thinking in JS way and it's probably not best practice to do that in > Clojure > > but I wanted to make some functions private in a library I was building) > and > > Cursive was not able to detect the definitions of the inner functions so > > somewhere below the definitions where I actually call the functions they > > were getting highlighted as unknown. That's what I had tweeted > > @cursiveclojure about on Friday, but I failed to floow up (sorry) > > > > I'd rather use locally produced software and tools :) but that's my > feedback > > and I hope to reevaluate based on your response. > > > > Thanks for the good work and for sharing it! > > > > Marc > > > > On Tue, Feb 17, 2015 at 7:53 AM, Colin Yates > wrote: > >> > >> I think you mean https://cursiveclojure.com/ :) > >> > >> On 17 February 2015 at 15:28, Alan Moore wrote: > >> > Marc, > >> > > >> > You mention using La Clojure - while I have nothing against it you > >> > should really check out Cursive. Colin has done a fantastic job with > it. > >> > See: > >> > > >> > www.cursiveclijure.com > >> > > >> > Just be sure to uninstall La Clojure first. If you have questions > there > >> > is a mailing list for it: > >> > > >> > https://cursiveclojure.com/mailinglist.html > >> > > >> > Alan > >> > > >> > -- > >> > 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
Re: [ClojureScript] Online HTML to Hiccup converter
Hi Aiden Are you using Hickory? Sent from my iPhone > On Feb 20, 2015, at 5:39 PM, Aiden Nibali wrote: > > Hello all, > > I've put together an online HTML to Hiccup converter at > http://tohiccup.herokuapp.com/ > Hopefully this will be of some use to people either as another example of an > Om project or for the tool itself. > > Aiden > > -- > 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] [ANN] thi.ng collection update (CLJ/CLJS)
looks stunning... literally stunning, thanks for sharing. On Tue, Feb 24, 2015 at 9:06 PM, Karsten Schmidt wrote: > Hi guys, > > thi.ng is a collection of over a dozen largely x-platform Clojure & > Clojurescript libs for computational/generative design & data > visualization tasks. > > I just wanted to give a little heads up that this project has recently > seen a number of releases and, as a whole, by now is generally quite > stable and usable (*is used*) for realworld projects (although most > libs remain in constant parallel development to make them more feature > complete). I've collated a number of images of projects and links to > the most important libs here: > > http://thi.ng/ > > Most notably of those: > > http://thi.ng/geom > By far the largest sub-project and backbone for most others: A 2D/3D > geometry package w/ comprehensive vector algebra, swizzling, > intersections, matrix types & helpers, quaternions, pure shape > primitives with ~50 protocols for polymorphic enquiry & manipulation, > meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics > engine (only particles, springs, behaviors)... Most of this lib is > pure geometry w/ no rendering specifics, although there're separate > modules for SVG rendering w/ shader support & decorators [1], WebGL > wrapper and converters from shapes/meshes to VBOs and various shader > presets/utils. > > http://thi.ng/shadergraph > GLSL (WebGL) pure function library & dependency graph (based on > com.stuartsierra/dependency), GLSL minification during CLJS compile > time > > http://thi.ng/color > RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes) > > http://thi.ng/luxor > Complete scene compiler DSL for http://luxrender.net, based around > thi.ng/geom > > http://thi.ng/morphogen > Declarative 3D form evolution through tree-based transformations, > basically an AST generator of geometric operations to transform a > single seed node into complex 3D objects > > http://thi.ng/tweeny > Interpolation of nested (presumably animation related) data > structures. Allows tweening of deeply nested maps/vectors with > completely flexible tween fns/targets and hence easy definition of > complex timelines > > http://thi.ng/validate > Purely functional, composable data validation & optional corrections > for nested data. Supports both maps & vectors, wildcards, comes with > many predefined validators, but extensible... > > http://thi.ng/trio > A generic, non-RDF specific triple store API and feature rich > SPARQL-like query engine > (and my prime example of using the literate programming approach with > org-mode[2][3]) > > Last but not least: Super special thanks are due to the following people: > > Rich, Alex + rest of clojure.core > David (+everyone else involved) for the immense effort on making CLJS > proper useful, > Chas, Kevin and anyone else working on CLJX... > none of this would have been possible without these amazing tools! > > Best, K. > > Ps. There're a number of other libs in this collection which are in > dire need of updating (last touched spring 2013) - these are related > to general OpenCL functionality and voxel rendering. Some of the > example images on the above site were created with these... > > [1] https://github.com/thi-ng/geom/blob/master/geom-svg/src/examples.org > [2] https://github.com/thi-ng/trio/blob/master/src/query.org > [3] http://orgmode.org/ > > -- > Karsten Schmidt > http://postspectacular.com | http://thi.ng/ > > -- > 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] Re: ANN: re-frame 0.1.7 Initial Release
Hi Mike, Thanks for answering my question on the Reagent list about "this.props" With respect to the no-cursor architecture, I'm currently having a problem in trying to keep my "reusable input component" both generic, so not specific to the data structure since that would kill re-usability, and at the same time avoid re-rendering all instances of the component on the page which happens which the cursor carrying the data structure sub-tree meant for input fields on the page is changed. So when I change the value in one of the re-usable input components all input components are re-rendered because the cursor that holds that sub-tree is dereferenced inside the component. How would your cursor-less architecture help this case? If it's hard to visualize or vague I would be happy to document it in a video. Thank you Mike and hope to chat with you at some point about ideas I have for Reagent. I wonder if Dan is on this list too and has time to chime in? Marc On Wed, Feb 25, 2015 at 3:13 PM, Jane Dampney wrote: > On Wednesday, February 25, 2015 at 10:52:23 PM UTC+11, Mike Thompson wrote: > > A Reagent Framework For Writing SPAs, in ClojureScript. > > > > README and source code: https://github.com/Day8/re-frame > > > > "Derived data, flowing" in a two-stage, FRP loop. > > > > Absolutely no Cursors!! > > > > Wow! No Cursors, indeed. > > Really well thought out, and nicely explained. > > Appears similar to https://github.com/evancz/elm-architecture-tutorial > but not the same. I like the use of middleware and love the possibility > of using statecharts. > > > > > > -- > 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] Re: ANN: re-frame 0.1.7 Initial Release
Mike, Do you want to give a talk about it? ;) I'm looking for speakers (local or remote) for our first Reagent meetup in SF. Back to cursors and enabling re-usable components. I'm not sure how isolating control outside of components can lead to re-usable components. Can you explain, please? I'm now passing finely grained cursors to the factory returned function to avoid re-rendering every instance of a reusable input component due to the previously coarse cursor we were using. It shifts the overhead to the usage context where the user of the component has to split the atom to single-use slices and pass the the corresponding instance of the component. Do you know what I mean? I can clarify. So far the cursor based architecture has not failed me, where my goal is to build re-usable Reagent components. But you know a lot more than I do about both Clojure and Reagent. So feel free to enlighten. In fact, I look forward to your explanation on building re-usable components. I'm not sold on any SPA framework where the components are hard to re-use. Looking forward to more chat! Marc On Thu, Feb 26, 2015 at 4:55 PM, Mike Thompson wrote: > On Thursday, February 26, 2015 at 10:19:05 AM UTC+11, Jane Dampney wrote: > > On Wednesday, February 25, 2015 at 10:52:23 PM UTC+11, Mike Thompson > wrote: > > > A Reagent Framework For Writing SPAs, in ClojureScript. > > > > > > README and source code: https://github.com/Day8/re-frame > > > > > > "Derived data, flowing" in a two-stage, FRP loop. > > > > > > Absolutely no Cursors!! > > > > > > > Wow! No Cursors, indeed. > > > > Really well thought out, and nicely explained. > > > > Appears similar to https://github.com/evancz/elm-architecture-tutorial > > but not the same. I like the use of middleware and love the possibility > of using statecharts. > > > > Indeed, Elm was an inspiration. As was the terrific Hoplon, which doesn't > get nearly enough praise. > > We all know that immutable data let's you manage "time" better, right? > We're able to ignore (isolate ourselves from) the effect of time on data. > > FRP is another dimension in the same process. FRP allows us to model the > "flow" of data over "time". It allows us to manage the process of producing > "Derived Data" (materialised views) over time. Again, it is all about > doing the "time/data” thing better. > > That was a big learning for me (I worry that everyone else already knows > this already, and I'm just very late to the party). > > Perhaps the biggest moment for me was seeing Pete Hunt (Facebook) talking > at reactconf. In his talk, he referenced a particular StrangeLoop video, > mentioning how it had had a big influence on the way Facebook looked at > things these days, and then he talked about how it was all about "Derived > Data". > > When I watched the video, a small nuclear explosion went off in the back > of mind. The penny suddenly dropped for me about FRP. > > At that point, I suddenly understood what I had been trying to achieve > with re-frame, and why I found it so pleasing to work with. It all made > sense. > > The key thing for me is: JUST. DON'T. USE. CURSORS. There I said it. They > appear convenient, I know. They are a way of achieving reference > transparency, I know. But I think they are a “local optimum”. Their use > seems to get in the way of a more important data flow paradigm and they > seem to encourage "control" into all the wrong places (components). At > least that's my experience (I did try to love them, really I did :-)). > > I know this is a controversial opinion within ClojureScript right now. OM > has such an overwhelming mindshare. David is a very compelling and > important character. > > Anyway, I'll finish off the todomvc over the weekend. That will make > re-frame a bit more real and easy to Grok. > > -- > Mike > > -- > 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] Re: ANN: re-frame 0.1.7 Initial Release
By re-use I mean sharing outside of the project! Angular components are hard to re-use (not that I ever used it but that's what I heard from people who have) Reagent components I'm building with cursors are easy to reuse and share via maven repo managers like Clojars. Artifactory, etc. I'm sure React components are shareable via some NPM based library. But when you talk about moving "control" outside of components are you saying that program logic is not simply a function of components coordinating among themselves? I find the Reagent cursor specially appealing because of the setter-getter function and the fact that it can serve as a callback to an async notification mechanism. Could you, would you eat it with a mouse? --from Dr Seuss Green Eggs and Ham On Thu, Feb 26, 2015 at 6:05 PM, Marc Fawzi wrote: > Mike, > > Do you want to give a talk about it? ;) > > I'm looking for speakers (local or remote) for our first Reagent meetup in > SF. > > Back to cursors and enabling re-usable components. I'm not sure how > isolating control outside of components can lead to re-usable components. > Can you explain, please? > > I'm now passing finely grained cursors to the factory returned function to > avoid re-rendering every instance of a reusable input component due to the > previously coarse cursor we were using. It shifts the overhead to the usage > context where the user of the component has to split the atom to single-use > slices and pass the the corresponding instance of the component. Do you > know what I mean? I can clarify. > > So far the cursor based architecture has not failed me, where my goal is > to build re-usable Reagent components. > > But you know a lot more than I do about both Clojure and Reagent. So feel > free to enlighten. In fact, I look forward to your explanation on building > re-usable components. I'm not sold on any SPA framework where the > components are hard to re-use. > > Looking forward to more chat! > > Marc > > > > On Thu, Feb 26, 2015 at 4:55 PM, Mike Thompson > wrote: > >> On Thursday, February 26, 2015 at 10:19:05 AM UTC+11, Jane Dampney wrote: >> > On Wednesday, February 25, 2015 at 10:52:23 PM UTC+11, Mike Thompson >> wrote: >> > > A Reagent Framework For Writing SPAs, in ClojureScript. >> > > >> > > README and source code: https://github.com/Day8/re-frame >> > > >> > > "Derived data, flowing" in a two-stage, FRP loop. >> > > >> > > Absolutely no Cursors!! >> > > >> > >> > Wow! No Cursors, indeed. >> > >> > Really well thought out, and nicely explained. >> > >> > Appears similar to https://github.com/evancz/elm-architecture-tutorial >> > but not the same. I like the use of middleware and love the >> possibility of using statecharts. >> >> >> >> Indeed, Elm was an inspiration. As was the terrific Hoplon, which >> doesn't get nearly enough praise. >> >> We all know that immutable data let's you manage "time" better, right? >> We're able to ignore (isolate ourselves from) the effect of time on data. >> >> FRP is another dimension in the same process. FRP allows us to model the >> "flow" of data over "time". It allows us to manage the process of producing >> "Derived Data" (materialised views) over time. Again, it is all about >> doing the "time/data” thing better. >> >> That was a big learning for me (I worry that everyone else already knows >> this already, and I'm just very late to the party). >> >> Perhaps the biggest moment for me was seeing Pete Hunt (Facebook) talking >> at reactconf. In his talk, he referenced a particular StrangeLoop video, >> mentioning how it had had a big influence on the way Facebook looked at >> things these days, and then he talked about how it was all about "Derived >> Data". >> >> When I watched the video, a small nuclear explosion went off in the back >> of mind. The penny suddenly dropped for me about FRP. >> >> At that point, I suddenly understood what I had been trying to achieve >> with re-frame, and why I found it so pleasing to work with. It all made >> sense. >> >> The key thing for me is: JUST. DON'T. USE. CURSORS. There I said it. >> They appear convenient, I know. They are a way of achieving reference >> transparency, I know. But I think they are a “local optimum”. Their use >> seems to get in the way of a more important data flow paradigm and they >> seem to encourage "control" in
Re: [ClojureScript] Re: ANN: re-frame 0.1.7 Initial Release
Will those components work within your SPA architecture and also work in pretty much anywhere where Reagent is used? On Fri, Feb 27, 2015 at 1:44 PM, Mike Thompson wrote: > > > > How would your cursor-less architecture help this case? If it's hard to > visualize or vague I would be happy to document it in a video. > > Reframe is about overall (in client) architecture, not reusable components > > We're releasing a library of reusable Reagent components in the next week > or so (targeted at Chrome, so not for everyone). That will give you > something to look at. > > > -- > Mike > > -- > 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.
Fwd: [ClojureScript] ClojureScript/Reagent Job Opportunity
CC: clojurescript-j...@googlegroups.com -- Forwarded message -- From: Kirill Ishanov Date: Sat, Feb 28, 2015 at 7:30 PM Subject: [ClojureScript] ClojureScript/Reagent Job Opportunity To: clojurescript@googlegroups.com Hi there, I work as the only front-end developer for a start-up (well-funded, stealth-mode, Menlo Park CA) which is building network fabric management software. The whole front-end is a mid-size SPA written in ClojureScript & Reagent which sits on top of REST-like API + WebSockets for telemetry data. The app is only a 5 month old toddler, which is not completely spoiled yet and can be grown into a decent application (however, I have a strong feeling that no best practices have been harmed during implementation). Recently we decided to increase the bus factor for the front-end team, so we're looking for the 2nd developer. If you're interested/experienced in front-end development/have some understanding of computer networking/(ideally) ready to do ClojureScript full-time & can bring some relevant experience - drop me an email. Thanks, Kirill -- 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] Example of a working macro?
Hi, I tried defmacro from a .clj file with proper namespace and I did a :require-macros (with standard :refer) to point to it from my .cljs file I thought I should maybe tell Leinigen something about the .clj file containing the macro but I'm not sure what is needed there. Does anyone have a clue? or know of a CLJS project on github where macros are used? Thanks, Marc -- 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: Example of a working macro?
Thank you very much Zubair! Do you have a blog or active twitter? Would love to follow. Sent from my iPhone > On Mar 3, 2015, at 8:43 AM, Zubair Quraishi wrote: > > There are several macros in my github project: > > https://github.com/zubairq/coils > > > >> On Tuesday, March 3, 2015 at 5:13:06 PM UTC+1, marc fawzi wrote: >> Hi, >> >> >> I tried defmacro from a .clj file with proper namespace and I did a >> :require-macros (with standard :refer) to point to it from my .cljs file >> >> >> I thought I should maybe tell Leinigen something about the .clj file >> containing the macro but I'm not sure what is needed there. >> >> >> Does anyone have a clue? or know of a CLJS project on github where macros >> are used? >> >> >> Thanks, >> Marc > > -- > 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] Why, in principle, can't macros be defined in ClojureScript itself?
Hi Peter, Thank you for pointing me to that thread. I've just got home and haven't a chance to read it yet. But I'm suspecting that "defmacro" is itself only supported in clojure with no equivalent in ClojureScript. I have seen lots of Clojure macros that use the Java interop and I think that many are not portable to Javascript. Just a guess... Sent from my iPhone > On Mar 3, 2015, at 8:48 PM, Peter West wrote: > > As it says. I had a hurried look through earlier postings for some > discussion of this, without success. > > Macros eventually all expand to CLJS-compatible code. Currently, IIUC, both > macro definition and expansion are handled by the Clojure compiler, with the > resulting code (presumably CLJS compatible) being handed back to the > ClojureScript compiler. Was this simply a convenience to get CLJS working > with a minimum of fuss, or are there some structural impediments? > > -- > 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] Re: ANN: re-frame 0.1.7 Initial Release
Not defending cursors (I'm new to it all, including ClojureScript), but someone has to play devil's advocate to your devil's advocate :) << - their use can sometimes distort the way you structure you data. Cursors want you to layout data hierarchically (which often fine) but one day you'll find yourself twisting your data structure so as to facilitate Cursor use. >> Wait... are you saying that I can't have a transform function that processes my data from the server before putting it into the atom? After all, unless you have a BFF (backend for front-end) you'll almost always need to transform your data for the view. << - Cursors are simple extractors (which abstract away the path). But they are not about "Derived Data" or "Materialised Views". They don't deliver to your view a modified version of the data. Yes, you can modify the data in your view, but that means the view is doing too much. >> Again... the "view" doesn't have to derive, you can derive in transform functions that can be used by any view and can be chained etc So I'm still not getting it. Are you saying that cursors "encourage" rather than "require" and going cursor-less provides less incentive for writing bad code? I think writing bad code and cursors are two separate topics. On Wed, Mar 4, 2015 at 1:15 PM, Mike Thompson wrote: > On Saturday, February 28, 2015 at 1:44:52 AM UTC+11, Erik Price wrote: > > On Thu, Feb 26, 2015 at 7:55 PM, Mike Thompson > wrote: > > > > The key thing for me is: JUST. DON'T. USE. CURSORS. There I said it. > They appear convenient, I know. They are a way of achieving reference > transparency, I know. But I think they are a “local optimum”. Their use > seems to get in the way of a more important data flow paradigm and they > seem to encourage "control" into all the wrong places (components). At > least that's my experience (I did try to love them, really I did :-)). > > > > > > > > I'm fairly new to Reagent, so as far as I can tell, cursors look great. > But it sounds like you've run into situations in which they aren't helpful. > Can you elaborate? > > > Cursors are convenient. You'll get going pretty quickly with them, for > sure. > > But if your app gets a bit bigger you might find some code smell starting > to appear. > > - their use can sometimes distort the way you structure you data. Cursors > want you to layout data hierarchically (which often fine) but one day > you'll find yourself twisting your data structure so as to facilitate > Cursor use. > > - Cursors are simple extractors (which abstract away the path). But they > are not about "Derived Data" or "Materialised Views". They don't deliver to > your view a modified version of the data. Yes, you can modify the data in > your view, but that means the view is doing too much. Take a view that > needs to show the top 20 items in a vector, when sorted by attribute Y. > Now imagine that you have two views on the same data each with different > sort criteria. The underlying data can't be sorted two ways at once. So > the view will have to start doing the sorting. > > - the "write back" feature of Cursors is something I really don't like. As > an app gets bigger, the control logic around updates gets more complicated. > Using writable Cursors is a slippery slope towards more control logic > getting put in the views. > > Overall, I find that Cursor use encourages you to make views do too much, > know too much, which tends to be a problem as apps get bigger. > > > -- > Mike > > > . make your use of Cursors easy, rather than modeling the right way. > > they can sometimes encourage you to structure your data in a tree-like way > ... even though certain way. > - The main problem I have with Cursors is that they are writable. > I've found that they encourage control logic into views. I prefer my > views to be very passive. > > > -- > 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] Re: ANN: re-frame 0.1.7 Initial Release
Writing to cursors from within components (and generally changing app state from within a component) is not a good pattern. You want to have clearly defined places where state mutation can happen, and in the normal case you put those in event handlers (sitting outside the component but being passed the cursor from the component which can be specified during event setup) So this is all about architecture choices, not cursors vs no cursors. On Wed, Mar 4, 2015 at 2:47 PM, Erik Price wrote: > Cool, thanks for following up, Mike. I agree with pretty much everything > you describe, especially writing to cursors from within a Reagent > component. We're using an approach that I'm really happy with (and may blog > about at some point), which mitigates the problems you mention even though > we are using cursors. Cheers! > > e > > On Wed, Mar 4, 2015 at 4:15 PM, Mike Thompson > wrote: > >> On Saturday, February 28, 2015 at 1:44:52 AM UTC+11, Erik Price wrote: >> > On Thu, Feb 26, 2015 at 7:55 PM, Mike Thompson >> wrote: >> > >> > The key thing for me is: JUST. DON'T. USE. CURSORS. There I said it. >> They appear convenient, I know. They are a way of achieving reference >> transparency, I know. But I think they are a “local optimum”. Their use >> seems to get in the way of a more important data flow paradigm and they >> seem to encourage "control" into all the wrong places (components). At >> least that's my experience (I did try to love them, really I did :-)). >> > >> > >> > >> > I'm fairly new to Reagent, so as far as I can tell, cursors look great. >> But it sounds like you've run into situations in which they aren't helpful. >> Can you elaborate? >> >> >> Cursors are convenient. You'll get going pretty quickly with them, for >> sure. >> >> But if your app gets a bit bigger you might find some code smell starting >> to appear. >> >> - their use can sometimes distort the way you structure you data. >> Cursors want you to layout data hierarchically (which often fine) but one >> day you'll find yourself twisting your data structure so as to facilitate >> Cursor use. >> >> - Cursors are simple extractors (which abstract away the path). But they >> are not about "Derived Data" or "Materialised Views". They don't deliver to >> your view a modified version of the data. Yes, you can modify the data in >> your view, but that means the view is doing too much. Take a view that >> needs to show the top 20 items in a vector, when sorted by attribute Y. >> Now imagine that you have two views on the same data each with different >> sort criteria. The underlying data can't be sorted two ways at once. So >> the view will have to start doing the sorting. >> >> - the "write back" feature of Cursors is something I really don't like. >> As an app gets bigger, the control logic around updates gets more >> complicated. Using writable Cursors is a slippery slope towards more >> control logic getting put in the views. >> >> Overall, I find that Cursor use encourages you to make views do too much, >> know too much, which tends to be a problem as apps get bigger. >> >> >> -- >> Mike >> >> >> . make your use of Cursors easy, rather than modeling the right way. >> >> they can sometimes encourage you to structure your data in a tree-like >> way ... even though certain way. >> - The main problem I have with Cursors is that they are writable. >> I've found that they encourage control logic into views. I prefer my >> views to be very passive. >> >> >> -- >> 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. > -- 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: ANN: re-frame 0.1.7 Initial Release
<< I much rather have unidirectional data flow and have ui/dom events only dispatch messages back. So view model data -> ui -> messages >> Ah! Enlightenment. Thank you. On Wed, Mar 4, 2015 at 3:51 PM, Daniel Kersten wrote: > I've been using Om (and therefore cursors) heavily for almost a year and > am finding myself moving further and further away from cursor. The issue > for me is absolutely the write-back - allowing your views to write to them > encourages your code to do so and encourages a style where your ui/dom > event handlers mutate data. I feel like this is an anti pattern that makes > it difficult to properly manage your state as the application grows unless > you are very disciplined. I much rather have unidirectional data flow and > have ui/dom events only dispatch messages back. So view model data -> ui -> > messages > > The messages can then be handled to update the view model or whatever in a > managed way. It's very similar to flux and similar architectures. > > Mainly this buys you purer (in the functional sense) code, easier > automated tests, easier to understand/reason about flow of data and > ultimately a simpler design. > > That's my opinion at least. > > > On Wed, 4 Mar 2015 22:57 Marc Fawzi wrote: > >> Writing to cursors from within components (and generally changing app >> state from within a component) is not a good pattern. You want to have >> clearly defined places where state mutation can happen, and in the normal >> case you put those in event handlers (sitting outside the component but >> being passed the cursor from the component which can be specified during >> event setup) >> >> So this is all about architecture choices, not cursors vs no cursors. >> >> >> On Wed, Mar 4, 2015 at 2:47 PM, Erik Price wrote: >> >>> Cool, thanks for following up, Mike. I agree with pretty much everything >>> you describe, especially writing to cursors from within a Reagent >>> component. We're using an approach that I'm really happy with (and may blog >>> about at some point), which mitigates the problems you mention even though >>> we are using cursors. Cheers! >>> >>> e >>> >>> On Wed, Mar 4, 2015 at 4:15 PM, Mike Thompson >> > wrote: >>> >>>> On Saturday, February 28, 2015 at 1:44:52 AM UTC+11, Erik Price wrote: >>>> > On Thu, Feb 26, 2015 at 7:55 PM, Mike Thompson >>>> wrote: >>>> > >>>> > The key thing for me is: JUST. DON'T. USE. CURSORS. There I said >>>> it. They appear convenient, I know. They are a way of achieving reference >>>> transparency, I know. But I think they are a “local optimum”. Their use >>>> seems to get in the way of a more important data flow paradigm and they >>>> seem to encourage "control" into all the wrong places (components). At >>>> least that's my experience (I did try to love them, really I did :-)). >>>> > >>>> > >>>> > >>>> > I'm fairly new to Reagent, so as far as I can tell, cursors look >>>> great. But it sounds like you've run into situations in which they aren't >>>> helpful. Can you elaborate? >>>> >>>> >>>> Cursors are convenient. You'll get going pretty quickly with them, for >>>> sure. >>>> >>>> But if your app gets a bit bigger you might find some code smell >>>> starting to appear. >>>> >>>> - their use can sometimes distort the way you structure you data. >>>> Cursors want you to layout data hierarchically (which often fine) but one >>>> day you'll find yourself twisting your data structure so as to facilitate >>>> Cursor use. >>>> >>>> - Cursors are simple extractors (which abstract away the path). But >>>> they are not about "Derived Data" or "Materialised Views". They don't >>>> deliver to your view a modified version of the data. Yes, you can modify >>>> the data in your view, but that means the view is doing too much. Take a >>>> view that needs to show the top 20 items in a vector, when sorted by >>>> attribute Y. Now imagine that you have two views on the same data each >>>> with different sort criteria. The underlying data can't be sorted two ways >>>> at once. So the view will have to start doing the sorting. >>>> >>>> - the "write back" feature of Cursors is something I
Re: [ClojureScript] Re: ANN: re-frame 0.1.7 Initial Release
btw Daniel, If you care to discuss more deeply, what we do is use fine-grained cursors so the two-way cycles are avoided (since each cursor updates only the data for the given component *instance* and not for any other component or any other instance) But I like centralizing state changes into a state manager and your idea of event handlers emitting state change events is very useful to make that work. Thank you again for your input. On Wed, Mar 4, 2015 at 3:57 PM, Marc Fawzi wrote: > << > I much rather have unidirectional data flow and have ui/dom events only > dispatch messages back. So view model data -> ui -> messages > >> > > Ah! Enlightenment. > > Thank you. > > > > > On Wed, Mar 4, 2015 at 3:51 PM, Daniel Kersten wrote: > >> I've been using Om (and therefore cursors) heavily for almost a year and >> am finding myself moving further and further away from cursor. The issue >> for me is absolutely the write-back - allowing your views to write to them >> encourages your code to do so and encourages a style where your ui/dom >> event handlers mutate data. I feel like this is an anti pattern that makes >> it difficult to properly manage your state as the application grows unless >> you are very disciplined. I much rather have unidirectional data flow and >> have ui/dom events only dispatch messages back. So view model data -> ui -> >> messages >> >> The messages can then be handled to update the view model or whatever in >> a managed way. It's very similar to flux and similar architectures. >> >> Mainly this buys you purer (in the functional sense) code, easier >> automated tests, easier to understand/reason about flow of data and >> ultimately a simpler design. >> >> That's my opinion at least. >> >> >> On Wed, 4 Mar 2015 22:57 Marc Fawzi wrote: >> >>> Writing to cursors from within components (and generally changing app >>> state from within a component) is not a good pattern. You want to have >>> clearly defined places where state mutation can happen, and in the normal >>> case you put those in event handlers (sitting outside the component but >>> being passed the cursor from the component which can be specified during >>> event setup) >>> >>> So this is all about architecture choices, not cursors vs no cursors. >>> >>> >>> On Wed, Mar 4, 2015 at 2:47 PM, Erik Price wrote: >>> >>>> Cool, thanks for following up, Mike. I agree with pretty much >>>> everything you describe, especially writing to cursors from within a >>>> Reagent component. We're using an approach that I'm really happy with (and >>>> may blog about at some point), which mitigates the problems you mention >>>> even though we are using cursors. Cheers! >>>> >>>> e >>>> >>>> On Wed, Mar 4, 2015 at 4:15 PM, Mike Thompson < >>>> m.l.thompson...@gmail.com> wrote: >>>> >>>>> On Saturday, February 28, 2015 at 1:44:52 AM UTC+11, Erik Price wrote: >>>>> > On Thu, Feb 26, 2015 at 7:55 PM, Mike Thompson >>>>> wrote: >>>>> > >>>>> > The key thing for me is: JUST. DON'T. USE. CURSORS. There I said >>>>> it. They appear convenient, I know. They are a way of achieving reference >>>>> transparency, I know. But I think they are a “local optimum”. Their use >>>>> seems to get in the way of a more important data flow paradigm and they >>>>> seem to encourage "control" into all the wrong places (components). At >>>>> least that's my experience (I did try to love them, really I did :-)). >>>>> > >>>>> > >>>>> > >>>>> > I'm fairly new to Reagent, so as far as I can tell, cursors look >>>>> great. But it sounds like you've run into situations in which they aren't >>>>> helpful. Can you elaborate? >>>>> >>>>> >>>>> Cursors are convenient. You'll get going pretty quickly with them, for >>>>> sure. >>>>> >>>>> But if your app gets a bit bigger you might find some code smell >>>>> starting to appear. >>>>> >>>>> - their use can sometimes distort the way you structure you data. >>>>> Cursors want you to layout data hierarchically (which often fine) but one >>>>> day you'll find yourself twisting your data struct
Re: [ClojureScript] Re: ANN: re-frame 0.1.7 Initial Release
I understand regarding nested components, makes lots of sense and r/wrap should help, but I've yet to use it personally since I'm just literally starting to write my first Reagent app I think the missing part of the picture you're painting is that components can have specialized instances, so a reusable input box may take first name, last name, or email or etc, and sending the whole form-data sub-tree for input to the input component (i.e. first name, last name, email, all that) means that typing the first name into the input box will cause all other instances of the input box (ones holding last name, email, etc) to update. So I tend to send down only the slice of the atom that is required by the given instance. I'll present a more comprehensive architecture including State Manager as a re-usable abstraction (!) Please keep discussing to whatever depth necessary, I'm sure my thinking on this is still lacking. p.s. the 1st meetup in SF will be announced tomorrow so a bunch of us can talk live about this stuff On Wed, Mar 4, 2015 at 4:48 PM, Daniel Kersten wrote: > I do find cursors fantastic for reusable isolated components. For example > if I have a widget that edits some data, I find it useful to give that > widget a cursor that it may modify, but it needs to be managed by the > parent so that what happens to the data is transparent to the widget. The > parent might then actually dispatch messages and the cursor is only really > for one layer on the boundaries. Reagents (r/wrap data func ...) seems > ideal for this. > > I hope that makes sense - typing on a phone right now. I'd be happy to > discuss more tomorrow when I have a real keyboard. > > > On Thu, 5 Mar 2015 00:26 Marc Fawzi wrote: > >> btw Daniel, >> >> If you care to discuss more deeply, what we do is use fine-grained >> cursors so the two-way cycles are avoided (since each cursor updates only >> the data for the given component *instance* and not for any other component >> or any other instance) >> >> But I like centralizing state changes into a state manager and your idea >> of event handlers emitting state change events is very useful to make that >> work. >> >> Thank you again for your input. >> >> >> >> On Wed, Mar 4, 2015 at 3:57 PM, Marc Fawzi wrote: >> >>> << >>> I much rather have unidirectional data flow and have ui/dom events only >>> dispatch messages back. So view model data -> ui -> messages >>> >> >>> >>> Ah! Enlightenment. >>> >>> Thank you. >>> >>> >>> >>> >>> On Wed, Mar 4, 2015 at 3:51 PM, Daniel Kersten >>> wrote: >>> >>>> I've been using Om (and therefore cursors) heavily for almost a year >>>> and am finding myself moving further and further away from cursor. The >>>> issue for me is absolutely the write-back - allowing your views to write to >>>> them encourages your code to do so and encourages a style where your ui/dom >>>> event handlers mutate data. I feel like this is an anti pattern that makes >>>> it difficult to properly manage your state as the application grows unless >>>> you are very disciplined. I much rather have unidirectional data flow and >>>> have ui/dom events only dispatch messages back. So view model data -> ui -> >>>> messages >>>> >>>> The messages can then be handled to update the view model or whatever >>>> in a managed way. It's very similar to flux and similar architectures. >>>> >>>> Mainly this buys you purer (in the functional sense) code, easier >>>> automated tests, easier to understand/reason about flow of data and >>>> ultimately a simpler design. >>>> >>>> That's my opinion at least. >>>> >>>> >>>> On Wed, 4 Mar 2015 22:57 Marc Fawzi wrote: >>>> >>>>> Writing to cursors from within components (and generally changing app >>>>> state from within a component) is not a good pattern. You want to have >>>>> clearly defined places where state mutation can happen, and in the normal >>>>> case you put those in event handlers (sitting outside the component but >>>>> being passed the cursor from the component which can be specified during >>>>> event setup) >>>>> >>>>> So this is all about architecture choices, not cursors vs no cursors. >>>>> >>>>> >>>>> On Wed, Mar 4, 2015 at 2:47 PM, Erik Price wrote: >>>
[ClojureScript] SF/Bay Area Reagent Meetup: 1st Meetup Announced
Our first and most modest contribution to the Reagent/ClojureScript communities: http://www.meetup.com/Reagent-Minimalistic-React-for-ClojureScript/events/220930045/ Please come and discuss Reagent with us! -- 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: ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
Hi Mike/Mike, What are reactions? and where in re-frame are they used or documented (at least in code)? I'm very curious as to why Dan hasn't documented them. re they experimental or supposed to be for Reagent's own internal use? Marc On Mon, Mar 9, 2015 at 8:14 AM, Mike Haney wrote: > I'm really enjoying re-frame. I've tried several different architectures > over the last 6 months and ended up with something about 80% similar to the > re-frame approach. The key piece missing for me was reactions - there is > absolutely no documentation on them in Reagent, but knowing about them now > solves so many problems. > > I recently started a side project and since it's in very early stages, I > decided to switch it to re-frame over the weekend. I'm quite pleased with > the results so far. Anyone who wants to follow along can check it out at > https://github.com/mdhaney/homesale-clj > > I welcome feedback, and am happy to help with re-frame itself wherever I > can. > > -- > 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] ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
I'm sure it is! The only issue I have at a very high level is that SPA frameworks should intrinsically support re-usable component at the architecture level. If this one does then I'm def going into it head first. But I hear that it may not. Either way, I'm going to get educated about reactions ... I saw they're used everywhere in ratomtest.cljs https://github.com/reagent-project/reagent/blob/19a384443f6353875cc4a0eef468e45f5411d2c5/test/reagenttest/testratom.cljs Thank u Jamie On Mon, Mar 9, 2015 at 8:56 AM, Jamie Orchard-Hays wrote: > Marc, it's all here: > > https://github.com/Day8/re-frame > > and here: > > https://github.com/Day8/re-frame/wiki > > Mike has done an excellent job of writing explanations. I spent a bunch of > time last week reading through and taking some notes. It's worth it. I was > a big advocate of cursurs (in fact I abandoned Reagent last Summer because > Om's cursors solved the immediate problem I was having in Reagent) but > Mike's examples and arguments in his Re-Frame docs have changed my mind. > The approach he presents is very compelling. > > Fortunately, I have some work coming up that will enable me to dig into > this stuff for an actual need. > > Jamie > > > On Mar 9, 2015, at 11:29 AM, Marc Fawzi wrote: > > Hi Mike/Mike, > > What are reactions? and where in re-frame are they used or documented (at > least in code)? > > I'm very curious as to why Dan hasn't documented them. re they > experimental or supposed to be for Reagent's own internal use? > > Marc > > On Mon, Mar 9, 2015 at 8:14 AM, Mike Haney wrote: > >> I'm really enjoying re-frame. I've tried several different architectures >> over the last 6 months and ended up with something about 80% similar to the >> re-frame approach. The key piece missing for me was reactions - there is >> absolutely no documentation on them in Reagent, but knowing about them now >> solves so many problems. >> >> I recently started a side project and since it's in very early stages, I >> decided to switch it to re-frame over the weekend. I'm quite pleased with >> the results so far. Anyone who wants to follow along can check it out at >> https://github.com/mdhaney/homesale-clj >> >> I welcome feedback, and am happy to help with re-frame itself wherever I >> can. >> >> -- >> 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. > > > -- > 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] ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
one glance at the re-frame wiki (searched for: reaction) https://github.com/Day8/re-frame/search?utf8=%E2%9C%93&q=reaction and I realize now it's some form of pub-sub ... so I can guess the kind of abstraction Mike built and if I'm guessing right it should provide more control than cursors ... Will dig into it this week. On Mon, Mar 9, 2015 at 9:25 AM, Marc Fawzi wrote: > I'm sure it is! > > The only issue I have at a very high level is that SPA frameworks should > intrinsically support re-usable component at the architecture level. If > this one does then I'm def going into it head first. But I hear that it may > not. > > Either way, I'm going to get educated about reactions ... I saw they're > used everywhere in ratomtest.cljs > > > https://github.com/reagent-project/reagent/blob/19a384443f6353875cc4a0eef468e45f5411d2c5/test/reagenttest/testratom.cljs > > Thank u Jamie > > On Mon, Mar 9, 2015 at 8:56 AM, Jamie Orchard-Hays > wrote: > >> Marc, it's all here: >> >> https://github.com/Day8/re-frame >> >> and here: >> >> https://github.com/Day8/re-frame/wiki >> >> Mike has done an excellent job of writing explanations. I spent a bunch >> of time last week reading through and taking some notes. It's worth it. I >> was a big advocate of cursurs (in fact I abandoned Reagent last Summer >> because Om's cursors solved the immediate problem I was having in Reagent) >> but Mike's examples and arguments in his Re-Frame docs have changed my >> mind. The approach he presents is very compelling. >> >> Fortunately, I have some work coming up that will enable me to dig into >> this stuff for an actual need. >> >> Jamie >> >> >> On Mar 9, 2015, at 11:29 AM, Marc Fawzi wrote: >> >> Hi Mike/Mike, >> >> What are reactions? and where in re-frame are they used or documented (at >> least in code)? >> >> I'm very curious as to why Dan hasn't documented them. re they >> experimental or supposed to be for Reagent's own internal use? >> >> Marc >> >> On Mon, Mar 9, 2015 at 8:14 AM, Mike Haney wrote: >> >>> I'm really enjoying re-frame. I've tried several different >>> architectures over the last 6 months and ended up with something about 80% >>> similar to the re-frame approach. The key piece missing for me was >>> reactions - there is absolutely no documentation on them in Reagent, but >>> knowing about them now solves so many problems. >>> >>> I recently started a side project and since it's in very early stages, I >>> decided to switch it to re-frame over the weekend. I'm quite pleased with >>> the results so far. Anyone who wants to follow along can check it out at >>> https://github.com/mdhaney/homesale-clj >>> >>> I welcome feedback, and am happy to help with re-frame itself wherever I >>> can. >>> >>> -- >>> 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. >> >> >> -- >> 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-usable Component Standard // [ClojureScript] ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
Will do and ask more questions... I'd like to approach it from the point of view of someone interested in both SPA and re-usable components that can be shared with Reagent, Om and other FRP-like ClojureScript SPA implementations The idea is if we can build SPAs any way we like (e.g. re-frame, vanilla Reagent/Secretary, Om+?, etc) but be able to share components amongst us that will help ClojureScript in the long run 80% of the web uses jQuery plugins (I heard that on HN, no reference, so it may be wrong but I think it's probably close) and no SPA framework can claim that. I was thinking that if we have a re-usable component standard then each SPA framework will figure out a way to work with such components, but in defining that standard we have to understand all the different SPA architectures that are likely to succeed ... and you guys are saying re-frame is likely to succeed, so it's high up on my list, with my interest centering around how it would work with reusable components when I asked Mike T said it's an SPA framework not a reusable component architecture but i think the two should work together .. He did also say that they're working on reusable components So with that said, I look forward to understanding how we can, as a community of developers all speaking speaking the same language (clojurescript), get to discussing standards that will help us share units of functionality rather than build A for framework ABC and build A again for framework XYZ Does that make sense? Marc On Mon, Mar 9, 2015 at 10:35 AM, Mike Haney wrote: > Read the whole README for re-frame and it will all make more sense. > > I don't think reactions are pub/sub - usually those are implemented using > atom watches. The event dispatch mechanism, however, is like pub/sub. I > noticed the library uses core.async, so they very well may be using > core.async pub/sub, although I haven't dug into the library code yet so I > might be wrong. > > -- > 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] ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
Since when can an Angular component work as is in a React environment or a Backbone "component" (view) work in another Backbone implementation without changes? That is what I mean, and I don't have to get into the re-frame specifics to tell you that a component built for my architecture won't work out of the box with your architecture or at least it won't leverage it properly. This is the ABC of app development: components are built to leverage the abstractions offered by specific frameworks. Web Components were supposed to change all that but they're stuck in standardization hell, four years now. There is no confusion on my part that so far we've been building React components, Backbone views (some based on handlebars and some on underscore and some on custom view layers etc) and Angular components, and all those "Components" are framework specific. So if you've come up with a framework that can work with ANY component architecture then that must be some great innovation because I'm not sure how you'd be able to account for all the services and framework facilities that a given component expects. If we don't have a Standard for reusable components in ClojureScript that crosses SPA framework boundary we will not have anything better than what is available in JS in terms of re-use potential of components across frameworks. On Mon, Mar 9, 2015 at 8:17 PM, Mike Thompson wrote: > On Tuesday, March 10, 2015 at 3:26:30 AM UTC+11, marc fawzi wrote: > > I'm sure it is! > > > > > > The only issue I have at a very high level is that SPA frameworks should > intrinsically support re-usable component at the architecture level. If > this one does then I'm def going into it head first. But I hear that it may > not. > > Marc, you really just have to read the docs. Honestly. > > Then realise that MVC frameworks don't mandate any re-usable components -- > ember doesn't, angular doesn't and re-frame doesn't. Neither do you want > them to. An MVC framework is mostly about overall plumbing. You can then > use whatever fancy reusable components you want on top of that. Don't get > the two confused -- they are different layers. > > -- > Mike > > > -- > 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] ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
The miscommunication I see is this: In many SPA frameworks like Angular and Ember, the resuable components cannot work as is across frameworks. Therefore, they have certain dependencies on the framework that cannot be packaged and carried across the framework boundary. Try taking an Angular widget and using it out of the box with Meteor or Ember (well, Ember and Angular just announced a partnership so that may actually be coming! not a great example but translate that to components should be reusable across "SPA frameworks using React for view layer" If we don't have a standard for reusable components then what I may develop my components for "SPA Framework XYZ using React for view layer" (say my own Reagent SPA framework) may not work out of the box on "SPA Framework ABC using React for view layer" (say re-frame) because I did not design my components for out-of-the-box re-usability across "all frameworks that use React for view layer" For example, I may have expected the framework to have a state manager that does all state updates, or I may have expected a data caching service where instead the other framework keeps refetching data, so I may have time breaks in the UX that I didn't expect. What does a framework need to have at minimum besides React for the view layer? And more importantly how should I define my component (in code) in order for it to be usable by any SPA framework using React for view layer? (e.g. Om+etc) Do we have a standard for that? if not, then how will I be able to keep hopping on the latest greatest SPA framework that uses React for view layer? I wouldn't be able to. I'd be wedded to the framework where my components work On Mon, Mar 9, 2015 at 9:14 PM, Mike Thompson wrote: > On Tuesday, March 10, 2015 at 2:35:24 PM UTC+11, marc fawzi wrote: > > Since when can an Angular component work as is in a React environment or > a Backbone "component" (view) work in another Backbone implementation > without changes? > > > > > > That is what I mean, and I don't have to get into the re-frame specifics > to tell you that a component built for my architecture won't work out of > the box with your architecture or at least it won't leverage it properly. > > > > > > This is the ABC of app development: components are built to leverage the > abstractions offered by specific frameworks. Web Components were supposed > to change all that but they're stuck in standardization hell, four years > now. > > > > > > There is no confusion on my part that so far we've been building React > components, Backbone views (some based on handlebars and some on underscore > and some on custom view layers etc) and Angular components, and all those > "Components" are framework specific. > > > > > > So if you've come up with a framework that can work with ANY component > architecture then that must be some great innovation because I'm not sure > how you'd be able to account for all the services and framework facilities > that a given component expects. > > > > > > If we don't have a Standard for reusable components in ClojureScript > that crosses SPA framework boundary we will not have anything better than > what is available in JS in terms of re-use potential of components across > frameworks. > > > > There quite a miscommunication happening here. I was saying that you can > build lots of different re-usable component libraries on top of Angular. > Angular doesn't mandate one. The Angular widget libraries and Angular are > different layers. > > Similarly, re-frame doesn't mandate a single reagent reusable component > library. In the future there might be many, who knows. re-frame and a > reagent reusable component library are different layers. > > -- > Mike > > > > -- > 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] ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
I understand the practical futility of my call to have a standard for reusable components that allows us as users to carry our investment forward to the next great framework. But expressing it allows me to think a little deeper about the possible solution. Thank you for engaging and pouring so much effort into a new paradigm that we can learn from, critique or choose to adopt. They are all good things. Love to chat in person one of those days! Sent from my iPhone > On Mar 10, 2015, at 12:44 AM, Mike Thompson wrote: > >> On Tuesday, March 10, 2015 at 4:18:41 PM UTC+11, marc fawzi wrote: >> The miscommunication I see is this: >> >> >> In many SPA frameworks like Angular and Ember, the resuable components >> cannot work as is across frameworks. Therefore, they have certain >> dependencies on the framework that cannot be packaged and carried across the >> framework boundary. Try taking an Angular widget and using it out of the box >> with Meteor or Ember (well, Ember and Angular just announced a partnership >> so that may actually be coming! not a great example but translate that to >> components should be reusable across "SPA frameworks using React for view >> layer" >> >> >> If we don't have a standard for reusable components then what I may develop >> my components for "SPA Framework XYZ using React for view layer" (say my own >> Reagent SPA framework) may not work out of the box on "SPA Framework ABC >> using React for view layer" (say re-frame) because I did not design my >> components for out-of-the-box re-usability across "all frameworks that use >> React for view layer" For example, I may have expected the framework to have >> a state manager that does all state updates, or I may have expected a data >> caching service where instead the other framework keeps refetching data, so >> I may have time breaks in the UX that I didn't expect. What does a framework >> need to have at minimum besides React for the view layer? And more >> importantly how should I define my component (in code) in order for it to be >> usable by any SPA framework using React for view layer? (e.g. Om+etc) >> >> >> Do we have a standard for that? if not, then how will I be able to keep >> hopping on the latest greatest SPA framework that uses React for view layer? >> I wouldn't be able to. I'd be wedded to the framework where my components >> work > > > My design goals for re-frame appear more modest than yours. > > > -- > Mike > > > -- > 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] Re: Dead Code Elimination
absolutely wild guess:
the compiler builds a call graph and any function that is not part of the
call graph is eliminated
(def x {:a 1 :b 2}) does not return a function but x maybe used inside some
function, so I'm assuming the compiler just leaves it there
why would it be hard to see if x is or is not used by some function that
is in the call graph? i think that is a more involved job that building a
call graph
On Tue, Mar 10, 2015 at 5:47 PM, Mike Thompson
wrote:
> On Wednesday, March 11, 2015 at 11:19:28 AM UTC+11, Mike Thompson wrote:
> > This issue from David Nolen, caught my eye:
> > https://github.com/andrewmcveigh/cljs-time/issues/21
> >
> > Feels like there is important information there, but I just don't know
> enough to interpret what's said. Can anyone help?
> >
> > If I have this:
> >
> > (def x {:a 1 :b 2})
> >
> > David is saying that x can't be dead-code-eliminated. Correct?
> >
> > If so, the solution he talks about is?
> >
> > ;; Replacing PersistentHashMaps with functions? Can't be right. I think
> I'm being too literal here
> > (def x ((fn [] {:a 1 :b2})))
> >
> > ;; more likely this?
> >
> > (defn x
> > []
> > {:a 1 :b 2})
> >
> > Ie. you must now "call" x to get the map.
> >
> > If this solution is the right one, doesn't that mean we would be
> inefficiently constructing the (potentially large) hashmap inside x on each
> call.
>
>
> Two follow-on questions:
>
>- Could this problem with PersistentHashMaps not being dead code
> eliminated be fixed with correct application of the Closure's
> "@nosideeffects" tags? Ie. if the function which creates
> PersistentHashMaps had this tag in its comment?
>
> - I assume that the following is not a problem:
>
> (defn y [] :y)
> (def x y)
>
> If both x and y are never used then both will be dead code eliminated.
>
> --
> Mike
>
>
> --
> 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] Dead Code Elimination
<<
This is puzzling. I have just run some tests and top level data structures
do appear to be eliminated.
For example: (def x {:a "" :b 2})
I was NOT able to find the string "" in the JavaScript compiled
under ":optimizations :advanced".
Can you provide any more clarity on this rule?
>>
I used this online closure instance:
http://closure-compiler.appspot.com/home
and selected "Advanced" optimization
then entered this:
a = {name: "test"} // a is top level i.e. window.a = {name: "test"}
function abc() { // abc() is also top level i.e. window.abc = function
abc() { return true}
return true
}
Output:
a={name:"test"};
// where did abc() go? never called so it's eliminated, but what about a?
If you were to enter:
var a = {name: "test"}
function abc() {
return true
}
you'll get 0 bytes in output
now if you enter:
window.a = {name: "test"}
window.abc = function abc() {
return true
}
you get:
window.a={name:"test"};window.b=function(){return!0};
so then one (or only?) way an unused function is eliminated while an unused
variable is not is if they somehow are converted to JS as:
a = {name: "test"}
function abc() {
return true
}
On Tue, Mar 10, 2015 at 10:08 PM, Gregg Ramsey
wrote:
> This is puzzling. I have just run some tests and top level data structures
> do appear to be eliminated.
>
> For example: (def x {:a "" :b 2})
>
> I was NOT able to find the string "" in the JavaScript compiled
> under ":optimizations :advanced".
>
> Can you provide any more clarity on this rule?
>
>
> On Wednesday, 11 March 2015 13:49:52 UTC+11, David Nolen wrote:
> > If you want your library to be dead code elimination friendly don't use
> top level data structures.
> >
> >
> > It's a very simple rule.
> >
> >
> > David
> >
> >
> > On Tue, Mar 10, 2015 at 8:19 PM, Mike Thompson
> wrote:
> > This issue from David Nolen, caught my eye:
> >
> > https://github.com/andrewmcveigh/cljs-time/issues/21
> >
> >
> >
> > Feels like there is important information there, but I just don't know
> enough to interpret what's said. Can anyone help?
> >
> >
> >
> > If I have this:
> >
> >
> >
> > (def x {:a 1 :b 2})
> >
> >
> >
> > David is saying that x can't be dead-code-eliminated. Correct?
> >
> >
> >
> > If so, the solution he talks about is?
> >
> >
> >
> > ;; Replacing PersistentHashMaps with functions? Can't be right. I think
> I'm being too literal here
> >
> > (def x ((fn [] {:a 1 :b2})))
> >
> >
> >
> > ;; more likely this?
> >
> >
> >
> > (defn x
> >
> > []
> >
> > {:a 1 :b 2})
> >
> >
> >
> > Ie. you must now "call" x to get the map.
> >
> >
> >
> > If this solution is the right one, doesn't that mean we would be
> inefficiently constructing the (potentially large) hashmap inside x on each
> call.
> >
> >
> >
> > --
> >
> > Mike
> >
> >
> >
> >
> >
> > --
> >
> > 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] ANN: re-frame v0.2.0 - an FRP MVC pattern for writing SPAs in Reagent. (Woah, so many LTAs!!)
Kyle, I've been watching and interacting with browser vendors as they try so hard to come to agreement on the spec, but none so far after 4 years. The Webkit team and IE team have not adopted it yet. and the discussion on reaching consensus for a minimum viable web component spec is still ongoing, so I expect a couple more ears before a break thru. That's two in dog years. A very long time I think. And I'm honestly not sure about the whole web component spec as it relates to shadow dom; it seems to be edge case driven and I think far more complicated than it could be. My thinking is leaning toward build-time porting of components from one framework to another. You do it once and you're set. But that too should not over stretch to cover its own set of edge cases and what if's. I think at some point we will learn to build components that can be easily ported over to whatever framework using automated tools and some manual refactoring. Not sure how hard that is but I would bet it's easier than what the folks over at Google have been dealing with trying to get one spec for Web Components that all browser vendors would be willing to implement. Sent from my iPhone > On Mar 10, 2015, at 11:42 AM, Kyle Cordes > wrote: > >> On March 10, 2015 at 11:31:29 AM, Marc Fawzi >> (marc.fa...@gmail.com(mailto:marc.fa...@gmail.com)) wrote: >> I understand the practical futility of my call to have a standard for >> reusable components that allows us as users to carry our investment forward >> to the next great framework. But expressing it allows me to think a little >> deeper about the possible solution. > > My hunch is that once adoption gets a little wider, "Web Components" will be > the standard under which reusable across framework components appear. Because > that standard will have browsers direct support and will not be specific to > any one language etc., it will likely have an order or two of magnitude more > components available than anything specific to React or CLJS etc. > > So the answer will be: if you want access to a pool of reusable components, > make sure that your framework can both make and consume web components in a > reasonably idiomatic and convenient way. > > > -- > Kyle Cordes > http://kylecordes.com > > > -- > 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] Resources for Getting Started with Clojurescript
I found clojurescript.net to be invaluable and non-intimidating way to try new stuff until I get it right :) Also, google stuff for Clojure rather than ClojureScript unless the issue is specific to the latter. There is a ton more content about Clojure on the web. On Thu, Mar 12, 2015 at 8:50 AM, Jamie Orchard-Hays wrote: > What's your goal? What are you trying to build? > > Jamie > > On Mar 12, 2015, at 9:46 AM, kennyo...@gmail.com wrote: > > > I've got clojurescript set up and used it a bit but I can't say I grok > it. I'm past the Quick Start phase and I'm left with "what now"? > > > > What are some resources where I can learn about cljs idioms and how to > put everything together? I'm quite familiar with clojure but nil when it > comes to the clojurescript specific. > > > > I find myself writing javascript just in a funny syntax and I know it > shouldn't be so. > > > > -- > > 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. > -- 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: clj-ajax, lib-noir and anti-forgery token
Has anyone tried JSON Web Token (JWT) for clj/cljs?
https://github.com/liquidz/clj-jwt
On Thu, Mar 12, 2015 at 10:59 PM, Tim Cross wrote:
> On Friday, 12 December 2014 22:58:24 UTC+11, Cesare wrote:
> > Hi All,
> > I'm not sure this is the right place to ask... anyway: I have a Luminus
> project with cljs template (Clojurescript + Reagent).
> >
> > After upgrading lib-noir (now at 0.9.5), it seems that the anti-forgery
> check is now enabled by default.
> >
> > How can I manage it from ClojureScript, in particular in ajax calls?
> >
> > At the moment I get the error "Invalid anti-forgery token" for POST
> calls.
> >
> > Thanks a lot
> > Bye
>
> I've just managed to work out how to do this. Actually, there are a number
> of ways to do it, but I think, given you are using luminus, this is the
> easiest.
>
> The basic idea is to add a javascript variable to the page which holds the
> anti-forgery token. Luminus makes this quite easy as it already adds the
> csrf-token variable as a standard part of the selmer template. If you add
>
>
> var csrf = "{{csrf-token}}";
>
>
> to the page template, then your clojurescript can get the value in js/csrf
> and either use that to setup the hidden variable in your javascript
> generated forms or if you are doing something like cljs-ajax, add it to the
> headers when makeing the request to the server.
>
> --
> 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] Re: re-frame with a large application
<< The main difference with re-frame is that we allow components to subscribe to events in order to manage their local state as we don't keep everything in the app state. >> That's very cool if what you mean is storing state that no other part of the app needs to know about, like the keys being entered into an input field etc << There is some reference data common to every module which is the only part accessed by everyone (using the Om ref-cursors). >> Can you give examples? Let's say I have two components that use the same derived or raw data, I would put that data outside of app state, into a data store/cache/indexeddb/etc On Tue, Mar 17, 2015 at 7:14 AM, wrote: > On Monday, March 16, 2015 at 8:53:59 PM UTC+1, Michael Campagnaro wrote: > > First off, re-frame looks really great, Mike. Thanks for writing it. > > > > My team has been working on a Reagent SPA for half a year and it's our > first CLJS project so we are feeling some pain due to design choices that > were not the best. We really like the re-frame pattern and want to > transition over to it. I'm attempting to work out a plan for this. Either > creating a new app on the side and porting code over to use re-frame or > gutting the current app in place. > > > > Since re-frame is so new it's hard to tell what the limitations are. On > one hand the codebase is small, simple and nothing stands out as being a > potential problem in a large app. On the other hand I can't help but be > skeptical and curious :) > > > > So I'd love to hear about anyone's experience using re-frame to power a > non-trivial app, preferably in production. Are there things that I should > be mindful of when scaling the re-frame pattern? > > We've been using a very similar approach to re-frame in production for > almost a year now (with Om instead of Reagent). The app isn't huge, but > it's a couple thousand lines of cljs. The main difference with re-frame is > that we allow components to subscribe to events in order to manage their > local state as we don't keep everything in the app state. > > The app is split into a namespace group for each module of functionality, > with each group having its own handlers for application events, remote > endpoints and components. > > There is one state atom for the whole application, although every module > gets it's own state under a separate key in the state map. There is some > reference data common to every module which is the only part accessed by > everyone (using the Om ref-cursors). > > I feel that the re-frame architecture scales very well if you are > consistent in naming and separating the responsibilities. > > -- > 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] Fwd: [reagent] angular phonecat in re-frame
Fwd: angular phonecat done in re-frame/reagent -- Forwarded message -- From: Dhruv Parthasarathy Date: Tue, Mar 17, 2015 at 2:30 AM Subject: [reagent] angular phonecat in re-frame To: reagent-proj...@googlegroups.com Hey all, I've ported the angular phonecat tutorial to re-frame, Mike Thompson's excellent framework for Single Page Apps heavily based on Reagent. You can see the tutorial here: https://github.com/dhruvp/angular-phonecat-re-frame It is similar to (and inspired by) vvvalvalval's work in many ways but focuses on applying reagent in the context of re-frame and has explanations for each of the steps. In addition, I have diffs to show what actions where taken between subsequent steps (they aren't perfect - need to get better at rebasing haha). Please let me know your thoughts! There definitely is room for it to improve and I'd appreciate your feedback. Thanks! Dhruv -- You received this message because you are subscribed to the Google Groups "Reagent-Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to reagent-project+unsubscr...@googlegroups.com. To post to this group, send email to reagent-proj...@googlegroups.com. Visit this group at http://groups.google.com/group/reagent-project. For more options, visit https://groups.google.com/d/optout. -- 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.
Fwd: [ClojureScript] Anyone interested in some remote CLJS/Om development work?
I started is a list for that. CC-ing Begin forwarded message: > Hi All > > (I'm not sure how people feel about recruiting on this group. Please pull me > up if I'm out of line.) > > I'm a small software consultancy in Australia - two developers, two part time > graduates. I'd like extra bandwidth to help me with some clojurescript work. > Finding local experience is difficult, I'd love options while I'm training > up a junior. > > My feeling is that developing Om components for reuse in apps would be > relatively easily done remotely. Nice defined requirements. Easy enough to > QA and code review. Seems like a save first step. > > I'm not after the lowest rate consultants possible. Would much prefer to > work with someone with a level head on a sane wage capable of adding value > and delivering good quality work. I figure the local award rates for > professionals employment in Australia would be attractive in countries > slightly lower down the average wage [1] table but curious to see what the > market rates are typically. > > Would love to hear from anyone interested or anyone who has advice on the > matter generally (tips, recommendations...). > > cheers, Oliver > > [1] http://en.wikipedia.org/wiki/List_of_countries_by_average_wage > > > -- > 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] [OM interop] is it possible to use Om components inside React javascript project?
I think it's possible in Reagent so it should also be possible with Om. In Reagent there is a "reactify" function "Returns an adapter for a Reagent component, that may be used from React, for example in JSX. A single argument, props, is passed to the component, converted to a map." Good luck! Interesting approach to adoption ! Sent from my iPhone > On Mar 17, 2015, at 4:07 PM, "Juan A. Ruz @tangrammer" > wrote: > > Hi guys, > I suppose that it should be possible as soon as Om uses react.js and > clojurescript compiles to javascript, but the question is more likely How > could I use om js compiled components inside a normal javascript project that > is currently using react.js too? > > Thanks! > Juan > > PS: my situation as you can imagine is trying to integrate bit a bit > clojurescript into a javascript company :) > > -- > 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] Re: re-frame with a large application
That's insightful, but let me poke at these statements anyways, and please correct me where I'm wrong... an exercise in learning: << - text input: local state works great until you start to add validation, then it is usually better to have it in global state. Also, clearing form fields on submission is easier to handle with global state. >> I don't save to global state the transient state of each component, only the state of the entire app at the time I'm transitioning the app's sate, e.g. submitting a query. That final state goes into global state. Local state for me, being new to React so forgive me if I'm doing it wrong, is a way for me to tell React to render my keystrokes. I don't need to store those keystrokes in global state until the user hits submit. Then I validate etc. << - loading indicators: local state works fine, until you start handling network errors and have to clear the loading indicator when there's an error. >> Right. I see what you mean, but the loading indicator's local state is accessible to me and can be reset when I detect a network error. In what situations would it be not accessible? (React question) << - collapsed/hidden flags: for drop down menus, nav drawers, etc. Again, it's easier to use global state so you can do things like close the menu when the user clicks away from it (a pet peeve of mine are menus that can only be closed by clicking on the menu itself - argh!). >> Oh again, this is pointing to an issue with accessing a component's local state from outside the component. Is this an issue in React? << I'm finding that most of these things become ridiculously easy with re-frame. Simple example - create a "menu-closing" handler middleware and attach it to any handlers where you want the menu to close. >> I've been reading up on re-frame and it's not a foreign concept to me but I need to think a lot more about the details or missing details. It sounds like it's got some powerful patterns bundled together. On Tue, Mar 17, 2015 at 7:09 PM, Mike Haney wrote: > In my experience, using component local state seems harmless enough in the > beginning, but I almost always find a need to move it to global state as an > app matures. A few common examples: > > - text input: local state works great until you start to add validation, > then it is usually better to have it in global state. Also, clearing form > fields on submission is easier to handle with global state. > > - loading indicators: local state works fine, until you start handling > network errors and have to clear the loading indicator when there's an > error. > > - collapsed/hidden flags: for drop down menus, nav drawers, etc. Again, > it's easier to use global state so you can do things like close the menu > when the user clicks away from it (a pet peeve of mine are menus that can > only be closed by clicking on the menu itself - argh!). > > I'm finding that most of these things become ridiculously easy with > re-frame. Simple example - create a "menu-closing" handler middleware and > attach it to any handlers where you want the menu to close. > > -- > 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] Re: re-frame with a large application
But there is transient state and state that you care to keep. I'm not sure why you would want to put transient state like keyboard input into global state before you actually need to transition app state. At that point grab the input component state and put it in global state, then transition, and now you can undo and redo. On Tue, Mar 17, 2015 at 8:46 PM, Mike Thompson wrote: > On Wednesday, March 18, 2015 at 1:09:12 PM UTC+11, Mike Haney wrote: > > In my experience, using component local state seems harmless enough in > the beginning, but I almost always find a need to move it to global state > as an app matures. A few common examples: > > > > - text input: local state works great until you start to add validation, > then it is usually better to have it in global state. Also, clearing form > fields on submission is easier to handle with global state. > > > > - loading indicators: local state works fine, until you start handling > network errors and have to clear the loading indicator when there's an > error. > > > > - collapsed/hidden flags: for drop down menus, nav drawers, etc. Again, > it's easier to use global state so you can do things like close the menu > when the user clicks away from it (a pet peeve of mine are menus that can > only be closed by clicking on the menu itself - argh!). > > > > I'm finding that most of these things become ridiculously easy with > re-frame. Simple example - create a "menu-closing" handler middleware and > attach it to any handlers where you want the menu to close. > > > Yes, indeed. Synchronizing state is a fraught process. Keep it in the one > place if you can. http://martinfowler.com/bliki/TwoHardThings.html > > -- > 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-framing re-frame
I'm reading this now: https://github.com/Day8/re-frame (so far 30% done with the main Readme) and it appears to be a basic pattern(s) and reference implementation for using Reagent in line with the React Flux architecture. true, false or maybe? I initially resisted the idea because it dumps cursors which I believe all or most ClojureScript React "frameworks" support. I was concerned that doing so means that components can never be written to be portable across ClojureScript UI frameworks that use React and depend on some cursor implementation, but that's a lost cause or less important than having one framework that does what you want and for which reusable components can be developed. After having played around with raw Reagent I found that I can get myself in trouble in so many ways, and I'm hoping re-frame will be the kind of opinionated framework that will isolate us from the "crazy" in "reactive" So is re-frame basically, at the 10,000 foot level, an implementation of the React Flux architecture for Reagent or should I keep reading? Thank you Marc -- 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: re-framing re-frame
Ok, putting it on hold, and reading again next week. Till then if anyone has any thoughts on how it compares to Flux type architectures at the 10,000 foot level, please feel free to enlighten. Thank youooo On Thu, Mar 19, 2015 at 12:30 PM, Marc Fawzi wrote: > I'm reading this now: https://github.com/Day8/re-frame > > (so far 30% done with the main Readme) and it appears to be a basic > pattern(s) and reference implementation for using Reagent in line with the > React Flux architecture. true, false or maybe? > > I initially resisted the idea because it dumps cursors which I believe all > or most ClojureScript React "frameworks" support. I was concerned that > doing so means that components can never be written to be portable across > ClojureScript UI frameworks that use React and depend on some cursor > implementation, but that's a lost cause or less important than having one > framework that does what you want and for which reusable components can be > developed. > > After having played around with raw Reagent I found that I can get myself > in trouble in so many ways, and I'm hoping re-frame will be the kind of > opinionated framework that will isolate us from the "crazy" in "reactive" > > So is re-frame basically, at the 10,000 foot level, an implementation of > the React Flux architecture for Reagent or should I keep reading? > > Thank you > > Marc > > > > -- 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: re-framing re-frame
Mike T is certainly a deep thinker and the contribution is great and entertaining -- I wish all Readme on github were crafted with such poetic touch and philosophical rigor But my gut feeling still on the fence, thinking about how macros work and if they could be useful here, especially after seeing the unexpected ways in which people use it, which is true of anything more complicated than a spoon https://github.com/Day8/re-frame/issues/25#issuecomment-83832855 On Thu, Mar 19, 2015 at 3:29 PM, Karl Guertin wrote: > By my understanding, the core pattern is a flux variation. Differences > from Facebook's original flux pattern: > > There's only one store and it's a global ratom. > > You can compute views from the root store or other derived views using > Reagent's reaction feature. > > Your handlers are expected to be wrapped using a middleware pattern to > handle cross-cutting concerns. > > -- > 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] Re: re-framing re-frame
<< Looking at re-frame from the Flux perspective is like looking at a cone from the side elevation and seeing a triangle. The view is only useful up to a point. >> Reminds me of this! https://johncarlosbaez.wordpress.com/2015/03/17/planets_in_the_4th_dimension/ It's not an ellipse! It's a circle in 4 dimensional space, you puny human! I think these metaphors while entertaining create mental fog in the brain of an elephant. You do want elephants to use use the framework, don't you? I would dumb down the explanation and keep it concise and concrete rather than escaping into higher dimensions whenever someone wants a simple reduction. On Thu, Mar 19, 2015 at 6:38 PM, Mike Thompson wrote: > On Friday, March 20, 2015 at 9:29:44 AM UTC+11, Karl Guertin wrote: > > By my understanding, the core pattern is a flux variation. Differences > from Facebook's original flux pattern: > > > > There's only one store and it's a global ratom. > > > > You can compute views from the root store or other derived views using > Reagent's reaction feature. > > > > > > Your handlers are expected to be wrapped using a middleware pattern to > handle cross-cutting concerns. > > > Given the question, that's a good summary! But I'd be cautious about the > value of the question. > > Looking at re-frame from the Flux perspective is like looking at a cone > from the side elevation and seeing a triangle. The view is only useful up > to a point. > > I'm sure you know that, but I just wanted to draw the point out. > > To me, the Elm Architecture provides a more interesting perspective, than > Flux. > > And from what Facebook said at reactconf, they appear to be heading in the > "derived data all the way down" kinda direction themselves. The data from > declarative queries flowing via Relay/GraphQL into components. Etc, etc. > > -- > Mike > > -- > 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] Re: re-framing re-frame
Now *re-frame* is* "Reactive All The Way Down" ™* Thanks to some Googling, at least as far as setting focus on rendered element when they mount and update, we don't have to target the DOM ... I just couldn't believe that React would not honor the autofocus attribute on input and textareas.. https://github.com/Day8/re-frame/issues/25#issuecomment-83873738 *Attributes supported by React:* accept acceptCharset accessKey action allowFullScreen allowTransparency alt async autoComplete autoFocus autoPlay cellPadding cellSpacing charSet checked classID className cols colSpan content contentEditable contextMenu controls coords crossOrigin data dateTime defer dir disabled download draggable encType form formAction formEncType formMethod formNoValidate formTarget frameBorder height hidden href hrefLang htmlFor httpEquiv icon id label lang list loop manifest marginHeight marginWidth max maxLength media mediaGroup method min multiple muted name noValidate open pattern placeholder poster preload radioGroup readOnly rel required role rows rowSpan sandbox scope scrolling seamless selected shape size sizes span spellCheck src srcDoc srcSet start step style tabIndex target title type useMap value width wmode On Thu, Mar 19, 2015 at 6:54 PM, Marc Fawzi wrote: > << > Looking at re-frame from the Flux perspective is like looking at a cone > from the side elevation and seeing a triangle. The view is only useful up > to a point. > >> > > Reminds me of this! > > > https://johncarlosbaez.wordpress.com/2015/03/17/planets_in_the_4th_dimension/ > > It's not an ellipse! It's a circle in 4 dimensional space, you puny human! > > I think these metaphors while entertaining create mental fog in the brain > of an elephant. You do want elephants to use use the framework, don't you? > > I would dumb down the explanation and keep it concise and concrete rather > than escaping into higher dimensions whenever someone wants a simple > reduction. > > > > > On Thu, Mar 19, 2015 at 6:38 PM, Mike Thompson > wrote: > >> On Friday, March 20, 2015 at 9:29:44 AM UTC+11, Karl Guertin wrote: >> > By my understanding, the core pattern is a flux variation. Differences >> from Facebook's original flux pattern: >> > >> > There's only one store and it's a global ratom. >> > >> > You can compute views from the root store or other derived views using >> Reagent's reaction feature. >> > >> > >> > Your handlers are expected to be wrapped using a middleware pattern to >> handle cross-cutting concerns. >> >> >> Given the question, that's a good summary! But I'd be cautious about the >> value of the question. >> >> Looking at re-frame from the Flux perspective is like looking at a cone >> from the side elevation and seeing a triangle. The view is only useful up >> to a point. >> >> I'm sure you know that, but I just wanted to draw the point out. >> >> To me, the Elm Architecture provides a more interesting perspective, than >> Flux. >> >> And from what Facebook said at reactconf, they appear to be heading in >> the "derived data all the way down" kinda direction themselves. The data >> from declarative queries flowing via Relay/GraphQL into components. Etc, >> etc. >> >> -- >> Mike >> >> -- >> 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] Re: re-framing re-frame
that video was an awesome and illustrative counter-example, made me laugh a lot given enough free time, people will find new and unexpected ways of using any given implement On Thu, Mar 19, 2015 at 9:22 PM, Peter B. West wrote: > > On 20 Mar 2015, at 11:20 am, Marc Fawzi wrote: > > > > > > Mike T is certainly a deep thinker and the contribution is great and > entertaining -- I wish all Readme on github were crafted with such poetic > touch and philosophical rigor > > > > But my gut feeling still on the fence, thinking about how macros work > and if they could be useful here, especially after seeing the unexpected > ways in which people use it, which is true of anything more complicated > than a spoon > > https://www.youtube.com/watch?v=6TS9ugnarQQ > > Peter West > The man believed the word that Jesus spoke to him and went his way. > > -- > 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] Re: Why, in principle, can't macros be defined in ClojureScript itself?
seen this? https://gist.github.com/alandipert/4669472 "ClojureScript does not have a standalone macro system. To write ClojureScript macros, one must write them in Clojure and then refer to them in ClojureScript code. This situation is workable, but at a minimum it forces one to keep ClojureScript code and the macros it invokes in separate files. I miss the locality of regular Clojure macros, so I wrote something called maptemplate that gives me back some of what I miss. The technique may be useful in other scenarios" On Wed, Mar 11, 2015 at 3:36 AM, Peter West wrote: > Thanks Matt and Karsten. You've clarified the issues for me quite > nicely. IIUC, again, the clojurescript compilation process is taking place > exclusively in a clojure/jvm environment. If that is the case, macro > expansion must also, necessarily, occur in that clojure/jvm environment. > If that is the case, what difference does it make if defmacro appears in a > file with a .cljs extension? > > It seems to me that the difference is that it greatly complicates the > compiler. Just looking at function definitions, including executing code > within defmacros, there are three cases. 1) Pure agnostic clojure, 2) > functions with java interop, and 3) functions with js interop. (And, I > suppose, functions with both forms of interop, which can be rejected > immediately.) 2) is only valid during macro expansion, 3) is valid > wherever macro expansion is not being perfomed, and 1) is always valid. > The compiler could, I imagine, be obliged to sort that lot out, effectively > creating .clj files on the fly, and allowing all agnostic code to fall > thorough to code emission, where redundant, macro only, functions can be > dealt with by dead code elimination. However, as I said, that would > complicate the work of the compiler. > > Thanks again for the feedback on this. > > On Tuesday, 10 March 2015 06:13:02 UTC+10, Matt Greer wrote: > > How could macros written in ClojureScript execute if ClojureScript isn't > self hosted? There needs to be some kind of runtime to execute the macro, > and currently the only runtime available is the JVM. > > > > > > > > On Wed, Mar 4, 2015 at 9:03 PM, Peter West wrote: > > On Thursday, 5 March 2015 05:31:49 UTC+10, Stuart Sierra wrote: > > > > Thanks to all for the replies. > > > > > > > > Stuart, I wasn't thinking about self-hosting; merely about unifying the > experience under Clojure and ClojureScript, wrt macros. Some work has > already been done towards this, and I was wondering whether it were > feasible to integrate defmacro into the CLJS compiler. I thought there may > be subtleties around the fact that CLJS appears to be an essentially AoT > environment. > > > > > > > > In the event that there are no structural impediments, we might look > forward to such a full integration of defmacro some time down the track. I > think it would be a boon for the wider acceptance of CLJS. > > > > > > > > > > > > > On March 3, 2015, Peter West wrote: > > > > > > Macros eventually all expand to CLJS-compatible code. > > > > > > Currently, IIUC, both macro definition and expansion are > > > > > > handled by the Clojure compiler, with the resulting code > > > > > > (presumably CLJS compatible) being handed back to the > > > > > > ClojureScript compiler. Was this simply a convenience to > > > > > > get CLJS working with a minimum of fuss, or are there some > > > > > > structural impediments? > > > > > > > > > > > > > > > Mostly, I think, it was the quickest path to bootstrap the > > > > > ClojureScript compiler. Clojure already had a reader and > > > > > macro expander, so ClojureScript used them. > > > > > > > > > > In Rich Hickey's original design, ClojureScript was not > > > > > intended to be self-hosting without the JVM. The past few > > > > > years of work have brought ClojureScript closer to the > > > > > *possibility* of self-hosting, but it hasn't been a priority > > > > > for most of the major contributors. > > > > > > > > > > -S > > > > > > > > -- > > > > 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. > > > > > > > > > > > > -- > > > > > > Matt > > -- > 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 h
Re: [ClojureScript] Re: Macros and type hints
looks like magic to a beginner, trying to parse ` is quote while ~ is unquote but what is ' compared to ` also, does :tag in meta have a special meaning reserved for type hints? is there a good reference that explains how macros work in clojure? like why we need to quote and unquote (assuming that's not particular to macros but macros is only place i've seen it used)? On Tue, Mar 24, 2015 at 6:04 AM, Mike Thompson wrote: > On Tuesday, March 24, 2015 at 10:31:00 PM UTC+11, David Nolen wrote: > > On Tue, Mar 24, 2015 at 3:57 AM, Mike Thompson > wrote: > > > > > > The Google Closure compiler does deadcode eliminate the "x" if you do it > this way. And it avoids the complete nightmare of getting a type hint > added to js/goog.DEBUG through a macro (which seems impossible to me). > > > > > > I just tested the approach that I suggested and verified it works the > same as it does in Clojure. > > > > > > > > (defmacro when-debug [& body] > > `(when ~(vary-meta 'js/goog.DEBUG assoc :tag 'boolean) > > ~@body)) > > > Many Thanks! That works. Phew, thank goodness. > > I can now see that your original code had "assoc" "name" incorrectly > transposed and that, combined with my rookie macro-debugging-skills, meant > a lot of thrashing about, wild tangents and hair pulling. I can't wait to > get better at this stuff. > > -- > Mike > > -- > 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] Getting started with re-frame?
Jamie, That makes sense unless you build out your site based on micro services (which coordinate among themselves) and then have "micro apps" on the front end (each consisting of 1-4 pages and mapped to individual features of your app) that don't need to share state/data. In that case, you'd want to arrange under app name and each would have its own repo. But in that case, I think re-frame might be too much abstraction for the amount of code you're having to deal with (less than 400 lines per app) ... At some small scale the abstraction becomes noise. On Thu, Mar 26, 2015 at 8:00 AM, Jamie Orchard-Hays wrote: > Coming from the Rails world as I do, I'd invert that: > > handlers/page01.cljs > subscriptions/page01.cljs > views/page01.cljs > > etc. > > Jamie > > On Mar 26, 2015, at 3:32 AM, Colin Yates wrote: > > > How would you structure this for an SPA with multiple top-level > > 'pages'? I am thinking: > > > > - common (the usual bootstrapping crud) > > - page1/[handlers,subs,views etc.] > > - page2/[handlers,subs,views etc.] > > ... > > > > The central db would be in common/state.clj which each page, during > > 'bootstrap' would update with a default state and schema. > > > > Thoughts? > > > > > > > > > > > > On 26 March 2015 at 01:52, Mike Thompson > wrote: > >> On Thursday, March 26, 2015 at 1:07:56 AM UTC+11, Colin Yates wrote: > >>> Hi all, > >>> > >>> What is the recommended approach? Cloning the example project, the > re-frame-template (which is still using re-frame 0.1.8) or sticking it > together by hand? > >>> > >>> Thanks! > >> > >> > >> We do have the mandatory lein template in the wings. Will be released > very shortly, I hope. > >> > >> In the meantime, look at the structure of the todomvc example. > >> https://github.com/Day8/re-frame/tree/master/examples/todomvc > >> > >> > >> -- > >> Mike > >> > >> -- > >> 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. > > -- > 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] re-frame - sanity check for re-usable components
Khalid,
I read about that on some blog post (dumb and smart component) but I'm
afraid that dumb components in this case will be truly dumb and offer
little benefit for them to be shared (what is worth reusing/sharing is the
behavior, markup and styles, not the markup and styles alone)
To make sure I'm getting what you're proposing, are you saying dumb
components don't encapsulate behavior? I think the same question applies in
case of what Jane describes.
On Fri, Mar 27, 2015 at 6:58 AM, Khalid Jebbari
wrote:
> On Friday, March 27, 2015 at 2:39:37 PM UTC+1, Jamie Orchard-Hays wrote:
> > Does it make sense to pass the reusable component's context as an
> argument to it? ie,
> >
> > (defn ReusableComponent [some-context] )
> >
> > Jamie
> >
> > On Mar 27, 2015, at 8:54 AM, Colin Yates wrote:
> >
> > > In re-frame event dispatching is handled by (dispatch [:discriminator
> detail]). A corresponding (register-handler :discriminator (fn [db [_
> detail]]) then reacts to that dispatched event.
> > >
> > > My question is how are people managing this with re-usable components?
> For example, I have a tree and when selecting a node in that tree something
> should happen. But this is where it gets all polymorphic as _what_ happens
> depends on the client who instantiated the tree. I can see the following
> ways forward:
> > >
> > > - tree is configured with a 'context' key which is combined with the
> discriminator so rather than the tree emitting :node-selected it emits
> :consumer-a-node-selected. Consumer a can then handle
> consumer-a-node-selected and consumer b can handle (go on, guess)
> consumer-b-node-selected
> > > - a variation on the above involving writing your own dispatching
> logic...
> > > - tree doesn't use dispatch as the event bus, rather it takes in an
> instance of a Protocol:
> > > IRespondToTree
> > > (on-node-select [this node])
> > > - tree is parameterised with a map of fns {:node-selected-fn ...} etc.
> > >
> > > How would you all handle it? (I am leaning towards the first one).
> > >
> > > --
> > > 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.
>
> Not sure I'm going to answer the question directly, since I've never used
> re-frame, Reagent or Om. I'm just an experienced React.js developer VERY
> interested with Clojure(Script).
>
> If you want reusable components, whatever wrapper you use around React,
> here's the plan.
>
> You should create 2 types of components : dumb and smart. Dumb components
> do 2 simple things : display stuff and handle input/events. The way they
> handle should be agnostic to any kind of library and should use only
> language-level feature. Functions. So the dumb component use function it's
> been passed and call it with the input/event. The smart components wrap
> dumb components and connect to the outside world with whatever your stack
> uses (channels, events, ratoms, what not).
>
> This way your dumb components are always reusable, whatever stack/project
> they're incorporated in. They can also be displayed in a simple page for
> your graphics or HTML/CSS team to check their look. The smart components
> handle whatever logic you want to put in them. So from a stack/page/project
> to another, only the smart components change, no the dumb ones. This keep
> UI consistent and separate concerns.
>
> Hope it's clear and helpful.
>
> --
> 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] re-frame - sanity check for re-usable components
Yeah but then what are you really reusing? I have components that have
sophisticated behavior... sharing just the markup and styles is of limited
value since what I want to share in effect is the smart components, which
is why I had settled on components encapsulating behavior as a pattern...
works better for me to share the whole component (with its behavior) rather
than just the dumb part
On Fri, Mar 27, 2015 at 10:25 AM, Khalid Jebbari
wrote:
> Yes, dumb components don't encapsulate beahvior. Indeed if you generic
> behaviour you need as someone proposed to push a generic event, and the app
> handles it specifically.
>
> Khalid aka DjebbZ
> @Dj3bbZ
>
> On Fri, Mar 27, 2015 at 4:45 PM, Jamie Orchard-Hays
> wrote:
>
>> Good articles. Thanks, Mike. In my apps I think of them as "generic" and
>> "specific", or something like that. IOW, I want some generic views that are
>> dumb and know nothing about the app and can be used where ever I need them.
>> They get composed into specific views.
>>
>> Jamie
>>
>>
>> On Mar 27, 2015, at 10:12 AM, Mike Thompson
>> wrote:
>>
>> > On Saturday, March 28, 2015 at 12:58:17 AM UTC+11, Khalid Jebbari wrote:
>> >> On Friday, March 27, 2015 at 2:39:37 PM UTC+1, Jamie Orchard-Hays
>> wrote:
>> >>> Does it make sense to pass the reusable component's context as an
>> argument to it? ie,
>> >>>
>> >>> (defn ReusableComponent [some-context] )
>> >>>
>> >>> Jamie
>> >>>
>> >>> On Mar 27, 2015, at 8:54 AM, Colin Yates
>> wrote:
>> >>>
>> In re-frame event dispatching is handled by (dispatch
>> [:discriminator detail]). A corresponding (register-handler :discriminator
>> (fn [db [_ detail]]) then reacts to that dispatched event.
>>
>> My question is how are people managing this with re-usable
>> components? For example, I have a tree and when selecting a node in that
>> tree something should happen. But this is where it gets all polymorphic as
>> _what_ happens depends on the client who instantiated the tree. I can see
>> the following ways forward:
>>
>> - tree is configured with a 'context' key which is combined with the
>> discriminator so rather than the tree emitting :node-selected it emits
>> :consumer-a-node-selected. Consumer a can then handle
>> consumer-a-node-selected and consumer b can handle (go on, guess)
>> consumer-b-node-selected
>> - a variation on the above involving writing your own dispatching
>> logic...
>> - tree doesn't use dispatch as the event bus, rather it takes in an
>> instance of a Protocol:
>> IRespondToTree
>> (on-node-select [this node])
>> - tree is parameterised with a map of fns {:node-selected-fn ...}
>> etc.
>>
>> How would you all handle it? (I am leaning towards the first one).
>>
>> --
>> 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.
>> >>
>> >> Not sure I'm going to answer the question directly, since I've never
>> used re-frame, Reagent or Om. I'm just an experienced React.js developer
>> VERY interested with Clojure(Script).
>> >>
>> >> If you want reusable components, whatever wrapper you use around
>> React, here's the plan.
>> >>
>> >> You should create 2 types of components : dumb and smart. Dumb
>> components do 2 simple things : display stuff and handle input/events. The
>> way they handle should be agnostic to any kind of library and should use
>> only language-level feature. Functions. So the dumb component use function
>> it's been passed and call it with the input/event. The smart components
>> wrap dumb components and connect to the outside world with whatever your
>> stack uses (channels, events, ratoms, what not).
>> >>
>> >> This way your dumb components are always reusable, whatever
>> stack/project they're incorporated in. They can also be displayed in a
>> simple page for your graphics or HTML/CSS team to check their look. The
>> smart components handle whatever logic you want to put in them. So from a
>> stack/page/project to another, only the smart components change, no the
>> dumb ones. This keep UI consistent and separate concerns.
>> >>
>> >> Hope it's clear and helpful.
>> >
>> >
>> > I'm not sure how much this perspective applies to the Clojurescript
>> wrappings, but here are further references:
>> > https://medium.com/@learnreact/container-components-c0e67432e005
>> > https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
>> >
>> > --
>> > Mike
>> >
>> > --
>> > Note that posts from new members are moderated - please be patient with
>> your first post.
>> > ---
>
