[ClojureScript] Meetup in SF

2015-01-20 Thread marc fawzi

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

2015-01-21 Thread Marc Fawzi
<>

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

2015-01-21 Thread Marc Fawzi
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

2015-01-21 Thread Marc Fawzi
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

2015-01-22 Thread Marc Fawzi
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

2015-01-23 Thread Marc Fawzi
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!

2015-01-23 Thread Marc Fawzi
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!

2015-01-24 Thread Marc Fawzi
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

2015-01-24 Thread Marc Fawzi
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

2015-01-25 Thread Marc Fawzi
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

2015-01-25 Thread Marc Fawzi
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

2015-01-25 Thread Marc Fawzi
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

2015-01-25 Thread Marc Fawzi
<<
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

2015-01-26 Thread Marc Fawzi
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!)

2015-01-28 Thread Marc Fawzi
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

2015-01-28 Thread marc fawzi
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

2015-01-28 Thread Marc Fawzi
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

2015-01-29 Thread Marc Fawzi
>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

2015-01-30 Thread Marc Fawzi
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

2015-01-31 Thread Marc Fawzi
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

2015-01-31 Thread Marc Fawzi
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

2015-02-01 Thread Marc Fawzi
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

2015-02-01 Thread Marc Fawzi
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

2015-02-01 Thread Marc Fawzi
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

2015-02-01 Thread Marc Fawzi
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

2015-02-01 Thread Marc Fawzi
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

2015-02-01 Thread Marc Fawzi
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

2015-02-02 Thread Marc Fawzi
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

2015-02-02 Thread marc fawzi

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

2015-02-02 Thread Marc Fawzi
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)

2015-02-03 Thread Marc Fawzi
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)

2015-02-03 Thread Marc Fawzi
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)

2015-02-03 Thread Marc Fawzi
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)

2015-02-05 Thread Marc Fawzi
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

2015-02-06 Thread Marc Fawzi
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

2015-02-09 Thread Marc Fawzi
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

2015-02-09 Thread Marc Fawzi
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

2015-02-09 Thread Marc Fawzi
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

2015-02-09 Thread Marc Fawzi
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

2015-02-10 Thread Marc Fawzi
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

2015-02-10 Thread Marc Fawzi
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

2015-02-10 Thread Marc Fawzi
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.

2015-02-11 Thread Marc Fawzi
<<
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 ?

2015-02-11 Thread Marc Fawzi
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

2015-02-11 Thread Marc Fawzi
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

2015-02-11 Thread Marc Fawzi
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

2015-02-12 Thread Marc Fawzi
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

2015-02-12 Thread Marc Fawzi
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

2015-02-13 Thread Marc Fawzi
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

2015-02-13 Thread Marc Fawzi
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

2015-02-16 Thread Marc Fawzi
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?!

2015-02-16 Thread Marc Fawzi
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?!

2015-02-16 Thread Marc Fawzi
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

2015-02-17 Thread Marc Fawzi
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

2015-02-17 Thread Marc Fawzi
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

2015-02-20 Thread Marc Fawzi
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)

2015-02-25 Thread Marc Fawzi
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

2015-02-25 Thread Marc Fawzi
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

2015-02-26 Thread Marc Fawzi
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

2015-02-26 Thread Marc Fawzi
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

2015-02-27 Thread Marc Fawzi
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

2015-02-28 Thread Marc Fawzi
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?

2015-03-03 Thread Marc Fawzi
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?

2015-03-03 Thread Marc Fawzi
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?

2015-03-03 Thread Marc Fawzi
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

2015-03-04 Thread Marc Fawzi
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

2015-03-04 Thread Marc Fawzi
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

2015-03-04 Thread Marc Fawzi
<<
 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

2015-03-04 Thread Marc Fawzi
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

2015-03-04 Thread Marc Fawzi
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

2015-03-05 Thread Marc Fawzi
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!!)

2015-03-09 Thread Marc Fawzi
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!!)

2015-03-09 Thread Marc Fawzi
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!!)

2015-03-09 Thread Marc Fawzi
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!!)

2015-03-09 Thread Marc Fawzi
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!!)

2015-03-09 Thread Marc Fawzi
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!!)

2015-03-09 Thread Marc Fawzi
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!!)

2015-03-10 Thread Marc Fawzi
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

2015-03-10 Thread Marc Fawzi
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

2015-03-10 Thread Marc Fawzi
<<
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!!)

2015-03-12 Thread Marc Fawzi
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

2015-03-12 Thread Marc Fawzi
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

2015-03-13 Thread Marc Fawzi
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

2015-03-17 Thread Marc Fawzi
<<
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

2015-03-17 Thread Marc Fawzi
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?

2015-03-17 Thread Marc Fawzi

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?

2015-03-17 Thread Marc Fawzi
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

2015-03-17 Thread Marc Fawzi
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

2015-03-17 Thread Marc Fawzi
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

2015-03-19 Thread Marc Fawzi
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

2015-03-19 Thread Marc Fawzi
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

2015-03-19 Thread Marc Fawzi
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

2015-03-19 Thread Marc Fawzi
<<
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

2015-03-19 Thread Marc Fawzi
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

2015-03-19 Thread Marc Fawzi
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?

2015-03-23 Thread Marc Fawzi
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

2015-03-24 Thread Marc Fawzi
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?

2015-03-26 Thread Marc Fawzi
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

2015-03-27 Thread Marc Fawzi
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

2015-03-27 Thread Marc Fawzi
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.
>> > ---
>

  1   2   3   >