caridy
commented
8 years ago @nlwillia you have the fetch hook, and you can do your own fetching, and keep your own cache. On top of that, we have the module status metadata, which will be exposed to the hooks, and finally, we might populate that metadata with some stuff in the default hooks, but we haven't get to that level of detail just yet. IOW, yes, this will be possible.
A loader hook might want to do something expensive with a module the first time it's seen and cache the result. (The specific caching approach doesn't matter; it's just something that's persisted somewhere across requests.) Over time, the hook can invalidate the cache in response to changes to the resource as long as it has something intrinsic to compare. However, there may be changes to the application configuration that would necessitate cache invalidation even though the specific resource did not change. In this scenario, it would be useful if hook code could access details of the fetch response instead of just the body. For example, it could observe a 200 instead of a 304 and respond to the hard reload by invalidating unconditionally. There might also be headers in the response that a hook could vary its behavior in response to.
There are other ways to signal the sorts of things a hook might want to respond to, but this typically requires cooperation from things outside the scope of the hook itself. If the
ModuleStatuscontained details about the fetch response, then a hook could act more autonomously. This information would be protocol dependent, so I don't know if this is something the spec should speak about or if it's better left to loader implementations (or if it's too fringe for either to consider), but it's something that you can't currently do in something like es6-module-loader without overriding fetch completely which is why I wanted to explore the idea here.