refactoring registry and builder from the next.js app to a separate package

[odnodn]

Hi, would you mind refactoring registry and builder from the next.js app to separate packages so that it would be easier to setup in non next.js environments or new projects.

For new non-next.js projects using the builder (or registry without setting up through shadcn), the next.js project has to be cloned, the next.js part then has to be either stripped out or adapted. When using a fork, you then loose syncing. Or am I missing something?
It would be easier to just include your packages (buzzform lib, optionally registry, and builder) and you would be set up quickly.

[ladparth]

Hey @odnodn, I am currently working towards this approach to make BuzzForm framework agnostic and headless. so far, i was able to create core package. I am working on react package now( assessing to use Tanstack Form due to some feature overlap and granular reactivity features). Lastly, as you said registry components and builder into a package as well to keep my next app clean. However, i would like to know what your current use case is at this stage? are you trying to use "Builder" and "Registry" in your own app?

[odnodn]

Perfect! 😄
And yes, would like to embed Builder (and Registry) in a react app for faster prototyping forms in an internal app on a github private project, then internally release to github pages (which is only static, so all server side next.js code has to be eliminated). So I have to refactor the cloned next.js app, stripping out next.js content, but this then breaks when you have new feature releases. Would be easier to not touch the next.js app.

[ladparth]

Perfect. Got it. When i created the builder, it was my intention to extract it as a package at a later stage and make it reusable for others to import. For registry, it is somewhat challenging as shadcn's new release makes it hard to support all variants/presets without registry in next js but i will be cleaning it up a little to make sure there's no nextjs syntax being used. i would be open to ideas if you have any recommendations.

Also, wanted to know if you care whether the react package i am building uses tanstack form or react hook form as a form engine? Form engine is something i wouldn't want to build from scratch.

[odnodn]

The registry is probably not the problem, this should probably not exist as separate library due to different variants/presets as you said. This should be up to the developer using the library. But either cleaning up next.js syntax would be fine, or , better , - as you are intending to do - placing the builder in its own package and importing to next.js (or react).

I haven't used tanstack forms yet, but I like tanstack libraries in general, especially tanstack table and their abstraction. TF seems to have at least feature parity and is framework agnostic which RHF is not. Probably this is the way to go, even though it has 10times less github stars, at least for now. Haven't checked how much they differ in form syntax and how easy it would be replacing RHF. But as you are hiding internal RHF or TF logic, maybe this should not be a problem.

Thanks for the hint for TF, have to have a closer look the next weeks. Their component pipeline just seems to be exploding. 😆