Otion SSR proposal to hide internal complexity

[katywings]

Motivation

• Trying to separate otion internal ssr logic from consumer business logic.

Proposed implementation

import { setup } from "otion";
import {
  filterOutUnusedRules,
  getStyleTag,
  VirtualInjector,
} from "otion/server";

export const otion = function (func: Function, otionOptions = {}) {
  const injector = VirtualInjector();

  setup({ ...otionOptions, injector });

  let html = func();
  const styleTag = getStyleTag(filterOutUnusedRules(injector, html));
  html = html.replace("</head>", styleTag + "</head>");

  return html;
};

Consumer usage

import { otion } from 'otion/ssr'
const html = otion(() => {
  return someComplicatedConsumerSsrHtml();
})

Details

• Earlier proposal https://twitter.com/Katy_Wings/status/1275193727275982849 ;)
• Example code: https://github.com/sossejs/sosse/blob/69806e8c5e83637ccf4005cef994c802a82402bc/otion/lib/main.ts#L8

Let me know if you have any questions :D

[kripod]

Thank you very much for suggesting this! It would significantly lower the barrier for consumers. I'll try my best to implement this during the weekend.

[katywings]

@kripod You're welcome ;), no stress and take care ^.^!

[kripod]

While this seems to be an interesting take, after a second thought, I lean towards a more transparent approach where each step is self-describing. As seen in the Next.js example, otion shall be set up with a VirtualInjector before rendering the HTML asynchronously, and afterwards, styles can be replaced with the solution provided by Next.js. A similar API exists in Gatsby, which speaks for the preference of composability over conciseness.

Thanks for your ongoing efforts regarding this project and I apologize for being so late with the review.

[katywings]

My proposal wasnt meant as a replacement of the current api, but as an additional alternative ;). But I understand your points and having only one way for doing something can be an advantage 👍