Option to register partials before first request

[Andrew Powell]

We have the need in our application to preload partials before the first request to the app is made. With how koa-hbs currently functions, the partials within the partialsPath property of the config aren't registered until the first request to the app is made. This makes any modification (or use of the partials through the same handlebars instance) before the request is complete problematic.

It would be great to have the option of instructing koa-hbs to register all partials (and even layouts/views) before the first request.

[Joe Wilm]

Do you have a suggestion for how this should look? I am thinking by default to preregister them for production environments and not otherwise. A config flag such as preloadTemplates = true would be useful to override this as needed.

[Andrew Powell]

I don't understand the notion of only making that available to production environments - it's not a matter of performance for us.

preloadPartials as a flag should be separate from preloadTemplates if you're proposing preloading templates not in the partialsPath directory. The current problem is that partials are only loaded on the first call to createRenderer at present. We've had to hack around this quite a bit.

[Joe Wilm]

This makes any modification (or use of the partials through the same handlebars instance) before the request is complete problematic.

What is the use case for this? I can see the point during development when you want to reload templates after changes are made, but any deployment of the application should not have dynamically registering templates.

if you're proposing preloading templates not in the partialsPath directory

Again, what is the use case for this? I cannot imagine a time when you would want to preload partials but not templates; hence preloadTemplates instead of preloadPartials.

I will be more than happy to support these things if you can illustrate why they should exist. I'm on board with the preloadTemplates, but I don't see the point of fine grain control over partials.

[Andrew Powell]

We're using this in a situation where a template is being used both as a partial and a base template, depending on some other data. There's also a partial in question which is being used directly in a base template, but the render result of which is also sent to a client as a data chunk via a REST api. Those are two use cases we're working with, the latter I think being the more common.

Bear in mind there's an entire application we're working with and while that may seem ludicrous, it was in fact the most sane way to accomplish a particular goal. Unfortunately I'm not at liberty to share the entirety of our internal app structure.

Here's what we're currently having to do, without modifying the koa-hbs source directly, which we're desperately trying to avoid:

  // this loads the partials BEFORE the first request is complete.
  app.use(function *(next) {
    if(!hbs.partialsRegistered) {
      yield hbs.registerPartials();
    }
    yield next;
  });

  app.use(middleware); // koa-hbs middleware

While it's a decent work-around, it's yet another function in the request pipeline that doesn't have to be there.

[Joe Wilm]

I can see why you'd want to get that moved out of the request pipeline. You've also highlighted a challenge with preloading partials - it's an asynchronous operation. If we add a flag preloadPartials to the koa-hbs middleware config, we need to queue render requests until everything is loaded. This solution does not completely solve your problem, though. The abstraction leaks - any calls to the underlying handlebars instance are not guaranteed to have partials registered until after a yield this.render() returns. Alternatively, if the only problem is not accepting requests until partials are loaded, you could do something like the following.

// Similar to your workaround without an extra function in the stack
co(function *() {
    yield hbs.registerPartials();
    app.listen();
});

I don't see other options for preloading while providing a guarantee on the state of koa-hbs and the underlying handlebars instance.

[Joe Wilm]

This is now marked as inactive and will be closed soon without further input. It looks like there is a viable solution for registering all the partials before accepting requests without any changes to this package.

[Andrew Powell]

I think it's safe to close. I don't know enough about the underlying arch to comment further, and there are two solutions to the problem. It's just a shame that it doesn't ship with one or the other. Regardless, this should be a good info point for anyone with the same needs. Thanks for discussing.