Support selecting multiple fragments

[joeldrapper]

This PR adds support for matching multiple fragments. Each fragment is rendered in its own <template> with a data-id attribute matching the ID of the fragment matched.

[joeldrapper]

@midnightmonster I realised we don’t return empty <template>s anyway so this data-id isn't particularly helpful.

[midnightmonster]

We could, though. If we get all the way to the end and there's still something left in @fragments, just spit out the empty template tag.

[joeldrapper]

Yeah, I’m debating if this is worth it, since you can always find the missing IDs by looking at the child nodes on the client side.

[joeldrapper]

It’s one of those things where if we put data-id in now, we can’t remove it later. But if we don’t, we can always add it in. So I’m inclined to keep it out for now.

[midnightmonster]

Remembering that there's a need for both "remove this node which is no longer present" and "silly developer, why did you ask me for a node that's inside another node you also asked for?"—I think the simplest thing is not to use the template tags at all. Client side makes the request and remembers which IDs it asked for. It instantiates the response text as a DocumentFragment (or however you're doing this) and (assuming it was requesting specific IDs at all) just goes down the list of IDs it knows it requested, querying the response document fragment by ID.

1. If it finds the ID in the response and the page, morph the page version with the new version.
2. If it finds the ID in the response but not the page, discard with perhaps a warning (presumably it does this already?).
3. If it finds the ID in the page but not the response, remove the node from the page.

This means it morphs a second time for a nested id, but those should be rare-to-never and it shouldn't result in any changes, so it probably doesn't matter.

[joeldrapper]

This makes sense. It’s actually a not ideal to have to manage multiple <template>s in the client-side code. It would be easier to make a new <template> and set its inner HTML to whatever came back from the server, and then iterate over the template’s child elements.