Current state of this project

[JulianCataldo]

I accept PRs and Issues, but I don't currently have time to review them swiftly.

I got some ideas to make this lib more SSR friendly, more headless, etc. so I'll will do everything in one sweep at that moment.

Note that I only maintain the core (headless) lib, not the UI implementations, which are up to you to customize. But PRs are welcome, of course.

Feel free to show your support if you think this project can evolve into something more professional, with more advanced features ;)

And don't forget it is not a production-ready project!

[pgoforth]

@JulianCataldo I do firmly believe that this can evolve into a production ready product...in fact, I'm in the process of doing that now (only using the core, building our own UI). Lets establish goals, make issues, work toward implementations. I'll also be happy to assist, but without a direction...my PRs will be relegated to features and fixes.

I see some areas for improvement (more automation, improved build process) but I'm curious about where you want to go? I agree that focusing on the core library is what is essential. UI flavors should be left up to individual devs or community updates.

[JulianCataldo]

Hello @pgoforth,

I'll get some time 3 months or so, in the meanwhile, I could give you a maintainer role for the org., and I'll just do a quick review for the novelties before including them, what do you think?

Here is the basic stuff that I wanted to sort out before I paused this project:

• Types errors. Recursive data passing JSON schema, objects and mutating values. It's performant, but I didn't typed it very well, I wanted to have a PoC without nit-picking too much, and my TS skills were weaker. It could be easier for me now.
• CSS build. I don't really like fiddling with CSS to TS conversion. But that could be leaved for userland implementation, I'll just maintain Shoelace (now WebAwesome), because it's my goto UI lib.
• SSR batte-tests. Especially now that WebAwesome will support it. It should already work with the System theme, though.
• More advanced schemas features (if, then,…)
• CI/CD broke, and can be enhanced a bit (I planned to copy those bits from news monorepos I've made, like the Gracile one, I.e., some progress regarding @next tagged version handling.
• TESTS, TESTS, TESTS

There is more, especially regarding UI Schemas, I'll post later on this, because it's a central concern.

Cya

[JulianCataldo]

Regarding the testing side, I've experimented with open-wc web test runner for custom elements mounting points, lit-ssr (for, well, testing SSR capabilities), Gracile (for convenience) and Playwright (for more intricate stuff, like hydration compliance). Also, regarding SSR, I would test against Web Awesome (an as soon as it is release) and System (bare) widgets.

[pgoforth]

So, I'm prefacing this all by saying my time to devote to OS projects is very limited, and I will most likely be working on things that would directly benefit my usage of the library. That said, I'm happy to contribute and try to address these issues along the way.

Perhaps I can give some insight into this process based on how I am currently using this library.

I am only using the base @jsfe/form and am extending it using my own UI. I am using my own build process (webpack in my case) to create multiple versions of my UI library for different browser support. CSS is all compiled through postcss, minified, and split into a seperate file...no sass, just modern CSS syntax.

In regards to augmenting the form schema, I actually built a form builder schema myself a couple years ago, and I can see a lot of ideas I implemented there that would be useful to this project (dependent fields, data referencing, things like that). I will go through my schema and highlight some ideas and give examples as I get the time.

Testing

IMO there are many levels of testing that need to happen, not just the UI or Integration level tests that you refrence. I bring this up because (in my experience) web components (and by proxy custom elements) are in their infancy with testing libraries, and you should not solely rely on these kinds of tests. I would suggest starting with:

• Unit testing around the core
• Functional testing around the HTML creation...could be done with just snapshots

Tooling

I'm still not getting everything working properly in my VSCode in regrads to module name resolutions (seems to really have issues with the @jsfe namespace). Maybe it's a Lerna thing...I know that can be fickle. Regardless, it seems that perhaps there are local settings that are allowing this repo to function fine on your machine, but are making it difficult for contributors. Isolating those differences, and fixing the .vscode folder settings, or any other configs, might be a key. A quickstart guide for contributors might go a long way as well.

[JulianCataldo]

Wow. Thanks for your insights! Definitely some valuable ideas here.

For the CSS workflow, user do their choice here, like you did, or like I did for the vendor UI libs widgets. Pure CSS is totally fine. I'm just an old SASS fan :p

No worries for the time you can offer, it's OSS, purely based on volunteering. I'm not asking anything, because I do this by pure passion, I expect that if people want specific stuff, they should invest in a commercial support, or bounties or whatever… ;) But this project is not big enough for that anyway.

I don't have strong opinions on the UI schema side of things, except that I found the RJSF way of things is the most flexible I've found for this kind of libs.

The workspace issue you had doesn't ring a bell for me. It is supposed to work well without much fiddling, thanks to PNPM workspace management. Lerna doesn't have a word on this. It is just used for the publishing process. That's all! Thanks for noticing, I'll try a fresh setup to make contributing easier for new-comers.

[pgoforth]

Yeah, I resolved the workspaces issue by manually installing deps inside each package folder. pnpm does not seem to hoist pacakges like npm does, so making sure all packages had their own deps installed was the key.

Edit: I'm looking through my old schema and I'm seeing some interesting items in my $defs key. I've made a Gist here. High level:

• There is a depends clause that will render or not render fields based on the values of other fields. It's an array of AND clauses nested in an OR array. So for example: "depends": [["name", "fred"], ["name", "bob"]] would evaluate to true if the name field was equal to "fred" or "bob"
• There is a concept of fieldsets as reusable components. In the gist, it's demonstrated in the example as an address block that contains all the fields and logic for addresses in a multitude of countries
• A field is a generic type that can be of a multitude of subtypes (select, password, email, etc.)
• There is a concept of "sections", but I feel like it's out of scope for this library...but I've included it because it was easier than editing the original schema. The idea was that (rather than one large form) you would be required to fill out different sections based on other answers. This kind of logic should be handled outside of this library however.
• Translations were also provided for so that you could associate multiple languages with the defined field "title" and "description". IE. the "title" and "description" would be translation key strings instead of actual words. Again, probably outside the scope of this library, but it's a possibile.

[JulianCataldo]

Never seen this depends feat. of JSON Schema, at least in their modern versions (Draft 4 and newer).

Only https://rjsf-team.github.io/react-jsonschema-form/docs/json-schema/dependencies/ is known to me. Similary, I think definitions is now preferred over $defs.

[pgoforth]

The depends is not a default property, it's a custom property that's defined in the schema to facilitate fields that are dependent on the value of another field.

I'm floating it as an idea for customization beyond JSON Schema that would be appropriate for this product.