Feature: Event Bubbling

• Based on behavior outlined here & found in most other HMR implementations.
• Needed by Prefresh, others.
• /cc @JoviDeCroock who wanted to implement in Snowpack

Requirements

• If a changed file has no accept() handler, the client needs a way to “bubble up” the change event to be handled by it’s parent(s)
• If a file has multiple parents, the event must bubble up each parent’s chain of imports.
• If an event bubbles up to a dependency tree entrypoint, trigger a full page refresh.
• No import.meta.hot API changes, if possible
• The server cannot scan a file that hasn’t been requested by the client (implication: no “full application” scanning step allowed)

The “Let the Server Do All The Work” Proposal

• No change to the Server->Client interface. Keep existing update message format:

  • {type: 'update': url}.

• The server stores a representation of your website dependency tree in memory:

  DependencyTree {
    [url: string]: {
      dependents: url[];
      dependencies: url[];
      isHmrEnabled: boolean;
    }
  }
  

• At server startup, DependencyTree is empty.

• Every time we serve a file, we scan the JS response and then update the DependencyTree with information about that one file. This never scans more than that one response.

• Every time a file changes, we call updateOrBubble(file):

  function updateOrBubble(url) {
    node = DependencyTree[url];
    if (node.isHmrEnabled) {
      send to the client: `{type: 'update': url: file}`
    } else if (node.dependents.length > 0) {
      node.dependents.map(updateOrBubble);
    } else {
      // We've reached the top, trigger a full page refresh
      send to the client: `{type: 'reload'}`
    }
  }
  

Open Questions

• Is it okay to send “update” events as we traverse the DependencyTree, or should we send them all at once in a batch? Webpack seems to send them in batches, but I believe this is more a limitation of bundling and not actually a requirement for good HMR.
• How do we track our progress through the DependencyTree so that we never call updateOrBubble() twice on the same node (or, would we ever need to?)
• Make sure that we can handle added/moved/removed imports in the DependencyTree.
• Make sure that we can handle added/moved/removed files in the DependencyTree.

[JoviDeCroock]

Revisiting the following statement:

I’m trying to consider the impact of non-batching and I think I’m getting there. What if we have a function that is shared across x components. Won’t we potentially render a stale tree if we have a series of updates rather than one big batch?

Since we are doing it in two passes:

• Pass 1 bubble up and mark modules
• pass 2 top down imports

It should not be possible to get stale trees due to an outdated parent.

Also we added the rewriting of imports, imagine a scenario where B (no accept) bubbles up to A (accept). When A is triggered again the import of B will be stale, that’s why beforee we send a hot response back we’ll rewrite the imports to match the ?mtime A was requested with

[FredKSchott]

Merged here + snowpack published within snowpack v2.0.0-rc.3 + esm-hmr v0.1.0