Allow plugin render function to be async

[greym0uth]

Currently a plugin's render function must be sync so we run into a roadblock if a plugin's render function needs to resolve an async operation (i.e. hitting CMS api, etc) before setting the state of a hydration script or before we call the context's render function.

Any ideas how to get around this or how the plugin render fuction could be updated to allow for it to be async?

[greym0uth]

This would allow for something like this to exist:

// routes/index.tsx
import { content } from "../utils/content.ts";

export default function index() {
  return (
    <article>
      {content`content-key`}
    </article>
  );
}

// utils/content.ts
let content: Record<string, string>;
export function content(strings: TemplateStringsArray) {
  return content[strings[0]] || "no_content";
}

export function setup(new_content: Record<string, string>) {
  content = new_content;
}

// plugings/cms.tsx
import { setup } from "../utils/content.ts";

export default function CMSPlugin(): Plugin {
  return {
    name: "cms-plugin",
    async render(ctx) {
      const content = await fetch_content();
      setup(content);
      ctx.render();
      return {};
    },
  };
}

A really simple workaround for this specific example would just to run the fetch_content in the route handler where ever content from the CMS is needed, but only if you have a small amount of data you're pulling from the CMS and are okay pulling the entire CMS every render.

What if we only want to pull in the content keys we're using and content injections are scattered around, nested in components, or exist inside islands?

Content injections in islands are easy as we can just pass a hydration script, and pass the resolved content to the state of that script (just like the twind plugin). The server-side generated content injections can be accomplished by making two render passes: one to build the list of keys that need to be fetched and the second to render the resolved content in.

I don't really like the idea of running the render pass twice so there may be a better solution or might introduce another DX decision to work out, but that is the only way I could think of accomplishing this while keeping this discussion focused on allowing the plugin's render to be async and not introduce any other features.

[lucacasonato]

This is not what the render function is for. The render function must stay sync so that no two render functions can ever run concurrently.

A future middleware hook would be better suited.

[greym0uth]

What're you thinking the middleware hook DX would resemble? Would the middleware hook just function similar to a route middleware, but instead of plugins?

I'm willing to help out wherever I can with an implementation. I can also open a different thread or continue the discussion in an existing thread if one exists. That way you can close out this discussion.

Ah looking at the roadmap I see you were referring to the longer term item: "Extend plugin system to support injecting middlewares, islands, and routes".

[marvinhagemeister]

FYI: Since this question was asked we added renderAsync() to the plugin API. See https://fresh.deno.dev/docs/concepts/plugins#hook-renderasync