Perhaps (?) not a practical concern here, but beware recursion in javascript. There's still no such thing as tail recursion in node, so each time you recurse the call stack gets longer (and it has a max allowed size).

(And this can always be expressed as a while loop!)

I was having trouble getting code coverage with the while loop Eran had here, because parent would never evaluate to false, since the root server always has vision state. The root server always has vision state because of the { setup: true } introduced in the register func.

Here's what's currently in vision - the loop Eran wrote:

internals.realm = function (server) {

    if (server.realm.plugins.vision) {
        return server.realm.plugins.vision;
    }

    let parent = server.realm.parent;
    while (parent) {
        if (parent.plugins.vision) {
            return parent.plugins.vision;
        }

        parent = parent.parent;
    }

    return {};
};

As soon as the root server goes in this loop, it is returned as having a realm because setup.true will always be there. So parent = parent.parent will never run, which would cause it to evaluate to false in the while loop, and return {}

This could possibly be rewritten as nearestManager, which would fix the issue of returning just because a realm has state in vision

I think rootRealm is a slightly odd variable name here– it's not the root realm until it's returned (and not being used as a variable anymore).

Agree!

Wait, when server.views() is called inside a plugin wont this set the manager on the plugin's parent? It would be hard to see this in a test when nearestState() comes into play. But imagine server1 registers a plugin with server2, and server2 register a plugin with server3. Now server3 calls server3.views()– I think this will cause server2 and server3 to both have the same manager.

I think you're probably right, I'll definitely go back and ensure this acts correctly in tests

Doesn't the manager make this assertion on its own?

Yup! No need to export the schema I suppose

Why this change?

This might've slipped through when trying to write tests based off of others. I can remove it!

Should we be using awaiting the return of this? (seen later in other call sites as well)

await server.register(...

I've asked around about this, "what's the difference between return await [Promise] and return [Promise]? And ljharb in the Node.js Slack community said they're identical in what they do, only returning an await causes an unnecessary wrapper. Do you know if there's a difference?

I see. That's good to know.

Do you know if there's a difference?

Nope. I'm new to async/await in general.

I find it's generally easier to remove cognitive load by simply awaiting anything async– only think about the underlying promises when really necessary. For what it's worth, in a lot of hapi code you'll find return await somePromise. Unless perf is terribly important, that seems most consistent.

Good to know!!

I'm curious why you're using return here. I don't see a reference in the docs about needing to return anything from a plugin's register function. (seen later in other call sites as well)

I'm curious what others think of using the fingerprint /# for detecting when using the 'onRequest' server extension.

When using the toolkit view decorator inside the onRequest server extension, it seems like this.request.route.realm is set to the root server every time.

this should be the toolkit itself. If h.view() is called in an extension then h.realm will be the realm in which the extension was created.

I'm pretty sure you want to always use h.realm and not h.request.route.realm here. Imagine writing a plugin that has its own manager and registers some extensions (but no routes). When calling h.view() in one of those extensions I think you would expect to know only about your manager/templates, and not about other managers/templates registered in a different plugin (i.e. a separate plugin that registers routes).

Hm, now I can't remember why I wrote it grabbing the realm from the route.