Syncing json schema with definitions in app-frontend

[olemartinorg]

Description

In the linked pull request I combed through the layout component type definitions in the frontend app, and in the process I noticed a few inconsistencies with the json schema. This PR aims to clean those up.

• For the FileUpload component, the validFileEndings key could also be an array of strings. The frontend supports it, and some layouts already used this instead of a plain string.
• The FileUploadWithTag component and all selectionComponents could also utilize an options mapping. Separated this out to its own type definition for easier re-use.
• The DatePicker component can optionally have its date format defined in the format key. This was missing from the schema, but implemented in frontend and used in several layouts already.
• Groups can have the boolean openByDefault set. This is present in documentation, implemented in frontend, but missing the schema.
• For the panel key as defined inside a Group component, it should be possible (according to frontend code and actual layouts) to define the showIcon key. This was missing in groupPanelOptions but present in panelComponent.
• Image components seem to require all their additional properties in the image key, but this was not explicit in the schema.

Related Issue(s)

• Altinn/app-frontend-react/pull/343

Verification

• [x] Your code builds clean without any errors or warnings
• [x] Manual testing done (required)
• [ ] Relevant automated test added (if you find this hard, leave it and we'll help out)
• [ ] All tests run green

Documentation

• [ ] User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[ivarne]

Have you looked into syncing these automatically? (Designate one as master, and generate the other).

I'm currently hoping to make it possible to dynamically modify the layout files in C#, and for that to work, we would need to have similar typings as C# classes as well (but obviously I got pushback because they would need to be maintained).

I have spent some time looking into this, but have not yet found a perfect solution.

[olemartinorg]

I've generated TypeScript types from JsonSchema before, and it can work sometimes, but I didn't look into doing that this time (one step at a time, I guess). Having separate repositories makes these things a bit worse, I guess.

I remember that part from your presentation, but it just occurred to me now; don't we already generate some data model classes from JsonSchema? Maybe that code can be adapted to generate C# classes from this schema layout? It's been a while since I looked at that code (and I never dove deep into it), but the use-cases might not overlap much.

[ivarne]

I do generate C# classes from json-schema in altinn2-convert see GenerateAltinn3ClassesFromJsonSchema, but I wasn’t very impressed with the results in translating a tagged union to a class hierarchy. I had to use partial classes to make it possible to fix the missing parts manually in separate files.

Maybe better tools exist than what I found. I also use the classes for building and serializing the layouts.

[olemartinorg]

Right, my experience is that as soon as the tool doesn't perform the way you want it to, cleaning up after the tool quickly becomes harder than just writing a highly tailored solution yourself (and/or adjusting the JsonSchema to fit)... The code I was thinking about is in Studio: JsonSchemaToInstanceModelGenerator.cs

[ivarne]

Yea, it’s a tough call. Generating is hard, but when you have many people in the loop with tight deadlines, it’s very likely that we will fail to sync changes manually too.