Create plugin for client side forms generation

[wtrocki]

We can use uniforms to generate list -> detail page etc

[wtrocki]

Cc @kingsleyzissou

[kingsleyzissou]

@wtrocki, we can maybe have a chat about this tomorrow. but documenting it here too. I started hashing things out, but I've hit a block.

Uniforms uses a bridge between the schema and the auto-generated forms, so we have a couple of options there:

1. Expose the schema to the client and let the client build the bridge for the forms. However, since the schema is being generated from the backend, this seems a bit wasteful.

2. Use the generated schema and build the bridge on the server-side. The issue with this would be how we could expose the bridge to the client.

3. Try build our own thing without Uniforms, but that seems like a lot of work.

[wtrocki]

Uniforms works with GraphQL schema types but it will also work with input types. Exposing specific input types to client is inevitable if we are choosing GraphQL to represent client side UI definition. Most of the competitors putting entire schema introspection to the client and use it to generate code so there is nothing wrong with that.

In our case we might to actually generate more rich JSON schema format etc. Using JSON schema will be not only much better in terms of performance and scalability but also we can use existing db annotations like length of the string or transformations for GraphQL scalar validation.

Doing this will also enable different frameworks like angular- there are tons of the forms generators for JSON schema for every framework.

Ad 1. We ideally need to expose chunks of schema for models that have specific annotation. Master detail view with create delete and edits. Compiling schema on client is heavy. Most of the prod apps will have server schema in compiled form on client.

Ad 2. Uniforms work best with compiled schema we can represent schema as GraphQL objects. Every server already expose introspection in non production mode

Ad 3. How about master detail page. Does it makes sense? Do we have libraries for this? It seems like there are some universal libs that do listviews etc. If we pick right format we can represent data in preview and editable form.

TL;DR I think that we can have simple plugin that will generate UI representation - Not 100% convinced that GraphQL schema is good for that as it is missing any constraints apart from NotNull.

Biggest decision here is to figure out what we covering - just representation in plugin and them use it with some library like uniforms in the template.

Do we need to cover list, detail view( This could become some poor admin panel solution). I would ask around some of the client app Devs to see what level of assistance they need and then come back with some conclusion

[wtrocki]

Looking for feedback @troZee @ardatan Do you see benefits from generated List -> Detail -> Edit views for React/RN or there is no value in this and simple JSON schema with formik forms in template will work

FYI @cristianonicolai - if graphback generate UI from GraphQL schemas would Kogito benefit from it? If yes then what is your preference for format for forms metadata?

[cristianonicolai]

@wtrocki possibly yes, although we were looking into creating a JSON schema out of POJOs. JSON schema seems to be supported by quite a few client frameworks, that would be our first try at this stage.

[wtrocki]

Ok. This confirms that JSON schema is the way to go then.

[troZee]

Generating forms based on schema would be hard, because it has lot of constraints. The library must be flexible for dev. Some of them can use different UI libraries/styles and it would be hard, to create some kind of adapter for all of them. There are also differences between frameworks like react and react native (business logic would be the same, but different JSX).

From my perspective it is better to implement forms on my own, because I can easily customize all requirements, which has been provided by business.

Also what in case, when someone use different solution than uniforms ? like formik, own implementation, own form lib ?

[wtrocki]

I have been chatting with couple devs and got some feedback:

1) master detail as framework do not make sense. It could be just as some reference implementation or template. With that in mind we already have master detail in datasync-starter that needs work on pagination and good patterns. It should be easy to replicate this to any framework or css styles after inspecting code.

2) Generation of forms that is generic is deemed to fail or not provide much value. There are so many frameworks, style libraries or even approaches for web. It is hard to provide useful abstraction layer on top of frameworks like uniforms.

3) Generating master detail views to hide complexity of the api is poor workaround for badly designed or overly complicated api. Api should be simplified first. This means we can do offix codegen or even move offix from cache to db/local state based storage.

4) Having optiniated forms approach is still benefitial. We could create uniforms plugin that will generate required code including engine. Challenge here is that our ecosystem is strongly tied to ReactNative and Ionic. While there is no issue to use uniforms with RN, Ionic will require contribution to uniforms as it needs to use ion-x components

Ideally people will simply build some sample app with some tech and blog post about it. For example topic could be something like "Offline Ionic apps with Graphback and Keycloak" "Writing your Gatsby website with Graphback, Keycloak and Offix"

This will provide much more value to users and also will help people to find some solutions for their needs.

[wtrocki]

Update: We have decided to give it a go and come up with auto-generation of forms using Uniforms. This will involve the creation of the AutoForm that will support:

• Ionic
• Patternfly

CC @radekmie

[radekmie]

A bit late, but here are my two cents:

• GraphQL schema is enough to render a form that will pass the GraphQL validation. The thing is that in most cases we do use an additional layer of validation to express business logic. Some simple ones like min/max string length, matching a regex or min/max value can be easily encoded within the GraphQL schema (using directives). The problem is that there's a lot of other rules (like x + y > z or x xor y) that are common and very non-local (include multiple values or have no clear source of the problem). In that case, using JSON schema is great, as it's still very simple (and serializable!) yet so expressive.
• uniforms (not Uniforms!) is a very flexible library, and a field doesn't have to be field per se - any component will do. This allows designing any kind of crazy designs in the schema, without touching JSX at all. It may not be the best choice because the schema may get big, but this possibility means that you can combine any kind of meta information you have (GraphQL schema, GraphQL directives, other annotations, configuration objects or even custom code) into a valid schema with its layout.
• You can think about uniforms in a plug'n'play way, as every AutoForm will use its children if defined - automatically generated content is just a fallback (in a way). The main goal here is to wire the logic (schema, validation) and keep the UI separated (JSX, schema or both).

If you'll have any questions or problems with uniforms, feel free to ping me (just like you did), use our Gitter or create an issue.

[kingsleyzissou]

Closing this issue.

We won't be building a package/plugin to generate JSON schema to be used with a uniforms bridge, since this is easy to implement already.

I have built two uniforms packages for our needs, one for patternfly and one for ionic.

They can be found here:

• https://github.com/kingsleyzissou/uniforms-patternfly
• https://github.com/kingsleyzissou/uniforms-ionic