Docs: Add Iterative chaining design

[JakobJingleheimer]

No description provided.

[GeoffreyBooth]

@JakobJingleheimer do you mind splitting out the updates to the recursive design to be its own PR?

[JakobJingleheimer]

Sure. I'm away til Sunday; I can do it then.

[GeoffreyBooth]

I suppose all these are optional, since a hook could just return void; and then the loader would be skipped, right? And if none returned anything, Node’s default eventually would?

[JakobJingleheimer]

Yes, merely returning void would cause that specific loader to be skipped. If all loaders did that, Node's default would eventually run.

[GeoffreyBooth]

So in the current docs “transpiler loader” example, the full “loader” is a set of one resolve hook and one load hook. So coffeescript-loader would be the set of a resolve hook and a load hook, not a reference to just that loader’s load hook. Hence -resolver feels weird, as -loader is not its parallel.

[JakobJingleheimer]

I updated the doc to strip those out in all but some file names. The casual nomenclature I was using was a resolver provides only a resolve hook, and a loader (an unfortunate naming collision with the main "loader" concept) provides both resolve and load hooks. I dunno what one might be called that provides only a load hook—maybe "sourcer"? But taking it out hopefully means we don't have to solve that problem 😛

For this casual usage:

• "resolvers" would be: unpkg, cache-buster
• "loaders" would be: coffeescript, https, and maybe babel

[GeoffreyBooth]

I would think that this should be undefined by default, not an object with empty strings as values. That’s really awkward to test against.

[JakobJingleheimer]

Hmm, I considered that.

I think resolve and load's interimResult should be the same in that regard, and resolve may have settled with a format, which is fed into load's interimResult.format, so then undefined vs quasi-empty object gets rather complicated. So I figured it's most straight-forward to just make them both objects with falsy initial property values of the appropriate data-type.

[GeoffreyBooth]

Why not just specifier? There’s no other specifier parameter, and since it’s not part of interimResult it would appear that no hook can modify the specifier.

This is a key difference between the designs: in the other design, one loader can call the next with different values for all of the parameters. In this design, a loader can communicate to the next in the chain only via its return values.

[JakobJingleheimer]

🤔 I went with originalSpecifier to ensure it was obvious that that value has not been modified in any way from what the user provided, and thus is not to be confused with the settled url. I know people are already confused by the term specifier and don't use it (using almost exclusively "import path" or "import url"), so it seemed like something that needed some extra clarity.

But thinking on it now, the properties in context are all "original"-ish values, so maybe it does make sense to just call it specifier.

[GeoffreyBooth]

And if this loader is first, so there’s no interimResult yet? Something like this?

if (!interimResult) {
  interimResult = defaultResolve(undefined, context);
}

const url = new URL(interimResult.url);

And now we have a hybrid of the two designs.

[JakobJingleheimer]

Yes? I think that only applies here (or to a first one) though?

[GeoffreyBooth]

Is this intended to be here? If it is, shouldn’t specifier be here too?

[JakobJingleheimer]

Is this intended to be here?

parentUrl? Yes, I think it's supposed to be there.

shouldn’t specifier be here too

No? 🤔 It could be, but why? (this is load, so specifier has already settled to url)

[JakobJingleheimer]

I thought of this after the meeting whilst I was updating the docs: nesting these under signals seems like a nice grouping to denote they are all signals, and reduces the surface area of the return (which was growing rapidly).