How to implement browser sync ?

[Nicolas Delsaux]

During DevoxxFR '16, I saw a nice presentation about feedback loop for
developpers (it was very cool).

Most of the features presented by the speakers were already available in
Wisdom (which I informed them), excepted browser sync, which I find very
cool.
Let me explain quietly : when a javascript file is changed, the browser
sync reload the page to make sure the version used by the browser is the
latest one.
Furthermore, if more than one browser is open, navigation (including
scrolling) is synchronized on all browsers.

There obviously is a npm/grunt/gulp "thingie" for that :
https://www.browsersync.io/
But it seems to be node only, as it includes a server-side component.

So, my goal is quite clear, I would like to implement such a feature for
Wisdom. This would obviously be only available in dev mode.
In the best of world, I would reuse the client-side JS, but i don't know
how to do ... and even if it is a good idea.

So, what do you think about that ? Do you have any implementation
suggestion ?

--
Nicolas Delsaux

[clement escoffier]

Hi,

I think it's easy to do it. You just need a "maven watcher" that emit the reload event. I was always suspicious about this feature. Let me explain. I think it looks great, but I'm not sure it is actually "that" useful. It save a keystroke (refresh). I can see more benefits when editing the CSS (so you don't have to refresh when using a dual screen), but otherwise, I fear it emits too many reload while you have still pending change to do. It can become confusing. That's the main reason why it's not "integrated". However, I don't mind adding it. 

If you look at https://github.com/jprichardson/reload/tree/master/lib, it looks like there is a server and client sides. The client side lib can be added to the application but I don't see how to inject it automatically to the pages. The server side would just be managed by the processor. Another design would be a bundle that do that at runtime (and waits for the application restart to reload the page). This second approach may makes the "dev/prod" support easier, and would also avoid CORS issue.

Clement 

--
Nicolas Delsaux

--
You received this message because you are subscribed to the Google Groups "wisdom-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wisdom-discus...@googlegroups.com.
Visit this group at https://groups.google.com/group/wisdom-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/wisdom-discuss/5721080F.8030505%40gmx.fr.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Delsaux]

Le 01/05/2016 17:50, clement escoffier a écrit :
> Hi,
>
> I think it's easy to do it. You just need a "maven watcher" that emit
> the reload event. I was always suspicious about this feature. Let me
> explain. I think it looks great, but I'm not sure it is actually
> "that" useful. It save a keystroke (refresh). I can see more benefits
> when editing the CSS (so you don't have to refresh when using a dual
> screen), but otherwise, I fear it emits too many reload while you have
> still pending change to do. It can become confusing. That's the main
> reason why it's not "integrated". However, I don't mind adding it.

In fact, the browserSync node extension do more than that, but I will
start by this side, as it is the most spectacular/demoable one. Anyway,
there is something I don't fully understand : for the reload to take
place, i have to expose a controller, which will emit events (using
websocket/server side events/I don't mind yet). But will my watcher be
able to do so ? in other words, how can I register a controller in a
watcher ?

>
> If you look at https://github.com/jprichardson/reload/tree/master/lib,
> it looks like there is a server and client sides. The client side lib
> can be added to the application but I don't see how to inject it
> automatically to the pages. The server side would just be managed by
> the processor. Another design would be a bundle that do that at
> runtime (and waits for the application restart to reload the page).
> This second approach may makes the "dev/prod" support easier, and
> would also avoid CORS issue.
>

Another interesting question ... I think I will insert the javascript
file through an interceptor which will add that JS to each HTML page.
Maybe it's overkill .. I don't know.

Can you extend your second approach ?

From what I understand, in such a case, my watcher would emit an
"event" (maybe through vert.x event bus) that the bundle will consume to
fire the web event. But, if doing so, how will my bundle be installed in
application ? can I "contribute" it to OSGi deployment in a way that is
independent from my application lifecycle ?

And finally, doing so will require I write two components : the watcher,
and the web side. Won't it be a little cumbersome to use ?