Re: [ClojureScript] Re: A new take on ClojureScript and npm

2017-05-17 Thread jiyinyiyong 
Yes Webpack will replace the dependent files. Webpack made a concept called
"module tree" based on dependency tree. File changes will propagate along
the tree, and hit the root at last. But if a change propagates to root, the
whole page reloads. That's not what we wanted.

I don't have an example, but you may follow the docs:
https://webpack.js.org/guides/hmr-react/#app-code

roughly 3 steps(I did that before but not sure about every detail)

1) add configs in `webpack.config.js`



  entry: [
'react-hot-loader/patch',
// activate HMR for React

'webpack-dev-server/client?http://localhost:8080', < add this
// bundle the client for webpack-dev-server
// and connect to the provided endpoint

'webpack/hot/only-dev-server', < add this
// bundle the client for hot reloading
// only- means to only hot reload for successful updates

'./index.js'
// the entry point of our app
  ],

  plugins: [
new webpack.HotModuleReplacementPlugin(),  < add this
// enable HMR globally

new webpack.NamedModulesPlugin(),
// prints more readable module names in the browser console on HMR updates
  ],

2) add `module.hot.accept('./demo', cb)` to handle the changes from
'./demo', so it will not reload the page:

// Hot Module Replacement APIif (module.hot) {
  module.hot.accept('./components/App', () => {
render(App)
  });}

3) replace `webpack` to `webpack-dev-server` to start bunding:

webpack-dev-server


Webpack would inject code that starts a WebSocket and responds to file
changes. Since it contains many steps, it's highly possible you run into
problems setting up Webpack HMR.

On Wed, May 17, 2017 at 6:54 PM Thomas Heller  wrote:

> The shadow-cljs compiler already does the correct thing when it comes to
> macros and recompiles all affected CLJS files.
>
> It does however know nothing about JS files that may be affected as well
> so it would not reload those. I don't know if the webpack HMR will reload
> dependent files?
>
> Does it reload ./index.js if that does require("shadow.cljs/some.foo") and
> some.foo was recompiled?
>
> I have never even seen a HMR config, can you share one so I can try a few
> things?
>
> On Wednesday, May 17, 2017 at 12:48:18 PM UTC+2, Jiyin Yiyong wrote:
> > Just realized that ClojureScript is different from CoffeeScript because
> of the macro system. If a macro changed, it may cause changes of multiple
> files. So that it's hard to just detect which file changed and compiled it
> alone. The only window left is to read and compare file content before
> writing, if we are trying to get rid of the unnecessary change events...
> >
>
> --
> 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/AGXku7Ous0Y/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: A new take on ClojureScript and npm

2017-05-17 Thread Thomas Heller 
The shadow-cljs compiler already does the correct thing when it comes to macros 
and recompiles all affected CLJS files.

It does however know nothing about JS files that may be affected as well so it 
would not reload those. I don't know if the webpack HMR will reload dependent 
files?

Does it reload ./index.js if that does require("shadow.cljs/some.foo") and 
some.foo was recompiled?

I have never even seen a HMR config, can you share one so I can try a few 
things?

On Wednesday, May 17, 2017 at 12:48:18 PM UTC+2, Jiyin Yiyong wrote:
> Just realized that ClojureScript is different from CoffeeScript because of 
> the macro system. If a macro changed, it may cause changes of multiple files. 
> So that it's hard to just detect which file changed and compiled it alone. 
> The only window left is to read and compare file content before writing, if 
> we are trying to get rid of the unnecessary change events...
> 

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from 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: A new take on ClojureScript and npm

2017-05-17 Thread jiyinyiyong 
Just realized that ClojureScript is different from CoffeeScript because of
the macro system. If a macro changed, it may cause changes of multiple
files. So that it's hard to just detect which file changed and compiled it
alone. The only window left is to read and compare file content before
writing, if we are trying to get rid of the unnecessary change events...

On Wed, May 17, 2017 at 6:18 PM Thomas Heller  wrote:

