Is the table-mode a possibility?

[matheo]

dyn-form support any kind of mode that we configure.
It will just refresh the DynControl factories any time we change it with new configuration overrides.

We can have a RADIO control in the edit mode but change it to INPUT in display mode, as the simple-form demo shows.

However, thinking about all the possibilities that we have with this Dynamic Forms library,
we could be able to build tables, and implement some inline editing of then, in a custom implementation of the config, let's say another package like @myndpm/dyn-tables with a specificly typed config.

Is it worth to play with ng-templates and create columns dynamically while we also support inline cell-edition?
it just sounds good and maybe it's not worth?

[adam-dorin]

Taking a look at the demo you linked + taking into consideration the question here is some ideas to bounce around:

1. I think ng-templates and a dynamic form is a bit much to aim from the first implementation ( but that could be just me :) )
2. In the demo the configuration is slightly confusing to me

 createMatConfig('RADIO', /*top level is RADIO*/{
        name: 'account',
        params: {
          options: [
            { text: 'Create Account', value: 'CREATE' },
            { text: 'Checkout as a Guest', value: 'GUEST' },
          ],
        },
        modes: {
          display: {
            control: 'INPUT', /* nested another type is defined for some sort of modes that the form will be in*/
            params: {
              getValue: (params: DynMatRadioParams, value: string) => {
                const option = params.options.find(o => o.value === value);
                return value && option ? option.text : value;
              },
            },
          },
        },
      })

My suggestion would be since there is some consideration towards the visibility of an element to perhaps consider some sort of isVisible computed property

 
 enum MODES = {
    EDIT = 'EDIT',
    DISPLAY = 'DISPLAY',
  }
createMatConfig('RADIO', {
        name: 'account',
        isVisible: (mode)=>mode===MODES.EDIT //  is called with the current state of the form
        params: {
          options: [
            { text: 'Create Account', value: 'CREATE' },
            { text: 'Checkout as a Guest', value: 'GUEST' },
          ],
        }
      })
createMatConfig('INPUT', {
         name: 'account',
         isVisible: (mode)=>mode===MODES.DISPLAY //  is called with the current state of the form
      })

[matheo]

Interesting, I didn't expect it to be confusing but it is indeed :P

the modes work as a sort of config-overrides, so my idea was to reuse the existing params and maybe add them some others depending on the "context" (mode). There are global overrides too, the display mode adds the readonly: true param for all the controls with this part:

modeParams: {
  display: { readonly: true },
},

maybe renaming the field to modeOverrides avoid the confusion a bit, but mainly the intent is to reuse the field config. IMO we need to implement the isVisible with some business-logic conditions instead, not having to worry with form stuff there. WDYT?

Technically speaking, the dyn-factory component is the one that detects the mode-change$ and compute a new config, dynamically loading a new control (if it changes), or updating the params to the existing instance. It keeps the responsability of the account field in a single place, and we won't need n*m redundant stuff for n fields and m modes :)

And about the table-mode, I've been thinking the ways we could extend this dyn-forms package with further ones like dyn-table. Considering this right now, helps to structure the dynamic-form better, like the support for having the same dynamic-form in multiple (stepper) routes, that is supported right now thanks to the ControlContainer implementation.

IMHO this kind of ideas/experiments allows to test the base architecture, detecting rigid points.