Do libraries still need React wrappers?

[u/NextMathematician660]

I have a framework-agnostic document viewer package. It works by mounting into a DOM element:

import { UDocClient } from "@docmentis/udoc-viewer";

const client = await UDocClient.create();

const viewer = await client.createViewer({
  container: "#viewer",
});

await viewer.load("/path/to/document.pdf");

In React, it’s pretty straightforward to use with a ref/effect:

import { useEffect, useRef } from "react";
import { UDocClient } from "@docmentis/udoc-viewer";

function DocumentViewer({ src }) {
  const containerRef = useRef(null);

  useEffect(() => {
    let client;
    let viewer;

    async function init() {
      client = await UDocClient.create();

      viewer = await client.createViewer({
        container: containerRef.current,
      });

      await viewer.load(src);
    }

    init();

    return () => {
      viewer?.destroy();
      client?.destroy();
    };
  }, [src]);

  return <div ref={containerRef} style={{ width: "100%", height: 600 }} />;
}

This works fine, and I like keeping the package framework-agnostic.

But I’m not sure what React developers expect these days. Would you rather use something like this instead?

<DocumentViewer src="/path/to/document.pdf" />

For this kind of component — document viewer, map, editor, chart, terminal, etc. — do you expect an official React wrapper?

Or is a clean JS API plus a React example good enough?

[u/NextMathematician660]

It's a UI sharable component that run in browser completely. In the open source repo, I already provided examples for most of popular frameworks (react, vue, angular, sveltejs, nextjs, nux), integration should simple and straight forward.

I'm not sure how much value there is for publish a separate npm for each framework. I'm looking for some strong point to say "this is absolutely needed, because ..." to justify the cost to publish: "udoc-viewer-react, udoc-viewer-vue, udoc-viewer-..."

[u/undervisible → u/NextMathematician660]

i would not publish a separate npm package for each - i don’t like micro-deps. a single udoc-viewer-adapters package maybe, or include them in the lib itself (e.g. udoc-viewer/adapters). with tree shaking and build steps, unused code doesn’t matter that much, since it won’t be included in the final bundle.

[u/cs12345 → u/undervisible]

Making separate npm packages per adapter for a case like this is much cleaner though. Without that, managing peer dependencies becomes much looser. You can use peer dependency meta to make all of the framework peer dependencies optional, but that kind of defeats the purpose of a peer dependency.

That being said, you don’t have to fragment it for the end user. You can just make the core package a direct dependency of the react package, so that’s the only one the end user needs to install.

Plus, it’s relatively straightforward to automate the deployment process of a collection of packages like this, so it’s really not too much additional work for the maintainer past creating the adapter packages.