>
> > * in `node_modules/` there are always tens or even thousands of folders,
> which I'm never happy to open it.
> >
>
> That is indeed scary, but you'd never need to open it. Same way you never
> look at any other node_modules folder probably.
>
> >
> > * for hot module replacement issues, sometimes we want to ignore the
> whole `node_modules/` because of the amount of the files,
> https://webpack.js.org/configuration/watch/#watchoptions-ignored . I
> don't think all of us will ignore that folder, but we might do and we
> consider code in `node_modules/` remaining the same.
> >
>
> Given that you can specify a regexp you can just use
>
> ignored: /node_modules\/(?!shadow-cljs)/
>
> where it still ignores any node_modules folder except shadow-cljs.
> Watching this folder however is currently not the best idea because I was
> lazy and didn't optimize for it yet. That means that the compiler will emit
> all files on compile, not just the files that were actually
> recompiled/changed.
>
> I will fix that eventually.
> https://github.com/thheller/shadow-cljs/issues/9
>
> --
> 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/AGXku7Ous0Y/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: Large public clojurescript websites

2017-05-17 Thread Jiyin Yiyong 
On Saturday, May 13, 2017 at 11:43:03 PM UTC+8, Marc Griffiths wrote:
> Hi,
> 
> I recently deployed a 100% cljs/cls site: organicinvestmentcooperative.com.au
> 
> I'm wondering if people can point me towards other clojurescript websites, or 
> people or resources to help build commercial scale websites in clojurescript
> 
> Feels like there is a lot of potential here, but lack of front end libraries 
> is causing more development work compared to more mainsteam technologies
> 
> Thanks!
> Marc

How about https://github.com/status-im/status-react/ 

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from 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: A new take on ClojureScript and npm

2017-05-17 Thread jiyinyiyong 
> Where is the difference in putting code into node_modules or compiled
then using webpack?

I'm not sure either. But here's what I see:

* in `node_modules/` there are always tens or even thousands of folders,
which I'm never happy to open it.

* for hot module replacement issues, sometimes we want to ignore the whole
`node_modules/` because of the amount of the files,
https://webpack.js.org/configuration/watch/#watchoptions-ignored . I don't
think all of us will ignore that folder, but we might do and we consider
code in `node_modules/` remaining the same.

As a result, using `resolve.alias` appears more acceptable to me.

On Wed, May 17, 2017 at 2:12 PM Thomas Heller  wrote:

> On Wednesday, May 17, 2017 at 3:51:14 AM UTC+2, Jiyin Yiyong wrote:
> > I don't like the way of writing `x.assoc(null, 'foo', 'bar')` by myself.
> Also I don't people would accept that.
> >
>
>
> I wouldn't as well, but that was an example to show that you can use CLJS
> code directly without modifying it in any way.
>
> import { assoc } from "shadow-cljs/cljs.core";
> assoc(null, "foo", "bar");
>
> also works. assoc is an ugly example because of the leading null but it is
> the shortest form to replace the CLJS {} empty map literal. {} would mean
> empty JS object which doesn't work with assoc.
>
> > I see the problem now. ClojureScript compilers may have tricky behaviors
> that make it different from CoffeeScript's compiling processes.
> >
>
> The compiler is pretty straightforward actually, the tricky parts are the
> version conflicts. If there was a way to ensure that everything always used
> the exact some compiler configuration/version this would be possible, but
> there is not AFAICT.
>
> > Putting `x.cljs` files in npm is fine, it's just slower. To me compiling
> ClojureScript is always slower, I already accepted that.
> >
>
> [:script] Build completed. (23 files, 1 compiled, 0 warnings, 0.12s)
>
> I think 0.12s is pretty fast. That is running in --dev mode recompiling
> one changed file with hot-reload enabled.
>
> Of course it is slower if you always run "shadow-cljs --once" which
> includes starting the JVM each time. "shadow-cljs --dev" will be
> substantially faster when re-compiling.
>
>
>
> >
> > I think here are may main concerns:
> >
> >
> > * in js projects, we regard code in `node_modules` are modules instead
> of source code. For web projects using Webpack, I would prefer using a
> 'compiled/' folder to hold the code and then config `resolve.alias` to make
> sure I import the code with `require('cljs/foo.bar.core')`.
> https://webpack.js.org/configuration/resolve/
> >
>
> Not sure what you mean. Where is the difference in putting code into
> node_modules or compiled then using webpack? The behavior is identical, the
> node_modules version just doesn't need the resolve.alias? Both versions
> require that you have your code compiled before running webpack, which
> directory you load them from should be automatic?
>
>
> > *  For nodejs projects, somehow I can accept the solution that we use
> `require('../../compiled/foo.bar.core')`. But I guess it may bring
> problems, which makes your `shadow-cljs` solution a better choice...
> >
>
> Yes, I hate relative paths. Actually the output folder where things end up
> is a config option. So if you really wanted to have your compiled folder
> that can be done. I just don't see an upside to it.
>
> >
> > * does shadow-devtools compiled cljs files incrementally? If it does,
> Webpack may use it to hot replace module.
> >
>
> Yes, incrementally. Don't know anything about HMR but shadow-devtools
> already has hot-reloading (ala figwheel) built-in. I just didn't enable it
> yet because other things were more important.
>
> Can't tell if Webpack HMR would work since I have never used it.
>
> Thanks for the feedback, I hope I lessened your concerns.
>
> Keep it coming.
>
> Remember: this is evolving as we discuss it, I have no idea what JS devs
> want so without feedback I'll be building what I want. That may or may not
> align.
>
> --
> 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/AGXku7Ous0Y/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

