You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got a hot reloader for JS that uses this project at the core and I'm curious about how I can help provide an extension point of some kind. I realize not everyone has the ability to do hot reloading of JS and even if they could it's likely they all need something a little different to accommodate based on the frontend tech stack.
For example, in the gif below you will see I'm using ember and at this time (early days yet) I'm firing an event from a ember dev tool that will dispatch it back to my application to re-render the component. I couldn't possibly submit a generic pull request here that unlocks hot reloading for all but I could do everything I needed if a special hook was available.
One "creative" solution I came up with was to monkey patch the reloadPage function as it's called at the very end of the reload chain anyway.
window.LiveReload.reloader.reloadPage=function(){//my hot reload JS code }
The one missing piece that would require a pull request/ discussion/ etc is that I need the path when this is called and today reloadPage doesn't take any arguments. This was me thinking more quickly on the subject so it's worth mentioning that we could offer an official override-able hook that is called just before reloadPage and it would be provided path so users "could opt in" for a custom hot reloading method if they wanted.
I personally like the ability to have an escape valve like this so I can still leverage 99% of the great work in livereload-js while still supporting hot reload for my ember apps w/ ember-cli.
I've got a hot reloader for JS that uses this project at the core and I'm curious about how I can help provide an extension point of some kind. I realize not everyone has the ability to do hot reloading of JS and even if they could it's likely they all need something a little different to accommodate based on the frontend tech stack.
For example, in the gif below you will see I'm using ember and at this time (early days yet) I'm firing an event from a ember dev tool that will dispatch it back to my application to re-render the component. I couldn't possibly submit a generic pull request here that unlocks hot reloading for all but I could do everything I needed if a special hook was available.
One "creative" solution I came up with was to monkey patch the
reloadPage
function as it's called at the very end of the reload chain anyway.The one missing piece that would require a pull request/ discussion/ etc is that I need the path when this is called and today reloadPage doesn't take any arguments. This was me thinking more quickly on the subject so it's worth mentioning that we could offer an official override-able hook that is called just before reloadPage and it would be provided
path
so users "could opt in" for a custom hot reloading method if they wanted.I personally like the ability to have an escape valve like this so I can still leverage 99% of the great work in livereload-js while still supporting hot reload for my ember apps w/ ember-cli.
Thoughts? Questions? Next Steps?
https://github.com/toranb/ember-hot-reload-spike
*keep in mind the above project is a spike to prove out hot reloading with ember-cli
The text was updated successfully, but these errors were encountered: