Breaking hotreloading about babel-watch HOT 5 CLOSED

Hey @ChrisCinelli ! Sorry for getting back to you so late. In general I don't have any good idea on how babel-watch could support such a complex use-case. If you have any suggestion on how precisely this could work I'd be keen to listen.

I'm not entirely sure if I understand how your setup works, so I'm assuming you have webpack that bundles JS and then also serverside rendering that uses the same client code, right? If so I worked on an app with very similar setup and the way we solved it was by starting two processes: one with webpack and the second with server code. Webpack will handle client code updates and hot reloading (webpack will keep socket connection open when updating client JS files) whereas babel-watch will handle restarting the server

Let me know if that helps!

from babel-watch.

It is a little more tricky when you have isomorphic code. I.e. component code that is used both on the server and frontend. Splitting server and client process does not help.

Going back on what I was asking, I think the tricky part is to find a good way for the process to communicate to babel-watch. Maybe something like: http://stackoverflow.com/a/36995148/407245

So if you start babel-watch with --delay-restart, it does not restart the process until the child send a process.send('full_page_reload'). The babel-watch user will have to send process.send('full_page_reload') when a route with a full page reload is hit.

from babel-watch.

@ChrisCinelli what do you mean by "more tricky"? I use the setup with two processes I described with isomorphic code (one process runs webpack, the other runs server code with server side rendering of react app)

Are you sure restarting the prcess whenever page reload is requested would solve your problem? If the server process dies when you're reloading your page the browser would get no response back. So in my opinion it is not sufficient to just wait with restart but I might be missing something...

from babel-watch.

I will try to be more clear. In an isomorphic app you have the code of components (that I keep in a "client" folder) that is shared and runs on both the server and the browser. Ideally you are able to modify HTML and CSS of the component and the react hot-reloader will be able to push the new version to the browser without restarting the server. The hot-reloader, though, does not push the code to the server. For that you need a server restart.

Now I tried 2 things:

1. I restart the server whenever a file in the folders change, this breaks the hot reloader and in general add latency or hiccups if you do ajax requests because these requests cannot be completed until the server is restarted.
2. I exclude the "client" folder from the watcher. But if I need to re-render the page from the backend after modifying component code in "client", I need to manually restart the process.

I am not sure how using 2 different processes can fix this problem. Both processes will have to detect changes in the "client" folder and once you modify a component file in it, they will both restart. Or am I misunderstanding what you suggested?

What I am suggesting is to have babel-watch to watch the server code (that includes the root page component) but when a file is changed, instead of restarting the server immediately, waits until there is full page reload (signaled by the code).
I think with the native implementation you will see an error because the connection is broken. A work around is to reload the page twice. For a full solution, either the parent process will proxy the request preserving the connection, or we issue a redirect to the same page URL before sending the signal to the parent.. The latter is a little more hacky but I think it should work.

from babel-watch.

This is a pretty complex use case that we don't intend to actually support. However, I'd be happy to accept a PR that would wait for a signal to do the reload, if you'd like.

from babel-watch.