[ClojureScript] Re: A new take on ClojureScript and npm: The Other Side

2017-05-17 Thread Thomas Heller 
Quick Update: Just renamed the repo/artifact to thheller/shadow-cljs. Got tired 
of having to differentiate between shadow-devtools and shadow-cljs.

Release coming later today.

Github should take care of redirecting all the old links.

This is the new home:
https://github.com/thheller/shadow-cljs

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from 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: A new take on ClojureScript and npm

2017-05-17 Thread Thomas Heller 
On Wednesday, May 17, 2017 at 3:51:14 AM UTC+2, Jiyin Yiyong wrote:
> I don't like the way of writing `x.assoc(null, 'foo', 'bar')` by myself. Also 
> I don't people would accept that.
> 


I wouldn't as well, but that was an example to show that you can use CLJS code 
directly without modifying it in any way.

import { assoc } from "shadow-cljs/cljs.core";
assoc(null, "foo", "bar");

also works. assoc is an ugly example because of the leading null but it is the 
shortest form to replace the CLJS {} empty map literal. {} would mean empty JS 
object which doesn't work with assoc.

> I see the problem now. ClojureScript compilers may have tricky behaviors that 
> make it different from CoffeeScript's compiling processes.
> 

The compiler is pretty straightforward actually, the tricky parts are the 
version conflicts. If there was a way to ensure that everything always used the 
exact some compiler configuration/version this would be possible, but there is 
not AFAICT.

> Putting `x.cljs` files in npm is fine, it's just slower. To me compiling 
> ClojureScript is always slower, I already accepted that.
> 

[:script] Build completed. (23 files, 1 compiled, 0 warnings, 0.12s)

I think 0.12s is pretty fast. That is running in --dev mode recompiling one 
changed file with hot-reload enabled.

Of course it is slower if you always run "shadow-cljs --once" which includes 
starting the JVM each time. "shadow-cljs --dev" will be substantially faster 
when re-compiling.



> 
> I think here are may main concerns:
> 
> 
> * in js projects, we regard code in `node_modules` are modules instead of 
> source code. For web projects using Webpack, I would prefer using a 
> 'compiled/' folder to hold the code and then config `resolve.alias` to make 
> sure I import the code with `require('cljs/foo.bar.core')`. 
> https://webpack.js.org/configuration/resolve/
> 

Not sure what you mean. Where is the difference in putting code into 
node_modules or compiled then using webpack? The behavior is identical, the 
node_modules version just doesn't need the resolve.alias? Both versions require 
that you have your code compiled before running webpack, which directory you 
load them from should be automatic?


> *  For nodejs projects, somehow I can accept the solution that we use 
> `require('../../compiled/foo.bar.core')`. But I guess it may bring problems, 
> which makes your `shadow-cljs` solution a better choice...
> 

Yes, I hate relative paths. Actually the output folder where things end up is a 
config option. So if you really wanted to have your compiled folder that can be 
done. I just don't see an upside to it.

> 
> * does shadow-devtools compiled cljs files incrementally? If it does, Webpack 
> may use it to hot replace module.
> 

Yes, incrementally. Don't know anything about HMR but shadow-devtools already 
has hot-reloading (ala figwheel) built-in. I just didn't enable it yet because 
other things were more important.

Can't tell if Webpack HMR would work since I have never used it.

Thanks for the feedback, I hope I lessened your concerns.

Keep it coming.

Remember: this is evolving as we discuss it, I have no idea what JS devs want 
so without feedback I'll be building what I want. That may or may not align.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from 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.