Fred K. Schott
Fred K. Schott
I feel like the current design hits the right balance between the max-verbose and the max-dynamic designs you've outlined: - arguments are optional to support multiple use-cases - (`accept()`, `accept(cb)`,...
In the documented API, `accept(cb)` and `accept([], cb)` behave identically
Does this help? ```js accept(['./depA'], ({ module, deps }) => { // deps & module could both be relevant to your use-case. // self module is always updated. }) ```...
~~You're right, that's a bug in the example. It should instead be:~~ Whoops, I read too quickly. That example is actually fine as is: you would only want to update...
> On your next edit, the store in the callback will be a stale one that is never used, so future updates will have no effect. Maybe this is a...
Sorry, got bogged down with 2.0 release work. Yea, I guess that's fair, maybe 1:1 compatibility shouldn't be the goal here if you already have an implementation that you're happy...
> one can't implement both API and stuff will conflict. Is this a useful goal? Parcel, Webpack, and Rollup (plugins) all include different `module.hot` implementations with varying levels of support,...
If splitting out `accept` and `acceptDeps` bring all 3 of our implementations into one big, happy "generalized" spec... then I'm willing to swallow my personal preference. I'm a bit out...
I'm +1 on this! The reasoning makes sense
So what I've learned since starting this: the trickiest part of HMR is event bubbling. If a file changes, an "update" event is kicked off that starts to bubble up...