feat: add categorization renderer to Vue Vanilla

[davewwww]

Regarding issue: #1719

there is still a bug that the label with i18n is empty if no translation was found. i have used the deriveLabelForUISchemaElement() - is that the correct function to translate such labels?

[netlify]

✅ Deploy Preview for jsonforms-examples ready!

Name	Link
🔨 Latest commit	7a94642
🔍 Latest deploy log	https://app.netlify.com/sites/jsonforms-examples/deploys/65d61db70097760008dd9d42
😎 Deploy Preview	https://deploy-preview-2270--jsonforms-examples.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[sdirix]

Hi @davewwww, Thanks again for another contribution ❤️ We will take a look soon!

[coveralls]

coverage: 84.861%. remained the same
when pulling 7a94642 on davewwww:feat/categorization-renderer
into 51b63f5 on eclipsesource:master.

[lucas-koehler]

Hi @davewwww , thanks again for this contribution. Generally, we'd like to have a categorization and a stepper renderer :) However, I'd prefer if they could be split up into two separate renderers, i.e a CategorizationRenderer and a CategorizationStepper renderer.
This way the code of each one is easier, they can be extended individually in the future, and it's easier for others to use them as templates for custom renderer. What do you think?

Testing this in the PR's example preview , I noticed that the labels of the categories/steps seem not correctly resolved. Could you have a look?

[davewwww]

Hi @davewwww , thanks again for this contribution. Generally, we'd like to have a categorization and a stepper renderer :) However, I'd prefer if they could be split up into two separate renderers, i.e a CategorizationRenderer and a CategorizationStepper renderer. This way the code of each one is easier, they can be extended individually in the future, and it's easier for others to use them as templates for custom renderer. What do you think?

sure.

Testing this in the PR's example preview , I noticed that the labels of the categories/steps seem not correctly resolved. Could you have a look?

yes, i've noticed that too. i use the deriveLabelForUISchemaElement() method for this. the particular category uischema has a i18n but no label attribute and i think the following code creates a undefined return value instead of returning the plain i18n key.

  const stringifiedLabel =
    typeof uischema.label === 'string'
      ? uischema.label
      : JSON.stringify(uischema.label);

any idea?

[davewwww]

hi @lucas-koehler,

I have reworked the renderers and created the useJsonFormsCategorization() function to generated the category items and within i call useControl(categoryProps, mapStateToLayoutProps) and there is the same behavior regarding the unlabeled buttons.

now i don't know if this is a bug or if the behavior is intentional and "only" the example is not configured correctly.

[lucas-koehler]

Hi @davewwww , thanks for the rework and your ongoing efforts! The new structure is much better IMO :)

Could you move the two new renderers to the layouts instead of the complex folder, please? I have some further comments inline. Please have a look.

now i don't know if this is a bug or if the behavior is intentional and "only" the example is not configured correctly.

I investigated this a bit and found the following: If there is a label property, it is resolved as i18n and if nothing is found it's put out as is. If however, the same happens for an i18n prop, nothing is returned as you already noticed. I think that is fine behavior but arguably it would be easier to find missing translations if the keys are put out. If you'd like you can raise an issue for that but I do not think the behavior should be touched as part of this PR.

Furthermore, I found out that the vue-vanilla example app indeed configures i18n for the examples differently than the other renderer sets. Namely, it does not use the i18n configured in the examples but configures its own based on the I18n translations text field.

If you change packages/vue-vanilla/dev/components/App.vue like the following, the i18n is used from the examples until the I18n translations text field contains a parsable i18n config

diff --git a/packages/vue-vanilla/dev/components/App.vue b/packages/vue-vanilla/dev/components/App.vue
index f734171e..d063c8b0 100644
--- a/packages/vue-vanilla/dev/components/App.vue
+++ b/packages/vue-vanilla/dev/components/App.vue
@@ -3,7 +3,6 @@ import { defineComponent } from 'vue';
 import { JsonForms, JsonFormsChangeEvent } from '../../config/jsonforms';
 import { vanillaRenderers, mergeStyles, defaultStyles } from '../../src';
 import '../../vanilla.css';
-import { JsonFormsI18nState } from '@jsonforms/core';
 import { ErrorObject } from 'ajv';
 
 import { getExamples } from '../../../examples';
@@ -27,14 +26,13 @@ export default defineComponent({
     };
   },
   data: function () {
-    const i18n: Partial<JsonFormsI18nState> = { locale: 'en' };
     const additionalErrors: ErrorObject[] = [];
     return {
       data: {},
       renderers: Object.freeze(vanillaRenderers),
       currentExampleName: examples[0].name,
       examples,
-      i18n,
+      i18n: examples[0].i18n,
       additionalErrors,
     };
   },
@@ -141,7 +139,7 @@ export default defineComponent({
           :uischema="example.uischema"
           :renderers="renderers"
           :config="config"
-          :i18n="i18n"
+          :i18n="example.i18n"
           :additional-errors="additionalErrors"
           @change="onChange"
         >

[lucas-koehler]

Thanks for the updates @davewwww . The PR LGTM now ✨
In the latest commit pushed by me I only moved the tests to fit the renderers being moved to the layout folder.