Re: [ClojureScript] Re: How does Clojurescript compilation scales with CPU?
I may do some testing in the a close future and report here. I will either do it in our project or in a an open-source project that's "relevant" to show real-world numbers. Do you have an idea of such project? I think I will try to bench compilation time in advanced mode with a different number of cores activated by BIOS (I will soon have a 16C/32T machine, I hope the BIOS will allow me to deactivate some of them). Khalid aka DjebbZ @Dj3bbZ On Fri, Jan 17, 2020 at 11:58 AM Thomas Heller wrote: > Depends on the size I'd say but in theory yes. Lots of things factor into > the compilation times, even tiny namespaces can take a long time to compile > if some macro just takes a long time to do its thing. > > On Friday, January 17, 2020 at 11:18:21 AM UTC+1, Khalid Jebbari wrote: >> >> Thanks for the detailed answer. Does it somewhat mean that splitting code >> into smaller namespaces can achieve faster compilation thanks to >> parallelization ? >> >> >> On Fri, Jan 17, 2020 at 10:43 AM Thomas Heller wrote: >> >>> It depends on the namespaces used. In general a CLJS namespaces can only >>> be compiled once all its dependencies have been compiled. So if those >>> dependendencies can be compiled in parallel they will use multiple threads >>> from a pool, which should keep all cores busy. In my experience a good >>> balance between core count and core speed matters. If you have big >>> namespaces that a lot of other namespaces depend on (eg. like cljs.core) >>> then its compilation will "block" all other threads so its important it >>> finishes fast (ie. fast cores). If you have lots a small namespaces that >>> are mostly independent then you can get maximum parallelization (ie. many >>> cores). >>> >>> I have a i7-8700K 6c and there are builds that aren't able to use all >>> cores due to the namespace setup (few very large ones). Others happily use >>> everything. Single core difference is gigantic to my previous CPU from a >>> macbook pro 2016. >>> >>> If you really really want to torture your CPU you can try >>> https://github.com/mfikes/fifth-postulate or >>> https://github.com/mfikes/coal-mine to compare. >>> >>> HTH, >>> Thomas >>> >>> On Friday, January 17, 2020 at 5:29:06 AM UTC+1, Khalid Jebbari wrote: >>>> >>>> Hello, >>>> >>>> We're using the parallel build option, and I noticed the difference in >>>> speed between my laptop and other laptops is basically proportional to the >>>> difference in speed of the CPUs (based on notebookcheck's benchmarks). I >>>> have 4C/8T 7700HQ CPU and my colleagues have a 8565U iirc (some have the >>>> 6600U). Mine is almost twice as fast in benchmarks, which is reflected in >>>> cljs compilation times. >>>> >>>> So my question is how does the cljs compiler scale with regards to CPU? >>>> Core count? Single thread perf? All cores frequencies? Is it capped to some >>>> number of cores? >>>> >>>> -- >>> 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/PwpVJNrF0Zc/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> clojur...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com >>> <https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >> -- > 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/PwpVJNrF0Zc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojurescript+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojurescript/fe80b84a-4c23-4789-9b27-8f84c631d93d%40googlegroups.com > <https://groups.google.com/d/msgid/clojurescript/fe80b84a-4c23-4789-9b27-8f84c631d93d%40googlegroups.com?utm_medium=email_source=footer> > . > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojurescript/CAM3R3BCE7cL9cBrPAVMKnzd6SZ65p3XeXbMM0wFMhs%2BjvqxN1A%40mail.gmail.com.
Re: [ClojureScript] Re: How does Clojurescript compilation scales with CPU?
Thanks for the detailed answer. Does it somewhat mean that splitting code into smaller namespaces can achieve faster compilation thanks to parallelization ? On Fri, Jan 17, 2020 at 10:43 AM Thomas Heller wrote: > It depends on the namespaces used. In general a CLJS namespaces can only > be compiled once all its dependencies have been compiled. So if those > dependendencies can be compiled in parallel they will use multiple threads > from a pool, which should keep all cores busy. In my experience a good > balance between core count and core speed matters. If you have big > namespaces that a lot of other namespaces depend on (eg. like cljs.core) > then its compilation will "block" all other threads so its important it > finishes fast (ie. fast cores). If you have lots a small namespaces that > are mostly independent then you can get maximum parallelization (ie. many > cores). > > I have a i7-8700K 6c and there are builds that aren't able to use all > cores due to the namespace setup (few very large ones). Others happily use > everything. Single core difference is gigantic to my previous CPU from a > macbook pro 2016. > > If you really really want to torture your CPU you can try > https://github.com/mfikes/fifth-postulate or > https://github.com/mfikes/coal-mine to compare. > > HTH, > Thomas > > On Friday, January 17, 2020 at 5:29:06 AM UTC+1, Khalid Jebbari wrote: >> >> Hello, >> >> We're using the parallel build option, and I noticed the difference in >> speed between my laptop and other laptops is basically proportional to the >> difference in speed of the CPUs (based on notebookcheck's benchmarks). I >> have 4C/8T 7700HQ CPU and my colleagues have a 8565U iirc (some have the >> 6600U). Mine is almost twice as fast in benchmarks, which is reflected in >> cljs compilation times. >> >> So my question is how does the cljs compiler scale with regards to CPU? >> Core count? Single thread perf? All cores frequencies? Is it capped to some >> number of cores? >> >> -- > 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/PwpVJNrF0Zc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojurescript+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com > <https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com?utm_medium=email_source=footer> > . > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojurescript/CAM3R3BARm8m08%3DA1aSN%2B3rW9E0DUNGyuzyWgGTmf5fscGnFjpA%40mail.gmail.com.
[ClojureScript] How does Clojurescript compilation scales with CPU?
Hello, We're using the parallel build option, and I noticed the difference in speed between my laptop and other laptops is basically proportional to the difference in speed of the CPUs (based on notebookcheck's benchmarks). I have 4C/8T 7700HQ CPU and my colleagues have a 8565U iirc (some have the 6600U). Mine is almost twice as fast in benchmarks, which is reflected in cljs compilation times. So my question is how does the cljs compiler scale with regards to CPU? Core count? Single thread perf? All cores frequencies? Is it capped to some number of cores? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojurescript/6d24e681-188b-44c8-905c-afd545794e3a%40googlegroups.com.
Re: [ClojureScript] Re: Question about code-splitting and loading of dependent modules.
Indeed, I had forgotten to call set-loaded! for the components splits. I
feel stupid... Thanks for the help !
On Mon, Feb 4, 2019, 2:17 PM Thomas Heller To me that still sounds like you are missing a (cljs.loader/set-loaded!
> :components1) call in my-app.components.common.components1. Each module
> must call set-loaded! at some point. In shadow-cljs this is taken care of
> automatically but CLJS otherwise requires that you do this manually. If you
> have the set-loaded! calls in the proper places and it should work. If it
> doesn't I'd recommend creating a fully reproducible example and report it.
>
>
> On Monday, February 4, 2019 at 12:01:23 PM UTC+1, Khalid Jebbari wrote:
>>
>> I realize it's much better if I give the complete configuration.
>>
>> latest ClojureScript stable 1.10.516
>> deps.edn alias: {:cljs {:main-opts ["-m" "cljs.main" "-co" "cljs-dev.edn"
>> "--compile"]}}
>> cljs-dev.edn file:
>>
>> {:main "my-app.core"
>> :parallel-build true
>> :optimizations :simple
>> :output-dir "target/js"
>> :modules{:cljs-base {:output-to "target/js/main.js"
>> :source-map true}
>> :page1 {:entries#{"my-app.layout.page1"}
>> :output-to "target/js/page1.js"
>> :source-map true}
>> :page2 {:entries#{"my-app.layout.page2"}
>> :output-to "target/js/page2.js"
>> :source-map true}
>> :page3 {:entries#{"my-app.layout.page3"}
>> :output-to "target/js/page3.js"
>> :depends-on #{:components1}
>> :source-map true}
>> :page4 {:entries#{"my-app.layout.page4"}
>> :output-to "target/js/page4.js"
>> :depends-on #{:components1 :components2}
>> :source-map true}
>> :page5 {:entries#{"my-app.layout.page5"}
>> :output-to "target/js/page5.js"
>> :depends-on #{:components1 :components2}
>> :source-map true}
>> :components1 {:entries
>> #{"my-app.components.common.components1"}
>> :output-to "target/js/components1.js"
>> :source-map true}
>> :components2 {:entries
>> #{"my-app.components.common.components2"}
>> :output-to "target/js/components2.js"}}
>> }
>>
>> So my point here is to remove code from cljs-base that is common to some
>> pages but not all of them and putting them into the split :components1 and
>> :components2. The compilation works, the split are good (I verified the
>> javascript produced for every file) but the runtime behavior is incorrect.
>> My problem is that when I load :page3 with (loader/load :page3
>> my-callback), I see a requests to components1.js with response 200 OK, but
>> no request to page3.js after, and my-callback is not executed.
>>
>> On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote:
>>>
>>> Hello,
>>>
>>> I create 3 modules in the :modules configuration, say :cljs-base, :a &
>>> :b, and know that module :a depends on code in the module :b (and in
>>> :cljs-base of course). If I manually load only :a with `(cljs.loader/load
>>> :a)`, will it automatically load :b? My local testing seems to show that it
>>> doesn't.
>>>
>>> --
> 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/NwRtAgr9ltc/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 https://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 https://groups.google.com/group/clojurescript.
[ClojureScript] Re: Question about code-splitting and loading of dependent modules.
I realize it's much better if I give the complete configuration.
latest ClojureScript stable 1.10.516
deps.edn alias: {:cljs {:main-opts ["-m" "cljs.main" "-co" "cljs-dev.edn"
"--compile"]}}
cljs-dev.edn file:
{:main "my-app.core"
:parallel-build true
:optimizations :simple
:output-dir "target/js"
:modules{:cljs-base {:output-to "target/js/main.js"
:source-map true}
:page1 {:entries#{"my-app.layout.page1"}
:output-to "target/js/page1.js"
:source-map true}
:page2 {:entries#{"my-app.layout.page2"}
:output-to "target/js/page2.js"
:source-map true}
:page3 {:entries#{"my-app.layout.page3"}
:output-to "target/js/page3.js"
:depends-on #{:components1}
:source-map true}
:page4 {:entries#{"my-app.layout.page4"}
:output-to "target/js/page4.js"
:depends-on #{:components1 :components2}
:source-map true}
:page5 {:entries#{"my-app.layout.page5"}
:output-to "target/js/page5.js"
:depends-on #{:components1 :components2}
:source-map true}
:components1 {:entries
#{"my-app.components.common.components1"}
:output-to "target/js/components1.js"
:source-map true}
:components2 {:entries
#{"my-app.components.common.components2"}
:output-to "target/js/components2.js"}}
}
So my point here is to remove code from cljs-base that is common to some
pages but not all of them and putting them into the split :components1 and
:components2. The compilation works, the split are good (I verified the
javascript produced for every file) but the runtime behavior is incorrect.
My problem is that when I load :page3 with (loader/load :page3
my-callback), I see a requests to components1.js with response 200 OK, but
no request to page3.js after, and my-callback is not executed.
On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote:
>
> Hello,
>
> I create 3 modules in the :modules configuration, say :cljs-base, :a & :b,
> and know that module :a depends on code in the module :b (and in :cljs-base
> of course). If I manually load only :a with `(cljs.loader/load :a)`, will
> it automatically load :b? My local testing seems to show that it doesn't.
>
>
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Question about code-splitting and loading of dependent modules.
I did this already in all modules. I noticed I had to add to the :main namespace (loader/set-loaded! :cljs-base) On Sat, Feb 2, 2019, 10:49 AM Thomas Heller In standard CLJS you must add a manual call to let the runtime know that > your module finished loading. > > (cljs.loader/set-loaded! :a) > > Somewhere near the "end" of your modules. Only with this call will the > runtime continue loading the code. > > https://clojurescript.org/guides/code-splitting > > > -- > 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/NwRtAgr9ltc/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 https://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 https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Question about code-splitting and loading of dependent modules.
Yes I did. Calling load :a loads :b in XHR then nothing, doesn't load :a
afterwards.
On Fri, Feb 1, 2019, 10:44 PM Thomas Heller You didn't show your config but did you correctly configure that :a
> depends on :b? eg. :depends-on #{:b}? That can't be inferred so you must
> manually configure it.
>
> On Friday, February 1, 2019 at 1:11:20 PM UTC+1, Khalid Jebbari wrote:
>>
>> In case it wasn't clear, the javascript file for :cljs-base is included
>> as a script tag in the html, and it loads :a.
>>
>> On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote:
>>>
>>> Hello,
>>>
>>> I create 3 modules in the :modules configuration, say :cljs-base, :a &
>>> :b, and know that module :a depends on code in the module :b (and in
>>> :cljs-base of course). If I manually load only :a with `(cljs.loader/load
>>> :a)`, will it automatically load :b? My local testing seems to show that it
>>> doesn't.
>>>
>>> --
> 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/NwRtAgr9ltc/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 https://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 https://groups.google.com/group/clojurescript.
[ClojureScript] Re: Question about code-splitting and loading of dependent modules.
In case it wasn't clear, the javascript file for :cljs-base is included as a script tag in the html, and it loads :a. On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote: > > Hello, > > I create 3 modules in the :modules configuration, say :cljs-base, :a & :b, > and know that module :a depends on code in the module :b (and in :cljs-base > of course). If I manually load only :a with `(cljs.loader/load :a)`, will > it automatically load :b? My local testing seems to show that it doesn't. > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Question about code-splitting and loading of dependent modules.
Hello, I create 3 modules in the :modules configuration, say :cljs-base, :a & :b, and know that module :a depends on code in the module :b (and in :cljs-base of course). If I manually load only :a with `(cljs.loader/load :a)`, will it automatically load :b? My local testing seems to show that it doesn't. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: ClojureScript 1.10.516
I get it. Maybe in the future the type inference could inform the Closure Compiler of the types, so that it could emit smaller code ? Really curious about it. On Friday, February 1, 2019 at 11:06:49 AM UTC+1, Thomas Heller wrote: > > > > On Friday, February 1, 2019 at 5:54:13 AM UTC+1, Khalid Jebbari wrote: >> >> Can it make bundles smaller ? >> > > Yes in theory, but only by a very small fraction. The cljs.core/str macro > may emit less code in certain situations for example but after :advanced > optimizations the difference will be very small. So I wouldn't expect any > substantial reductions overall, it is mostly about the compile time > warnings. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] ANN: ClojureScript 1.10.516
Congrats David and all contributors! Not a feedback but a question: does the new type inference have an influence on the generated JS code ? Can it make bundles smaller ? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: ClojureScript 1.10.439
Reporting build-times changes, in a ~15loc CLJ/CLJS/CLC project, on a 8-cores CPU machine, with :parallel-build always true and timings as reported by :compiler-stats true, using boot-cljs. I've run each build at least twice to check for variations. With CLJS 1.10.339 - :optimizations :none Compile sources, elapsed time: 11628.251228 msecs Compile sources, elapsed time: 1865.551867 msecs => Total: ~13.5 secs (13493.803095 msecs) - :optimizations :advanced Compile sources, elapsed time: 13882.684487 msecs Compile sources, elapsed time: 22.481435 msecs Optimizing with Google Closure Compiler, elapsed time: 15468.294224 msecs Optimizing 265 sources, elapsed time: 15892.028818 msecs => Total: ~45 secs (45265.488964 msecs) With CLJS 1.10.439 - :optimizations :none Compile sources, elapsed time: 11551.295873 msecs Compile sources, elapsed time: 1337.826701 msecs => Total: ~12.8 secs (12889.12257399 msecs) - :optimizations :advanced Compile sources, elapsed time: 12874.073566 msecs Compile sources, elapsed time: 23.319803 msecs Optimizing with Google Closure Compiler, elapsed time: 16746.485323 msecs Optimizing 265 sources, elapsed time: 17214.70572 msecs => Total: ~46.8 secs (46858.584412 msecs) No significant changes in compilation times, but it may be due to boot/boot-cljs overhead, no idea. This is completely unscientific, as it may not make use of the some things enabled only when using cljs.main. I've also received a warning for a :private-var-access in one of my dependencies, will open an issue there. End of report. And big thanks to all contributors! On Monday, November 5, 2018 at 7:34:18 PM UTC+1, David Nolen wrote: > > ClojureScript, the Clojure compiler that emits JavaScript source code. > > README and source code: https://github.com/clojure/clojurescript > > Leiningen dependency information: > > [org.clojure/clojurescript "1.10.439"] > > Please refer the announce post for the details: > https://clojurescript.org/news/2018-11-02-release > > As always, feedback welcome! > > ## 1.10.439 > > ### Changes > * CLJS-2904: Default :npm-deps to false > * CLJS-2878: Update Closure Compiler to v20180805 > * CLJS-2827: Avoid var special in core macros for private var access > * CLJS-2819: Warn on non-dynamic earmuffed vars > * CLJS-2806: Bump test.check to 0.10.0-alpha3 > * CLJS-2815: Support string keys in :global-exports > * CLJS-2812: Support for overriding object printing > * CLJS-2805: Bump tools.reader to 1.3.0 > * CLJS-1702: Warning when using private vars > * Align ClojureScript AST to tools.analyzer > > ### Enhancements > * CLJS-2903: Support fingerprinting > * CLJS-2897: cljs.main: Display initial REPL prompt sooner > * CLJS-2884: Support for GraalJS RC6 > * CLJS-2859: Graal.JS: Enable high-res timers by default, allow > user-configuration > * CLJS-2831: Add a graaljs REPL environment > * CLJS-1997: Outward function type hint propagation > * CLJS-844: Optimize js->clj by switching to transients > * CLJS-2442: `set` and `vec` performance enhancements > > ### Fixes > * CLJS-2953: stest/with-instrument-disabled prints warning of private use > * CLJS-2728: Ability to disable macro spec checks > * CLJS-2843: s/explain of evaluated predicate yields :s/unknown > * CLJS-2951: Add a spec generator for some? > * CLJS-2940: Can't define nilable spec on undefined pred > * CLJS-2948: Stack overflow calling instrumented variadic fn with zero args > * CLJS-2793: Instrumenting breaks function with varargs > * CLJS-2934: Enhanced delay printing > * CLJS-2864: Optimize str macro for single arity case > * CLJS-1297: defrecord does not emit IKVReduce protocol > * CLJS-2937: docstring for to-array > * CLJS-2943: Update merge-with to use key / val > * CLJS-2941: seqable? should return true for nil > * CLJS-2915: Tests fail if directory has a period (.) in the path > * CLJS-2782: lein test fails if directory has hyphens > * CLJS-2911: Avoid infinite loop on infinite partitions > * CLJS-2906: cljs.main: Crash when with default REPL > * CLJS-2883: Instrumentation fails compilation with a large number of > spec'd functions > * CLJS-2896: Allow parallel analysis and compilation > * CLJS-2893: seq: use .-length instead of alength for strings > * CLJS-2890: fspec role in problem path is not useful > * CLJS-2887: Improve names in core macro specs > * CLJS-2891: stop including data in ex-info message > * CLJS-2888: Printing of spec problems buries the failing predicate which > should be more prominent > * CLJS-2861: Self-host: :checked-arrays not working > * CLJS-2852: Clojure imparity: ns-publics returns different arglists for > macros > * CLJS-2725: Doc on spec keywords > * CLJS-2665: Port clojure.spec.test.alpha/enumerate-namespace > * CLJS-2848: Default explain printer prints root val and spec > * CLJS-2846: [spec] s/tuple explain-data :pred problem > * CLJS-2847: s/coll-of and s/every gen is very slow if :kind specified > without :into > * CLJS-2841: [spec] instrument exception doesn't contain function name
Re: [ClojureScript] Re: Creating a map entry
Ooops, silly me... Thanks for catch.
On Thu, Oct 18, 2018, 4:55 PM Alex Miller wrote:
>
>
> On Thursday, October 18, 2018 at 4:07:32 AM UTC-5, Khalid Jebbari wrote:
>>
>>
>> PS: I couldn't get clojure cli to download criterium to run the
>> benchmark, so I ended up using the REPL provided by in my current app setup
>> (based on Clojure 1.9.0, Boot 2.8.2 and criterium 0.4.4, the latest stable
>> versions).
>> Here's the command I ran and the error:
>>
>> ```
>> > clj -Sdeps "{:deps {org.clojure/clojure {:mvn/version \"1.9.0\"}
>> criterum {:mvn/version \"0.4.4\"}}}"
>> Error building classpath. Could not find artifact
>> criterum:criterum:jar:0.4.4 in central (https://repo1.maven.org/maven2/)
>>
>
> You misspelled "criterium" in your deps.
>
> --
> 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/doSapNEhLjc/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 https://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 https://groups.google.com/group/clojurescript.
[ClojureScript] Code-splitting and closure libs problem ?
Hello,
I have a problem with one of the CLJS split module I lazy load. This CLJS
split depends on a manually written Closure library in Javascript, itself
depending on another manually written Closure lib. When the split loads and
is executed, it successfully loads its Closure dependency but this Closure
lib fails to load its own Closure dep. I can verify it in the browser
console, the transitive deep Closure lib namespace doesn't exist.
The goal is to lazy load external trackers (à la Google Analytics) only
when necessary, so I wrap the small JS code they require in a CLJS
namespace that I can lazy-load with cljs.loader. As a note, another reason
we wrap Closure tracker libs in CLJS ns is we also use them in non CLJS
projects so we can't directly `goog.require` cljs.loader in them.
Details:
Env:
Clojure 1.9.0
Clojurescript 1.9.946
Linux
openjdk version "1.8.0_162"
Boot 2.7.1 and boot-cljs 2.1.4
CLJS compiler options:
Boot-cljs main.cljs.edn
{:require [yoda.core]
:init-fns [yoda.core/init]
:compiler-options {:libs ["trackers/dataLayer.js"
"trackers/google_analytics.js" ;; depends
on trackers/dataLayer.js
"trackers/other_tracker.js"]
:output-dir "js"
:modules{:cljs-base{:output-to "js/main.js"}
:google-analytics {:entries
#{yoda.tracking.google-analytics-wrapper} ;; depends on
trackers/google_analytics.js
:output-to
"js/main.out/google_analytics_wrapper.js"}
:other-tracker{:entries
#{yoda.tracking.other-tracker-wrapper} ;; depends on
trackers/other_tracker.js
:output-to
"js/main.out/other_tracker_wrapper.js"
Other CLJS compiler options in build.boot:
(task-options! cljs {:compiler-options {:asset-path "/yd/js"
:optimizations :none
:source-map true
:parallel-build true
:verbose true}})
Code-loading in my-project.tracking namespace:
;; start external trackers
(loader/load :google-analytics
(fn []
((resolve
'my-project.tracking.google-analytics-wrapper/start) ga-tracking-id)))
(loader/load :other-tracker
(fn []
((resolve
'my-project.tracking.other-tracker-wrapper/start
The generated cljs_deps.js looks ok:
goog.addDependency("../trackers/dataLayer.js", ['trackers.dataLayer'],
['goog.array']);
goog.addDependency("../trackers/google_analytics.js",
['trackers.google_analytics'], ['trackers.dataLayer', 'goog.net.Cookies']);
goog.addDependency("../my_project/tracking/google_analytics_wrapper.js",
['my_project.tracking.google_analytics_wrapper'], ['cljs.loader',
'trackers.google_analytics', 'cljs.core']);
goog.addDependency("../trackers/other_tracker.js",
['trackers.other_tracker'], []);
goog.addDependency("../yoda/tracking/other_tracker_wrapper.js",
['yoda.tracking.other_tracker_wrapper'], ['trackers.other_tracker',
'cljs.loader', 'cljs.core']);
Problems:
1. The browser requests source-maps for all the Closure libs in trackers/
which is weird because the compilation doesn't change them. They're kept as
is. No need to use source-maps for plain JS code right ?
2. The browser requests source-maps at the wrong URI for split modules: it
tries to load them from the root path / directly. Here's the error in the
browser
Source map error: TypeError: NetworkError when attempting to fetch resource.
Resource URL: null
Source Map URL: google_analytics_wrapper.js.map ;; it should be
/yd/js/my_project/tracking/google_analytics_wrapper.js.map where it does
exist (verified on disk)
3. Printing the `trackers` global JS variable in the browser (for the
"trackers" part of the trackers.XXX namespaces) shows that it doesn't
contains the dataLayer namespace, the transitive Closure lib.
4. Code splitting works fine for the `other_tracker` split, I can verify
its code is executed. Hence problem #3 seems to come from the transitive
dependency.
I hope I was clear in explaining the problem. Happy to help you help me by
answering any question.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Code-splitting question
Is it true to say that the dependency on :cljs-base is handled by the compiler ? It seems so when I look at the code generated in :none mode. I'd love to understand why it's not possible between modules. Le 24 févr. 2018 21:09, "David Nolen" <dnolen.li...@gmail.com> a écrit : > You must specify :depends-on - the compiler will not do this for you. > > David > > On Fri, Feb 23, 2018 at 1:06 PM, Khalid Jebbari <khalid.jebb...@gmail.com> > wrote: > >> Hello, >> >> Say I have 2 namespaces in CLJS/CLJC, A and B. A requires B explicitly. >> >> I want to produce a js file for each namespace, A.js and B.js. So I use >> the code-splitting feature, and create a dedicated module entry for each >> namespace, :A and :B. >> >> What's exactly the difference between specifying that module :A >> ":depends-on" :B and not specifying it ? Surely the compiler can understand >> the dependence by just analyzing the requires in code. >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojurescript+unsubscr...@googlegroups.com. >> To post to this group, send email to clojurescript@googlegroups.com. >> Visit this group at https://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/0s2xiicjm8U/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 https://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 https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Code-splitting question
Thanks for the pointer. I've read the thread twice though and don't fully understand your answer. I'll try to play with :depends-on in our project next week and analyse the output. But detailed explanation is still welcome. Le 24 févr. 2018 10:51, "Thomas Heller" <th.hel...@gmail.com> a écrit : > I answered a similar question a while ago: > https://groups.google.com/d/msg/clojurescript/Gk1XA0aIxJM/Ixu45z-wkEoJ > > > On Friday, February 23, 2018 at 7:06:43 PM UTC+1, Khalid Jebbari wrote: >> >> Hello, >> >> Say I have 2 namespaces in CLJS/CLJC, A and B. A requires B explicitly. >> >> I want to produce a js file for each namespace, A.js and B.js. So I use >> the code-splitting feature, and create a dedicated module entry for each >> namespace, :A and :B. >> >> What's exactly the difference between specifying that module :A >> ":depends-on" :B and not specifying it ? Surely the compiler can understand >> the dependence by just analyzing the requires in code. >> >> -- > 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/0s2xiicjm8U/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 https://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 https://groups.google.com/group/clojurescript.
[ClojureScript] Code-splitting question
Hello, Say I have 2 namespaces in CLJS/CLJC, A and B. A requires B explicitly. I want to produce a js file for each namespace, A.js and B.js. So I use the code-splitting feature, and create a dedicated module entry for each namespace, :A and :B. What's exactly the difference between specifying that module :A ":depends-on" :B and not specifying it ? Surely the compiler can understand the dependence by just analyzing the requires in code. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Problems with code-splitting
Bug filed: https://github.com/boot-clj/boot-cljs/issues/183 On Monday, February 5, 2018 at 5:22:58 PM UTC+1, Khalid Jebbari wrote: > > I managed to create a minimal reproduction repository. It’s definitely a > problem of Boot-cljs, not of the CLJS compiler itself. > > The repo (with problem statement and instructions): > https://github.com/DjebbZ/code-splitting-bug-boot-cljs > > Will post on boot-cljs issue too, it may help them spot the problem. > > On Saturday, February 3, 2018 at 2:37:18 PM UTC+1, Khalid Jebbari wrote: >> >> No I'm really lazy loading from another namespace, our `yoda.tracking` >> where all happens. This ns doesn't `require` at all the lazy loaded module, >> it just `resolve` it. I will work on a minimal repro case based on >> boot-cljs next week. >> >> Thanks for your attention. >> > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Problems with code-splitting
I managed to create a minimal reproduction repository. It’s definitely a problem of Boot-cljs, not of the CLJS compiler itself. The repo (with problem statement and instructions): https://github.com/DjebbZ/code-splitting-bug-boot-cljs Will post on boot-cljs issue too, it may help them spot the problem. On Saturday, February 3, 2018 at 2:37:18 PM UTC+1, Khalid Jebbari wrote: > > No I'm really lazy loading from another namespace, our `yoda.tracking` > where all happens. This ns doesn't `require` at all the lazy loaded module, > it just `resolve` it. I will work on a minimal repro case based on > boot-cljs next week. > > Thanks for your attention. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Problems with code-splitting
No I'm really lazy loading from another namespace, our `yoda.tracking` where all happens. This ns doesn't `require` at all the lazy loaded module, it just `resolve` it. I will work on a minimal repro case based on boot-cljs next week. Thanks for your attention. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Problems with code-splitting
Hello,
I'm trying to package all our trackers code (think Google analytics and the
likes) into different splits so that they don't make base JS package too
big and don't slow down time to interactive. Good idea, right ?
Our strategy is basically to write the trackers code in Javascript first
with Google Closure compiler in mind (goog.provide(), goog.require() etc.)
and add those libs to our CLJS project and also package it as a standalone
Javascript file for others non-CLJS project. So far it works really well,
until now that I'm trying to code-split them.
My first experiment fails because the code of the split ends up in the base
package instead, even though the split file is created. But this split file
is empty. Here's the configuration:
Linux
Boot 2.7.1 with boot-cljs 2.1.4
Clojure 1.9
ClojureScript 1.9.946
Java 8 (openjdk version "1.8.0_144")
CLJS compiler options:
```
{:main "yoda.core"
:libs ["trackers/google_analytics.js" ] ;; lot of trackers
here...
:modules{:google-analytics {:entries
'#{yoda.tracking.google-analytics} ;; cljs namespace that wraps the call to
JS tracker, to be able to call `(loader/set-loaded! :google-analytics)`
:output-to "js/google-analytics.js"}}
:asset-path "/yd/js/main.out"
:optimizations :simple
:source-map true
:parallel-build true
:verbosetrue}
```
I use the modules like this in the CLJS code:
```
;; CLJS wrapper namespace
(ns yoda.tracking.google-analytics
(:require [cljs.loader :as loader]
[trackers.google-analytics :as ga]))
(defn start [ga-tracking-id entity]
(ga/start ga-tracking-id entity))
(loader/set-loaded! :google-analytics)
;; Code that lazy-loads it somewhere else
(loader/load :google-analytics
(fn []
((resolve 'yoda.tracking.google-analytics/start)
ga-tracking-id entity)))
```
It seems to work when I look at the browser console:
log:Module loaded: cljs_base
log:Module loaded: google_analytics
But when I examine the cljs_base.js and google_analytics.js files, the
problem appears: cljs_base.js contains the code of my CLJS wrapper
namespace, and google_analytics.js is empty (apart from the comment for
source-map).
With the `:verbose true` option it looks like the CLJS compiler does the
work properly:
Building module :google-analytics
# ... several entries ...
adding entry [trackers.google-analytics] # the JS code
adding entry (yoda.tracking.google-analytics) # our CLJS wrapper namespace
module :google-analytics depends on :cljs-base
Furthermore I expected the google_analytics.js to be loaded with a network
request, but there's only the request to load cljs_base.js.
Is it because of cross module code motion ? It seems that the code of the
CLJS tracker is moved to the main module, but I don't understand why.
Thanks in advance for your help.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Problems with code splitting
Hello,
I'm trying to package all our trackers code (think Google analytics and the
likes) into different splits so that they don't make base JS package too
big and don't slow down time to interactive. Good idea, right ?
Our strategy is basically to write the trackers code in Javascript first
with Google Closure compiler in mind (goog.provide(), goog.require() etc.)
and add those libs to our CLJS project and also package it as a standalone
Javascript file for others non-CLJS project. So far it works really well,
until now that I'm trying to code-split them.
My first experiment fails because the code of the split ends up in the base
package instead, even though the split file is created. But this split file
is empty. Here's the configuration:
Linux
Boot 2.7.1 with boot-cljs 2.1.4
Clojure 1.9
ClojureScript 1.9.946
Java 8 (openjdk version "1.8.0_144")
CLJS compiler options:
```
{:main "yoda.core"
:libs ["trackers/google_analytics.js" ] ;; lot of trackers
here...
:modules{:google-analytics {:entries
'#{yoda.tracking.google-analytics} ;; cljs namespace that wraps the call to
JS tracker, to be able to call `(loader/set-loaded! :google-analytics)`
:output-to "js/google-analytics.js"}}
:asset-path "/yd/js/main.out"
:optimizations :simple
:source-map true
:parallel-build true
:verbosetrue}
```
I use the modules like this in the CLJS code:
```
;; CLJS wrapper namespace
(ns yoda.tracking.google-analytics
(:require [cljs.loader :as loader]
[trackers.google-analytics :as ga]))
(defn start [ga-tracking-id entity]
(ga/start ga-tracking-id entity))
(loader/set-loaded! :google-analytics)
;; Code that lazy-loads it somewhere else
(loader/load :google-analytics
(fn []
((resolve 'yoda.tracking.google-analytics/start)
ga-tracking-id entity)))
```
It seems to work when I look at the browser console:
log:Module loaded: cljs_base
log:Module loaded: google_analytics
But when I examine the cljs_base.js and google_analytics.js files, the
problem appears: cljs_base contains the code of my CLJS wrapper namespace,
and google_analytics.js is empty (apart from the comment for source-map).
With the `:verbose true` option it looks like the CLJS compiler does the
work properly:
Building module :google-analytics
# ... several entries ...
adding entry [trackers.google-analytics] # the JS code
adding entry (yoda.tracking.google-analytics) # our CLJS wrapper namespace
module :google-analytics depends on :cljs-base
Furthermore I expected the google_analytics.js to be loaded with a network
request, but there's only the request to load cljs_base.js.
Is it because of cross module code motion ? It seems that the code of the
CLJS tracker is moved to the main module, but I don't understand why.
Thanks in advance for your help.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Scripting with Clojure(Script) : Plain Clojure ? Node.js ? Boot ? Planck ? Pixie ?
Hi every one, Just starting this thread to gather feedback from people who used CLJ(S) to script and replace, you know, shell/Python/Ruby/Whatever. Pretty sure it's a dream to code AND script with CLJ(S). I know that it's possible to do it with CLJS backed by Node.js/io.js, with Boot somehow, with plain Clojure, with Mike Fikes' Planck (only OSX for now though), and Timothy Baldridge's Pixie which is not Clojure but quite close. If you use any or several, please post your feeback here. It's a nice time to CLJ(S) all the things :) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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] HTML DOM to Edn
I know that Enlive does this internally, it uses JSoup from Java to convert to plain Clojure data structure. Not sure it exposes this functionality directly though. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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] Enlive-style templating in server-side clojurescript?
There is a pure javascript solution that works well on Node.js : https://github.com/substack/hyperglue From substack, a very talented Node.js developer. The concept is somehow similar to Enlive. Given an HTML file, apply transformations on selectors declaratively by passing an object. Check it out, it might do the job for now. On Monday, July 6, 2015 at 8:47:43 PM UTC+2, Creighton Kirkendall wrote: Tim, There is a current effort underway by Luke Vanderhart to port enlive to cljs. I know that he has a working version in his repo. He is working towards getting the changes accepted into main enlive project. https://github.com/levand Creighton On Tue, Nov 11, 2014 at 2:55 AM, Tim Galebach tim.ga...@gmail.com wrote: Hi, I've been creating some nodejs servers in ClojureScript for some projects I'm working on, and it has worked quite well so far. I now want to do some server-side templating, serving static html to the client. The problem I'm running into so far is that most of the templating libraries for ClojureScript (kioo, enfocus, etc.) seem to require the dom to perform manipulations on HTML. Other solutions like hiccups are less viable because I want to be easily able to mockup in HTML and also work with designers. I love the Enlive approach in Clojure; is there anything similar for cljs, or something I'm missing in one of the existing libraries? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Thx ! Will be an interesting read Le 1 juin 2015 à 18:00, Herwig Hochleitner hhochleit...@gmail.com a écrit : 2015-06-01 17:35 GMT+02:00 Khalid Jebbari khalid.jebb...@gmail.com: So the various states are encapsulated in a go loop? In multiple go-loops, actually. I always knew that core.async could be used to model FSM's. In a way, core.async go blocks desugar into an fsm implementation (reified state, explicit state transitions). Maybe that's what makes them well-suited to implementing FSMs on top. Well, if you can share the code somehow, do so. https://www.refheap.com/101966 -- 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/7STtgK5QiIc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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] Using a state machine to design/program UI ?
So the various states are encapsulated in a go loop ? I always knew that core.async could be used to model FSM's. Well, if you can share the code somehow, do so. Le 1 juin 2015 à 15:26, Herwig Hochleitner hhochleit...@gmail.com a écrit : Wow, big thread. I just want to offer, how I've done a FSM implementation in CLJS: - FSM edges are core.async channels - FSM state changes are represented by passing a token object (which can contain additional state vars) across an edge channel - Each state is represented by a go-loop, with a single in-edge and multiple out-edges - After being passed the token by its in-edge, a state runs, then passes the token to one of its out-edges All said and done, this mainly exploits the excellent work on core.async and core.match. Overall, it smells a lot like actors, only that the possible messages are pre-determined. If you are interested, ping me for code. -- 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/7STtgK5QiIc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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] Using a state machine to design/program UI ?
I mentioned it in the very first post of this discussion Khalid aka DjebbZ @Dj3bbZ On Fri, May 22, 2015 at 5:57 PM, Marc Fawzi marc.fa...@gmail.com wrote: this looks like fun https://github.com/cdorrat/reduce-fsm ;) On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi marc.fa...@gmail.com wrote: Yup, well captured. On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data
Re: [ClojureScript] reagent-nodejs feedback request
To eliminate the need to use 2 different routers, the only possibility I see is to use a js library that works both on client and server-side. Backbone.js has a minimal router like this, you may also want to check crossroads.js or finch.js. But something tells me that you'll need to write some different boilerplate for server and client to plug into this. Both have different ways to listen to URL requests/changes. History.js is famous for doing this in the client I think. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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] Using a state machine to design/program UI ?
You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have
Re: [ClojureScript] Isomorphic ClojureScript
@David, I didn't know this feature. Good to know ! @Marc : it's a matter of trade-offs. Node.js and the JVM are very different platforms. If developer convenience is very important, isomorphic the node.js way with Nashorn or Node could be a good thing. Depends on the developers :) Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 4:01 PM, Marc Fawzi marc.fa...@gmail.com wrote: Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere I love this idea in principle but seeing how confusing reader conditionals can be to a beginner I would personally stick with the Om/Reagent isomorphic path (nashorn or node) On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Javascript developer speaking. The problem with isomorphic apps the Node.js way (not the Meteor way) is that you want to run the SAME code both sides, and client-side concerns aren't server-side concerns. Given it's the same language, and some thing are side-agnostic, indeed a great amount of code is shareable like templates (and event handling with React.js), which make the 1st render fast. But other concerns can't really be written the same way on both sides. Current solutions : - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow you to replace 1-to-1 some files for server-side and client-side. So you need to write your own common interfaces, not easily done. - Use Meteor, and have simple if(isClient/isServer) in your code to split the concerns and let Meteor deal with rest. The thing is that Meteor is not really compatible with the rest of Node.js/npm ecosystem, and they make lot of choices for you about the stack. Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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/T6no_srtBzc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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] Isomorphic ClojureScript
That's right ! Ideology leads nowhere. And we'll all have to write javascript (for browsers) one way or the other anyway :) Le 20 mai 2015 à 16:25, Marc Fawzi marc.fa...@gmail.com a écrit : @khalid true re: trade offs... also, good to diversify thinking in just one tech all day can be a path to ideological stuckness ... :) On Wed, May 20, 2015 at 7:11 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: @David, I didn't know this feature. Good to know ! @Marc : it's a matter of trade-offs. Node.js and the JVM are very different platforms. If developer convenience is very important, isomorphic the node.js way with Nashorn or Node could be a good thing. Depends on the developers :) Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 4:01 PM, Marc Fawzi marc.fa...@gmail.com wrote: Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere I love this idea in principle but seeing how confusing reader conditionals can be to a beginner I would personally stick with the Om/Reagent isomorphic path (nashorn or node) On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Javascript developer speaking. The problem with isomorphic apps the Node.js way (not the Meteor way) is that you want to run the SAME code both sides, and client-side concerns aren't server-side concerns. Given it's the same language, and some thing are side-agnostic, indeed a great amount of code is shareable like templates (and event handling with React.js), which make the 1st render fast. But other concerns can't really be written the same way on both sides. Current solutions : - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow you to replace 1-to-1 some files for server-side and client-side. So you need to write your own common interfaces, not easily done. - Use Meteor, and have simple if(isClient/isServer) in your code to split the concerns and let Meteor deal with rest. The thing is that Meteor is not really compatible with the rest of Node.js/npm ecosystem, and they make lot of choices for you about the stack. Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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/T6no_srtBzc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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/T6no_srtBzc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a *relatively* small set of states that can be transitioned between based in user input. You can even apply state minimization techniques to reduce the total number of states. But in a web app you are continuously grabbing data from the server and that data is generated based on not only user input but also the state of the server side database and that server generated data would modify UI side app state and you have to account for all possibilities so the total number of states could grow wildly if your UI is data driven (where the state of the UI depends on the data in non-trivial ways) but even if your UI state dependence on server data was a trivial relationship you could still end up with a huge state diagram for the simplest viable business app if you include templating the view as part of the UI FSM on top of business logic. You could segment your app into micro apps and that will help regardless of whether you're building the app as FSM or not. And what if the state transitions are probability driven? How many states will you end up having to chart? Not convinced YET... Sent from my iPhone On May 18, 2015, at 6:57 AM, Sean Tempesta sean.tempe...@gmail.com wrote: Hi Khalid. I found your topic interesting so I thought I'd chime in. Regarding your comments on routing: So, under normal conditions, the initial URL sets the FSM in motion (as an event). We could call this entry point a routing state. Afterward, the state transitions are controlling the urls (not the other way around), right? Outside of normal conditions (ie. people copying and pasting links into random parts of the system), you also just send the url to the routing state and then switch to a new state based on whatever rules and definitions you've set. Or maybe I'm missing something. I haven't built an FSM in a while. :) Sean On Monday, May 18, 2015 at 6:07:22 PM UTC+8, Khalid Jebbari wrote: Trying to push forward the discussion about Web UI with state machines. I came up with the following decomposition of the core components of a web application : - application state - application data - business logic - ui
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Indeed, the combination of all states/transitions could lead to something unreadable and unmanageable. I was talking about that with a colleague the other day. Don't have a solution (yet), I'm still learning and reading about FSM. As I was saying in my previous post, having some sort of hierarchy in states machines could help. It boils down to composability of state machines. A few weeks ago some folks showed me a web UI where they could drag and drop and connect state machines to produce a bigger one. The resulting state machine basically generated a new application they could use for a client. I was REALLY impressed. They were using Elixir for that but it doesn't matter. So, compatibility is key here. The aforementioned clojure libs are using data to represent FSMs, so the composition can be made easily I think (from a syntax point of view at least). Needs more 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] Re: Using a state machine to design/program UI ?
Thanks for the clarification, I didn't about them. Now I need even more reading and thinking :) Le 18 mai 2015 à 22:23, Marc Fawzi marc.fa...@gmail.com a écrit : Back to composability I read about stacked vs hierarchical FSMs and it looks like what you want is a stacked one not a hierarchical one... Subgraphs dont have to be entangled with the global graph Sent from my iPhone On May 18, 2015, at 10:26 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a *relatively* small set of states that can be transitioned between based in user input. You can even apply state minimization techniques to reduce the total number of states. But in a web app you are continuously grabbing data from the server and that data is generated based on not only user input but also the state of the server side database and that server generated data would modify UI side app state and you have to account for all possibilities so the total number of states could grow wildly if your UI is data driven (where the state of the UI depends on the data in non-trivial ways) but even if your UI state dependence on server data was a trivial relationship you could still end up with a huge state diagram for the simplest viable business app if you include templating the view as part of the UI FSM on top of business logic. You could segment your app into micro apps and that will help regardless of whether you're building the app as FSM or not. And what if the state transitions are probability driven? How many states will you end up having to chart? Not convinced YET... Sent from my iPhone On May 18, 2015, at 6:57 AM, Sean Tempesta sean.tempe...@gmail.com wrote: Hi Khalid. I found your topic interesting so I thought I'd chime in. Regarding your comments on routing: So, under normal conditions, the initial URL sets the FSM in motion (as an event). We could call this entry point a routing state. Afterward, the state transitions are controlling the urls (not the other way around), right? Outside of normal conditions (ie. people copying and pasting links into random parts of the system), you also just send the url to the routing
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Am reading Horrocks' book. Did you ? Le 19 mai 2015 à 06:17, Mike Thompson m.l.thompson...@gmail.com a écrit : On Tuesday, May 19, 2015 at 3:13:23 AM UTC+10, Daniel Kersten wrote: From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) As Kevin Lynagh said earlier in this thread, the best book around on this subject is Horrocks': http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782 Kevin also mentions a book I've not read yet: Practical UML Statecharts in C / C++. -- 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 a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: Using a state machine to design/program UI ?
This is it, Marc. The SFSM diagram represents exactly what I had in mind. Do you think they're viable in the context of a web app ? As long as they can be stacked as needed, they could handle any complexity of UIs, no ? Khalid aka DjebbZ @Dj3bbZ On Mon, May 18, 2015 at 10:34 PM, Marc Fawzi marc.fa...@gmail.com wrote: stack-based is not exactly stacked but I was thinking chip design for some reason ( http://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit) The one diagram that made it obvious: http://gamedev.stackexchange.com/questions/25854/gamestate-management-hierarchical-fsm-vs-stack-based-fsm On Mon, May 18, 2015 at 1:28 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Thanks for the clarification, I didn't about them. Now I need even more reading and thinking :) Le 18 mai 2015 à 22:23, Marc Fawzi marc.fa...@gmail.com a écrit : Back to composability I read about stacked vs hierarchical FSMs and it looks like what you want is a stacked one not a hierarchical one... Subgraphs dont have to be entangled with the global graph Sent from my iPhone On May 18, 2015, at 10:26 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a *relatively* small set of states that can be transitioned between based in user input. You can even apply state minimization techniques to reduce the total number of states. But in a web app you are continuously grabbing data from the server and that data is generated based on not only user input but also the state of the server side database and that server generated data would modify UI side app state and you have to account for all possibilities so the total number of states could grow wildly if your UI is data driven (where the state of the UI depends on the data in non-trivial ways) but even if your UI state dependence on server data was a trivial relationship you could still end up with a huge state diagram for the simplest viable business app if you include templating the view as part of the UI FSM on top of business logic. You could segment your app into micro apps and that will help regardless of whether you're building the app as FSM or not. And what if the state transitions are probability driven? How many states will you end up
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Indeed I was thinking during the while about the last project I participated, a classical web site with e-commerce processes and forms, for which FSM would have been useful (both client side and server side). I agree with you, there's no silver bullet when we consider the variety of applications possible on the web platform. Le 18 mai 2015 à 23:54, Marc Fawzi marc.fa...@gmail.com a écrit : with a programing language like ClojureScript, we have multiple paradigms to deploy to tackle different kinds of design challenges and come up with an optimal solution to each challenge. It's hard to see how using a single-paradigm tool like FSM or SFSM or even EFSM (the most robust FSM which tackle the complexity of web software creation [1]) can deal with the novel challenges I run into when building a cutting edge web app (e.g. real time, complex interactive data visualizations) When was the last time when you've worked on a novel feature and did not meet a novel challenge? Novel challenges abound in RD oriented product development and they are best dealt with when you have multiple paradigms that you can deploy against it. If you're building cookie cutter, conventional, no thrills web apps, then there are many single-paradigm tools that can be used, including but not limited to FSMs. 1. https://books.google.com/books?id=zvNvk-1OuBoCpg=PA10lpg=PA10dq=stack+based+efsmsource=blots=uIQZJAxkx3sig=paxzhNUxozOVynvJxmGlSKINMh0hl=ensa=Xei=DlxaVdfLJo3aoAT-_4CYBQved=0CC0Q6AEwAg#v=onepageqf=false On Mon, May 18, 2015 at 1:51 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Regarding SFSMs, it looks like the top-level states would be URLs (in a well behaved application), and the nested ones would be for any widgets inside the pages. Just thinking out loud. Khalid aka DjebbZ @Dj3bbZ On Mon, May 18, 2015 at 10:49 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: This is it, Marc. The SFSM diagram represents exactly what I had in mind. Do you think they're viable in the context of a web app ? As long as they can be stacked as needed, they could handle any complexity of UIs, no ? Khalid aka DjebbZ @Dj3bbZ On Mon, May 18, 2015 at 10:34 PM, Marc Fawzi marc.fa...@gmail.com wrote: stack-based is not exactly stacked but I was thinking chip design for some reason (http://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit) The one diagram that made it obvious: http://gamedev.stackexchange.com/questions/25854/gamestate-management-hierarchical-fsm-vs-stack-based-fsm On Mon, May 18, 2015 at 1:28 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Thanks for the clarification, I didn't about them. Now I need even more reading and thinking :) Le 18 mai 2015 à 22:23, Marc Fawzi marc.fa...@gmail.com a écrit : Back to composability I read about stacked vs hierarchical FSMs and it looks like what you want is a stacked one not a hierarchical one... Subgraphs dont have to be entangled with the global graph Sent from my iPhone On May 18, 2015, at 10:26 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Trying to push forward the discussion about Web UI with state machines. I came up with the following decomposition of the core components of a web application : - application state - application data - business logic - ui logic - event processing - presentation layer - routing In this schema, I think the application state is the real core, because every other components is directly related to it, at least if you use a state machine. I came up with the following model. - application data : related to application state because both can easily represented as data. If we want a web app that is completely state-driven (I want this, for debugging, testing and time-travel capabilities), simply merge the data and the state in the same data entity. - business logic/ui logic : in a state machine there's the notion of actions executed with each transition (where necessary). So the logic could just be executed by the state machine itself. - event processing : a state machine can be event-driven, and this a perfect match with a web app since the web (and any UI for that matter) is inherently event driven. So the event/input of the state machine could just match the event triggered by the user, as well as custom events if necessary. - presentation layer : simply display the current app-state as HTML/CSS. In the React.js model, it would simply mean updating the app state and letting React render everything. - routing : this is where stuff gets complicated in my mind. In a proper application, lot of state is derived from the URLs. But not all state, for instance whether a modal is displayed or not, or whether a form is validated client side or not isn't tied to a URL. Which tend to let me think that there's some kind of hierarchy in the state machine. The URLs could be represented as events as well in the state machine, but could happen at anytime, whereas other events and related transition depend on the current state in a state machine. So it's like you have a top-level state machine for URLs, and each URL has its own state machine for all interactions in the page. Maybe page-state machine could be refined in multiple levels state machines too, not sure about that. It seems like Hierarchical State Machine may help here, but I haven't studied the subject yet at all. What do you think ? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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] Using a state machine to design/program UI ?
Ruslan, I haven't look at the code or tried your example. But being able to draw the program's logic and have it executed is even more than awesome. I'm not sure whether graph-to-code like what you did, or code-to-graph like what automat or Kevin's (from this thread) work do is better, but simply knowing that both are possible in the CLJ(S) world... I'm happy I started this thread. Khalid aka DjebbZ @Dj3bbZ On Thu, May 14, 2015 at 3:45 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: And that is why they should be compiled, not implemented directly in main language of the project. I've made experimental yEd diagrams → CLJ(S) FSM compiler and executor (https://github.com/ul/vfsm). Simple example of its usage could be found here https://github.com/ul/ampere/tree/master/examples/simple — open resources/example.graphml with yEd ( http://www.yworks.com/en/products/yfiles/yed/) to see how control logic of handler is defined. What is the real fun, that it is easy to spot an error in the logic looking on that graph. If you rewrite this state machine in textual code, you will get something harder to inspect. четверг, 14 мая 2015 г., 6:39:02 UTC+3 пользователь Erik Price написал: Finite state machines are a useful modeling tool, but when implemented in code they can involve a lot of boilerplate and complexity. These days I prefer Rx-like paradigms for sophisticated handling of asynchronous events. e On Wed, May 13, 2015 at 5:54 AM, Khalid Jebbari khalid@gmail.com wrote: Hello everyone, As a Javascript web developer, I'm thinking more and more about a good way to design interface so that I don't create a mess. Because I think the current state of the art of web UI development and frameworks is still a big mess. React.js and the CLJS wrapper around them help a bit but not that much I think. My goals are the following : - construct the complete UI logic outside of anything web related, so that it's testable without a browser and usable in other contexts (CLI, back-end, scripts, whatever) - being able to *visualize* the logic without having to read all the code, through diagrams and other means. I've heard in several places that state machines are a good way to handle such cases, since they're inherently event-driven and the web is too. So I start researching. The wikipedia page ( https://en.wikipedia.org/wiki/Finite-state_machine) and the various linked pages are very instructive and indeed explain that a FSM can be used to model UI interaction. I found this 3-parts article series from IBM ( http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that implements a tooltip using a state machine. Then I found 2 clojure libs that helps design a state machine : reduce-fsm (https://github.com/cdorrat/reduce-fsm) and automat ( https://github.com/ztellman/automat). Both have the *very* nice feature of being able to generate a state diagram from the code, but only automat provides support for CLJS. I think a state machine fits very well with React.js and as so the various CLJS wrappers, since : - in an event-driven state machine, there's a loop listening to events. This event-loop is naturally provided by web browsers - defining strictly and formally the available states helps reduce bugs and maintain the application - the output is always defined by the combination of the input and the current state, which is *exactly* what the render function of React component are about : displaying DOM based only on the state of the component. Since this state is purely data, and CLJ/CLJS are kings when it comes to data, the benefits would be to be able to test the logic a component outside of the DOM and have components that simply emit events (with the associated payload) to the state machines. The various libs in the CLJ/CLJS ecosystem can help greatly : - the aforementioned automat lib to design and visualize a state machine - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert ( https://github.com/miner/herbert) and the likes to formally specify data types/shapes that come in and out of the state machine - test.check to generate lots of input to the state machine and check the output. This can't replace UI testing, but can complement it a lot. Note that Herbert is de facto compatible with test.check - The various React.js wrappers to take this state and simply project it to the DOM. This post is basically a reflection on the subject that I wanted to share and not lose in my mind since I'm new to state machines, and a question to the community : did you already use a state machine to program a web UI ? Successfully ? With which tools ? What do you think of the various libs (aka the stack lol) proposed above ? I know that a simple state machine trivially implemented with no libs at all and may seem often
Re: [ClojureScript] Using a state machine to design/program UI ?
Generating a functional state machine from a diagram is awesome. Generating a diagram from the code of a state machine is awesome too. But state diagram are only 1 of the 2 visual representations of state machines AFAIK. The other is the state transition table : https://en.wikipedia.org/wiki/State_transition_table I already opened an issue to the automat repo, hoping Zach Tellman will consider generating the table from the code being a good idea. And also in Ruslan's vfsm to generate a state machine from a table. Visual programming for the win, really. Khalid aka DjebbZ @Dj3bbZ On Thu, May 14, 2015 at 10:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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 a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [ClojureScript] Using a state machine to design/program UI ?
In the case of global app state combined with a state machine, where would the URL be stored ? Should it be considered a trigger/event of the state machine ? Should it be stored in the state as any other data ? Le 15 mai 2015 à 03:22, Marc Fawzi marc.fa...@gmail.com a écrit : Thanks Brutha! :) Sent from my iPhone On May 14, 2015, at 6:11 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: Speaking of Cambrian Explosion, I saw in the latest LispCast a link to a new React CLJS lib from weavejester called Brutha: https://github.com/weavejester/brutha Jamie On May 14, 2015, at 8:54 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: Actually, I'm interested in local transitions (cell=) rather than local state. That is, a view may be interested in transitions that only apply to itself. I like the idea of encapsulating those transitions into the view itself. re-frame's subscriptions are inherently global, at least to whichever namespaces have required the subscriptions. This offers better encapsulation as I understand them. Jamie On May 14, 2015, at 8:27 PM, Daniel Kersten dkers...@gmail.com wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what state your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. On Thu, 14 May 2015 22:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I'm still in the early stages of digesting Javelin, but one idea I keep having is using it locally in components to make subscriptions that are otherwise global using reframe. On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
I understand the relationship between state machines and event-log/CQRS. A program could just translate the UI events into events stored in an event log, and let them be consumed continually by a state machine. You would basically reduce the events log using the state machine as a reduction function. When you say logic end up in lot of different places, do you mean logic that should be related ? I'd like to understand more about that point. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: Using a state machine to design/program UI ?
Ok, you talk about logic being on the server and the client. I thought you
were saying that related logic was spread across different points from an
architecture point of view, like some in the event-log consumers, some
in the components, some in the request handlers etc. (these are just
examples).
Khalid aka DjebbZ
@Dj3bbZ
On Wed, May 13, 2015 at 2:30 PM, Colin Yates colin.ya...@gmail.com wrote:
Yeah, I didn't explain that second point well. Because of the lack of
(my experience with) web based tooling I typically have most of the
logic on the back end leaving the UI to be pure rendering only. With
the symmetry of CLJ and CLJS that technical barrier has disappeared.
Case in point, I am just now coding logic which summarises the
criteria used to select the data you are seeing. Imagine a table with
a set of tabs, each tab allowing you to restrict some criteria and the
table shows you matching results. The logic to produce something like
Viewing 132 out of 3423 results for location 1 and location 2, across
all woogies and non-active wibblies, ... is less trivial then it
might sound. Previously I would have returned this as part of the
results returned from the server {:results [..] :total-count 3423
:context for location 1 ...} where as now I am less nervous about
that logic living on the web tier. Of course, there are other concerns
for this case in point around data staleness (you don't want the
context being updated before the results are updated etc.).
tldr - the symmetry of CLJ and CLJS make it easier (for me at least)
to put non-trivial logic on the front end
On 13 May 2015 at 13:06, Khalid Jebbari khalid.jebb...@gmail.com wrote:
I understand the relationship between state machines and event-log/CQRS.
A program could just translate the UI events into events stored in an event
log, and let them be consumed continually by a state machine. You would
basically reduce the events log using the state machine as a reduction
function.
When you say logic end up in lot of different places, do you mean logic
that should be related ? I'd like to understand more about that point.
--
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to the Google
Groups ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojurescript+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/7STtgK5QiIc/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.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+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: Using a state machine to design/program UI ?
I just watched the video. Wow. Having a live statechart is even better than what I imagined. It reminds me somehow of the NoFlo JavaScript project. This would be an awesome lib to have... (Am I suggesting you should open source this statechart stuff ? :D). Seriously thank you for the pointers. I'll definitely study this methodology. Le 14 mai 2015 à 00:00, Kevin Lynagh ke...@keminglabs.com a écrit : In addition to the Horrocks book, take a look at Practical UML Statecharts in C / C++. This book also describes Harel Statecharts, but goes into much more depth about how one can implement them on embedded systems. I've been experimenting with using Harel Statecharts as an architecture for ClojureScript applications, and it has been working out very well. This video from last year describes that work: https://www.youtube.com/watch?v=57wJpfMcfnU (I haven't open sourced any of these tools, though since I recorded that video Figwheel came out and David has put a ton of work into the cljs compiler, so you should be able to get up and running with those tools.) -- 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/7STtgK5QiIc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: Using a state machine to design/program UI ?
I have a question for you Kevin : when you modeled your logic with a state machine, were you able to unit test it outside of the browser ? (Sorry if the answer is in the video, I haven't watched it yet) Le 14 mai 2015 à 00:00, Kevin Lynagh ke...@keminglabs.com a écrit : In addition to the Horrocks book, take a look at Practical UML Statecharts in C / C++. This book also describes Harel Statecharts, but goes into much more depth about how one can implement them on embedded systems. I've been experimenting with using Harel Statecharts as an architecture for ClojureScript applications, and it has been working out very well. This video from last year describes that work: https://www.youtube.com/watch?v=57wJpfMcfnU (I haven't open sourced any of these tools, though since I recorded that video Figwheel came out and David has put a ton of work into the cljs compiler, so you should be able to get up and running with those tools.) -- 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/7STtgK5QiIc/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: Reagent TodoMVC
On Friday, April 24, 2015 at 7:04:13 AM UTC+2, marc fawzi wrote: http://todomvc.com/examples/reagent/ https://github.com/tastejs/todomvc/blob/master/examples/reagent/readme.md :) Nice to have an example in the official TodoMVC repo. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: [ANN] cljs-pikaday, a reagent date picker
Thx for the link to closureplease. Will help a lot ! -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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
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 colin.ya...@gmail.com 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.
[ClojureScript] Re: react - performance difference between hiding or removing elements?
On Friday, March 27, 2015 at 2:40:45 PM UTC+1, Colin Yates wrote: I realise this is one of those 'it depends', but in general, is it recommended to hide elements in react or not render them? For example, I have an SPA with a bunch of top-level pages. Each page has a number of tabs, each tab might be a tree or a table and so on. I could render the whole thing and hide non-relevant things with 'visible: hidden', or I could only render what is actually needed. I went with the second as it seems 'cleaner' somehow, but it does mean you need to track more things: - scroll positions of various panels - expanded/collapsed state - etc. On the other hand, rendering everything and using the hidden class might overwhelm the dom and I am unsure of how expensive a reflow caused by showing/hiding compared to replacing the dom. The general opinion I get from google, stack overflow and react docs is to only render what is needed, but nothing definitive. If it matters, this is a closed intranet with pretty lame PCs, so waiting a while for the app to load is fine. Switching between tabs/panels, expanding tree nodes etc. should be as quick as possible. Has anybody done any studies/offer any guidance? Thanks! I've seen a talk wednesday by a guy specialised in Web Perf. He clearly stated that BIG DOM makes stuff slow. I would definitely not render them. Hiding/showing should be reserved for small parts of a component, i.e. an error message in a form. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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
If you're more interesed into the pattern I described, you can read more here : https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0. This is really where the React.js community is headed. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: react - performance difference between hiding or removing elements?
By the way, he developped a nice tool (and open-sourced it!) to measure perf based on a lot of criteria : http://yellowlab.tools/ -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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
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 jamie...@gmail.com
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 m.l.thompson...@gmail.com
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 colin.ya...@gmail.com
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.
---
You received this message because you are subscribed to the Google
Groups ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojurescript+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/WOGdUY79Xv4/unsubscribe.
To unsubscribe from this group and all its topics, send
Re: [ClojureScript] re-frame - sanity check for re-usable components
Staying tuned !
I'm not in SF, will there be slides or videos ?
Le 27 mars 2015 à 20:16, Marc Fawzi marc.fa...@gmail.com a écrit :
You can have your cake and eat it.
Will present the complete approach on the next Reagent meetup in SF, and
while we are talking about having a presentation about re-frame port of
ANgular's phonecat example, the reusable smart components presentation will
be based on RAW Reagent, nothing added.
Stay tuned.
On Fri, Mar 27, 2015 at 10:58 AM, Khalid Jebbari khalid.jebb...@gmail.com
wrote:
If this approach suits you better, fine. Remember, this approach is coming
from the React.js world, where everything is mutable and where there's no
committment to a particular way of passing data/events. For my current
projects, we indeed encapsulated both markup and behaviour, but it was hard
sometimes to make it reusable without changing/hacking it. We didn't use a
global method for sharing state like Flux, so it may explain why.
Khalid aka DjebbZ
@Dj3bbZ
On Fri, Mar 27, 2015 at 6:45 PM, Daniel Kersten dkers...@gmail.com wrote:
Marc, can you tell us a little more about the approach your taking?
On Fri, 27 Mar 2015 at 17:43 Marc Fawzi marc.fa...@gmail.com wrote:
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
khalid.jebb...@gmail.com 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 jamie...@gmail.com
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 m.l.thompson...@gmail.com
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 colin.ya...@gmail.com
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
[ClojureScript] Re: ClojureScript Google Closure Module support
Browserify : https://github.com/substack/node-browserify Factor-bundle : https://github.com/substack/factor-bundle -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: ClojureScript Google Closure Module support
Haven't tried yet the new modules compilation strategy, but I know a very good strategy available in the JS world with Browserify and its plugin factor-bundle. Basically, factor-bundle analyses all the emitted code and put in a single file every single module (written like node modules) that appears twice or more in the various emitted files into a single file. So there's never duplication of code. Example: module A requires module B. module C requires modules B D. You compile A C. Browserify would output 3 files : A.js, C.js and another (custom name) common.js that would include modules B and D. It handles automatically the exposition of B and D so that anyone can require them. Result and benefits: A.html contain script tags for A.js and common.js. C.html contain script tags for B.js and the same common.js. So common.js is cacheable by browsers out the box, reducing the payload. The other benefit is that each page requires only 2 script tag. We're currently using this process in production, it's one of the best in the JS world. I think the idea is awesome, especially since it requires almost no configuration. Factor-bundle manages to find all common code by analysing the dependency graph. Since Google Closure Modules / CLJS namespace also create a dependency graph I'm pretty sure it's somehow possible. No ? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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 Google Closure Module support
Thanks for the clear explanation. It's pretty clear I should play with it to see how it goes. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: File uploads in ClojureScript + React
On Saturday, February 14, 2015 at 3:26:53 PM UTC+1, Michiel Borkent wrote: I am currently looking at the options for supporting file uploads in several browsers in a ClojureScript SPA. My first attempt was posting a form with a file upload with cljs-http. This didn't work because the Ring/compojure app started to complain about the content boundary not being in order. Also just using cljs-http will not work for IE9 of course. Next, I gave goog.net.iframeIO a try. This will work for the spectrum of browsers we have to support, but working with iframes for modern browsers doesn't feel right. Then I tried jquery-file-upload. Still playing around with it, but I'm pretty sure this will give me what I need, as it has a fallback mechanism for older browser via iframe transport. I wonder what other options I have and what is convenient in combination with React and ClojureScript. Feel free to post some examples to your open source projects or give any other helpful tips. Thanks, Michiel Borkent Why do you need a plugin at all ? A basic form with the input type=file should work fine. form method=post enctype=multipart/form-data input type=file name=[some name] / input type=submit value=Upload / /form Supported since IE 3.0 I think... -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: Touch events and React.js/Om
No need to fiddle with other libs or complicated build steps, React js handle
this very well.
Simply handle the touchend event and preventDefault().
In React's JSX syntax :
div onClick={myHandler} onTouchEnd={myHandler}.../div
myHandler: function(event) {
event.preventDefault();
... // do your stuff
}
The preventDefault() call avoids the click to trigger 300ms after the touch
event.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+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: Touch events and React.js/Om
I didn't notice any usability issue of this kind. Touching triggers touchend and no click, clicking on desktop triggers click normally, and scrolling triggers none of them. Maybe our use cases were different, hence the need for you to introduce fastclick. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: Om 0.8.6, Hello CLJSJS
Indeed, data is better than app. Khalid aka DjebbZ @Dj3bbZ On Mon, Feb 2, 2015 at 10:49 AM, Sebastian Bensusan sbe...@gmail.com wrote: Thanks Khalid, The way I see it, Om has three concepts regarding state: 1. The global state defined with atom. Named `app-state` 2. The cursor passed to each component with the relevant parts of the global state. Named `app` 3. Local state of each component, initialized in `IInitState` and manipulated with `(set-state! owner korks v)` and `(get-state owner)`. It is a property of the owner object so it is not directly referenced. I agree that `app` is ambiguous for 2 but I wouldn't like to call it `app-state` nor `state` since those could also be confused with 1 and 3. Nothing better than `cursor` or `data` comes to mind. Some other parts of the Documentation (the Example in https://github.com/swannodette/om) use `data` and I think it works even if it is a meaningless term for a fn argument. If you agree and nobody raises objections I'll change `app` to `data`. Sebastian -- 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/bruQ9os5wmM/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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+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: ANN: Om 0.8.6, Hello CLJSJS
On Sunday, February 1, 2015 at 9:16:05 PM UTC+1, Sebastian Bensusan wrote: I changed the tutorial to use a new version of the figwheel template https://github.com/bhauman/figwheel-template. When the new template is published to Clojars we can update the Om wiki. I'll move on to the Intermediate tutorial. If by the time I'm done with all of the tutorials the template is not published I'll do it myself. The new version: https://github.com/bensu/basic-om-tut/blob/master/Basic-Tutorial.md Feedback is welcome. Hope this helps. On Saturday, January 31, 2015 at 5:19:35 PM UTC+1, David Nolen wrote:Template preferred. On Saturday, January 31, 2015, Sebastian Bensusan sbe...@gmail.com wrote: Sure, I'll explore Figwheel's new REPL and add that instead. What about adding/configuring Figwheel? Should it be step by step inside the tutorial, from mies-om to mies-om + Figwheel? Or it should just start with a ready to go template mies-om-wheel? Thanks Sebastian Bensusan On Saturday, January 31, 2015 at 1:26:34 AM UTC+1, David Nolen wrote: I would prefer just Figwheel. Relying only on Figwheel also means you could probably go out with an updated tutorial much sooner. Thanks, David On Fri, Jan 30, 2015 at 4:10 PM, Sebastian Bensusan sbe...@gmail.com wrote: Hi David and Dan, I edited Om's Basic Tutorial (https://github.com/swannodette/om/wiki/Basic-Tutorial) to be used with Chestnut. Most of the work (not much!) was changing evaluate in LightTable to save in your text editor. I don't know what the procedure is for updating a Wiki and having this conversation, should I open an issue on Om? I have it as a standalone repo in case someones wants to propose a change or make a pull request: https://github.com/bensu/basic-om-tut Two issues: 1. Chestnut 0.6.0 (current stable version) uses Om 0.7.3 and I needed to deref a cursor inside a go loop in order for things to work. See https://github.com/swannodette/om/issues/315 and https://github.com/swannodette/om/commit/92a3e0cf698769fb59bb3744faddaea40b37412d. Om version is bumped to 0.8.3 beta in v0.7.0-SNAPSHOT-20141226 2. Chestnut's 0.6.0 doesn't reload the index.html (not on save, not on refresh). The whole process needs to be restarted. See: https://github.com/plexus/chestnut/issues/84 This was addressed in v0.7.0-SNAPSHOT-20141207. I would wait until Chestnut 0.7.0 stable is published in Clojars before adding this tutorial to the Om Wiki. Otherwise, if you feel the extra dependency on Chestnut is also too much, I'll fork mies-om and add Figwheel there for the tutorial. After revising this work, I'll move on to the next tutorial. Best Sebastian Bensusan On Tuesday, January 27, 2015 at 5:25:09 PM UTC+1, David Nolen wrote: I think expecting every last thing to work especially from third parties who may be wisely lagging behind is unlikely at least for the near future. I haven't kept up with Light Table and what issues it may have. Now is probably a good time to remove the Light Table centric nature of the Om tutorials and switch to a Figwheel based thing that doesn't require anything more than your text editor of choice. The wiki has always been community editable and I would love to see people push it forward especially with stuff like this. I will have less time for such things as I focus more on Om core and ClojureScript enhancements. David On Tue, Jan 27, 2015 at 10:46 AM, Olav Nymoen ol...@comoyo.com wrote: Just testing clojurescript out so many possible pitfalls on my side here. Does the new javascript externals stuff break lighttables live external browser functionality? Following the basic intro tutorial I cannot get live updates to work. The mies-om om-tut is based on 0.8.4 , and it cannot reference com.facebook.react, while 0.8.6 cannot find cljsjs.react. It compiles nicely with lein, but I can't seem to get the lighttable live REPL stuff to work. Olav On Tuesday, January 27, 2015 at 1:57:19 AM UTC+1, David Nolen wrote: The only significant change is that Om now relies on the cljsjs.react artifact instead of the one I maintained myself. cljsjs.react has the benefit that usage of React with addons instead of plain React may be configured via Maven in your pom.xml or your project.clj. It's exciting to see that we are already reaping the benefits of :foreign-libs and Maven over existing JavaScript solutions for managing dependencies. This release also includes a fix for a very subtle set-state! bug discovered by Brenton Ashworth.
