Web-Component or Vanilla JS Binding

Hi,
I’m currently evaluating form libraries and stumbled across jsonforms. I like the architecture with the separation of the bindings and the renderer sets.

The renderer set is a good match as we must use web component based ui components provided by my company.

Our application is fully web component based and we don’t want to include angular based web components for example just for the forms. Therefore, a web-component binding might be the solution.

Can you give me some guidance on how to start a poc for this. What is the bare minimum that I have to implement for a proof-of-concept? For the render set, probably one layout and one component will do. How does this look for the binding? Is there some shortcut for a quick result?

greetings from Switzerland

[original thread by Thomas Scheuchzer]

Hi @scheuchzer(scheuchzer), I think the easiest way is to just bundle a webcomponent out of one of the existing renderer sets. By chance we already do this for our Angular preview of the JSON Forms editor. This is the repo by which we build the jsonforms-angular-webcomponent. You can find the built version in the json forms editor repo and just reuse that for your PoC. This is how we invoke it

At some point we also had a webcomponent version of the React bindings however it’s not maintained at the moment.

[Thomas Scheuchzer]

Thanks @sdirix for the answer. Yes I found that angular-webcomponent project. But what I’d like to prove is that we can make it without adding angular to our stack. Currently, we’re almost bare web-component based, only using lit-element. But it’s certainly a way to poc a custom renderer set.

The Angular webcomponent completely bundles Angular + JSON Forms Angular bindings + JSON Forms Angular Material renderer set within it, so Angular is not exposed in any way to your project. Of course the size is much larger compared to a web component without all these frameworks included.

The bare minimum for a PoC without all these frameworks is to just use @jsonforms/core without any additional framework. However you then need to handle the state management in some way, as the core bundle only gives you utilities to work on your state without including a way to store it. This is usually then handled within the bindings, i.e. React, Angular and Vue. However conceptually this can of course also be done without any framework in pure JS.

If you want to implement a pure Vanilla JS binding + renderer set PoC for your web component you need to implement some small statement functionality accepting Actions.init and Actions.update. Then you can use mapStateToControlProps and mapDispatchToControlProps for a control renderer and mapStateToLayoutProps for a layout renderer. Ideally you should also implement a dispatch-renderer.

[Thomas Scheuchzer]

Is there a reason why json-forms is compiled as common-js module? wouldn’t it be nice to have it as a es module?

[Thomas Scheuchzer]

I’m currently struggling in two situations. First I tried to implement my own binding. There I struggle with the modules. I try to create a ES module and then it complains that the required json-forms classes have not been exported. Bundler plugins that convert common-js into es couldn’t do the trick.
Then I tried with the jsonforms-angular-webcomponent. I’d like to update it to the latest version of json-forms. Unfortunately, this is not working without changes to the code. Angular can’t find JsonFormsAngularService anymore. So I imported in the app.module and added it to the providers list. But then loading still fails because some object with a data attribute is undefined.

There is no specific reason anymore. This is how we set it up a long time ago and works good enough in general so we never changed it. From CRA over Angular CLI to Vue CLI, all of them handle common js modules just fine without special configuration needed. Of course it makes sense that we look at this at some point to see whether we can improve the current state. As backwards compatibility is important, especially for the core, so this might be a JSON Forms 3.X issue.

Then I tried with the jsonforms-angular-webcomponent. I’d like to update it to the latest version of json-forms. Unfortunately, this is not working without changes to the code. Angular can’t find JsonFormsAngularService anymore. So I imported in the app.module and added it to the providers list. But then loading still fails because some object with a data attribute is undefined.

We had some breaking changes with JSON Forms 2.5 for the Angular variant of JSON Forms. Therefore updating the web component also need some changes to the code, but it should be rather straightforward.

Is there a reason you need the latest version of JSON Forms for your PoC? The 2.4.1 version should be good enough I think.

We also have a bundled UMD build of JSON Forms available. It’s located at lib/jsonforms-core.js. Maybe that works better for you?

[Thomas Scheuchzer]

Thanks. I’ll have a try. I just wanted to go away from that Alpha version that is still configured in the web-component example

Ah I see. Usually our alpha versions are pretty stable on their own. The difference to “full” releases is that they did not receive manual testing and new features introduced in them might change before the “full” release, but this is seldom the case. I did not try, but updating the Angular web component to the normal 2.4.1 release should be straightforward.

[Thomas Scheuchzer]

by the way, when using the angular seed following CommonJS warning is shown. Moving away from CommonJS would certainly help.

WARNING in /src/app/app.module.ts depends on '@jsonforms/angular'. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

WARNING in /src/app/app.module.ts depends on '@jsonforms/angular-material'. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

Good point!

I created a ticket #1722 and planned it as one of the next tickets to do.