New component: Grid

[olemartinorg]

Description

After a refinement meeting for #107, we found that some specific of the needs can be isolated into a separate (new) studio/app-frontend layout component: Grid (see my comment in #543).

Example:

Functional requirements

• The component should be displayed using the same design system components as New component: List #578 and Repeating groups: Replace table with components from design system #580
• The configuration for the number of rows/columns in this component should be static, i.e. when configured to show a 5x7 grid (5 columns, 7 rows), it is not possible for the user to add more rows/columns.
• Each cell in this Grid should have place for exactly 0 or 1 components. (See Repeating groups: Components in table #579 for the same implementation in the repeating groups table).
• This component has no affiliation with the data model. It is only a way to visually structure multiple components in a grid. Each of these components are expected to have their data model bindings as flat bindings (no extra complexity for looking up inside arrays according to which row in the grid the component renders in).
• Some extra configuration for a row might be needed, such as coloring it as read-only (as in the screenshot from figma above). Take care to re-use as much of the column-configuration from other table-like components as possible (see New component: List #578 and repeating groups).
• Requirements from Oppstilling av statiske enkeltfelter i datamodell slik at de fremstår som tabell i GUI #298

Additional Information

• Oppstilling av statiske enkeltfelter i datamodell slik at de fremstår som tabell i GUI #298 (duplicate - all discussion here should be considered as well)
• Design: Tables #107 (includes link to figma designs)
• Technical analysis table app frontend #543

[rvessb]

org/ssb

[ivarne]

org/krt (finanstilsynet)

[olemartinorg]

We discussed this a bit during the sprint planning earlier today. Some questions came up. It seems like this task is ready for someone to start working on it, but some specifics are not entirely decided on yet.

So, regarding how to define this in the layout JSON files: Should we support multiple components inside a single cell? Maybe not now, but it might be needed later. In that case, we'll need designs for how that should look (and how two input fields should be differentiated). I suggest that we only support one field per cell for now (and only simple components in them, so no support for the AddressComponent, for example).

The other question was regarding how to reference the components that should live inside the cells. The way I see it, we have two alternatives; we either keep on doing the same thing as it's been done in (repeating) groups, by referencing children externally:

[
  {
    "id": "myGroup",
    "type": "Group",
    "children": ["myComponent1", "myComponent2"]
  },
  {
    "id": "myComponent1",
    "type": "Input"
  },
  {
    "id": "myComponent2",
    "type": "Input"
  },
]

But for a Grid, we'll need a two-dimensional way of referencing children:

{
  "id": "myGrid",
  "type": "Grid",
  "rows": [
    ["myFirstRowComponent1", "myFirstRowComponent2"],
    ["mySecondRowComponent1", "mySecondRowComponent2"]
  ]
}

When thinking more about it:

1. We'd probably need some way to indicate that a cell (or an entire row/column?) should contain headers, or if a row should be readOnly (i.e. be yellow).
2. It'd be nice not having to reference a Header or Paragraph component in order to just display some text (so, have a shortcut for that).
3. It could also be nice not having to reference a child, but defining it directly in the configuration.

All in all, we should take care to find a configuration format that everyone can live with (and still supports our other functionality, like dynamics/expressions, calculation, validation, etc) without too much hassle. We should probably also talk to Team Studio when deciding on a format for this configuration, so we find something they're happy with implementing in Studio.

[ivarne]

• Inlining instead of referencing children would be great (but then we would need to change Group to accept direct children as well for consistensy).
• Another option to avoid nested lists, would be to have a required property numColumns, so that you can just have a list of children, and break it into the desired number of columns on display.

{
  "id": "myGrid",
  "type": "Grid",
  "numColumns": 2
  "rows": [
    "myFirstRowComponent1",
    "myFirstRowComponent2",
    "mySecondRowComponent1",
    "mySecondRowComponent2"
  ]
}

[olemartinorg]

• Inlining in Group is harder, as that would require support in Studio as well. We can get away with doing pretty much whatever we want here, as the Grid component doesn't have support in Studio yet. Also, we'd have to find a different way to support multiPage if inlining components in Group. Even though I'd love to find a better solution for that mess, I think inlining Group would have to be a separate task.
• Thanks for the numColumns alternative! I personally find that I much prefer other representations, but I guess this is a contender as well.
• Yet another alternative is to have each row be an object (with relevant options like header and readOnly), and then have each component reference as an object as well (which can also be other types, like lightweight text references instead of full-blown components):

{
  "id": "myGrid",
  "type": "Grid",
  "rows": [
    {
      "header": true,
      "cells": [
        {"text": "My header text"},
        {"component": "myFirstRowComponent1"}
      ]
    },
    { "cells": [
      {"text": "my.text.key"},
      {"component": "mySecondRowComponent1"}
    ]},
    {
      "readOnly": true,
      "cells": [
        {"text": "texts.sum"},
        {"text": ["sum",
          ["component", "myFirstRowComponent1"],
          ["component", "mySecondRowComponent1"]
        ]}
      ]
    }
  ]
}

[FinnurO]

Eksempel fra SSB

[ivarne]

We probably need some way to support colspan and rowspan also. That might talk in favor of a more verbose grid layout than a simple list and numCols

[nkylstad]

From a studio perspective, the formats discussed here seem like ok alternatives to implement. If there is a need for a lot of configuration on the row level, then the verbose format where each row is an object seems like the best solution.

Restricting the components that can be used inside a table cell to basic form components seems like a good idea, we want to avoid things like nested tables 😅

Do we need settings on a row level, or should these be part of the cell object? Or both?

[olemartinorg]

@nkylstad Thanks for feedback! 🥳 I'm currently working on the assumption that we'll allow some row-level configuration AND cell-level configuration. That means, you could set rows[0].cells[0].readOnly = true if you'd like, or the whole row by setting rows[0].readOnly = true (which would override the setting for every cell in that row).

For now, we have defined the following typescript types:

export interface GridCellOptions {
  header?: boolean;
  readOnly?: boolean;
}

export interface GridComponentRef extends GridCellOptions {
  component: string;
}

export interface GridText extends GridCellOptions {
  text: ExprVal.String;
}

export type GridCell<C = GridComponentRef> = C | GridText | null;

export interface GridRow<C = GridComponentRef> extends GridCellOptions {
  cells: GridCell<C>[];
}

export interface ILayoutCompGrid<C = GridComponentRef> extends ILayoutCompBase<'Grid'> {
  rows: GridRow<C>[];
}

So, every option in GridCellOptions is also possible to set on GridRow.

[TomasEng]

I am fine with most of the suggestions here. If the components are not going to be referenced outside of the table, I am in favor of inlining the cell configuration directly. Has there been any discussion on how to support summing of cells? Should we support other aggregate functions (average etc.) as well? I don't find the array syntax in the example quite intuitive. Could we do something like this instead?

{
  "cells": [
    {
      "function": {
        "name": "sum",
        "args": [ ... ]
      }
    }
  ]
}

[olemartinorg]

@TomasEng We're not aiming for inlining of components in the first implementation. We might go there later (then also for groups), but right now most legacy code in app-frontend would not support it, so we'd have to do some major cleanup first.

Also, sum/average is not really functionality we're supporting in this component, as it's already implemented in single fields by use of calculation (either backend or frontend). We have no explicit support for neither sum or average there, as the exact logic is something the application developers need to decide upon, and implement.

The syntax you describe above looks a lot like what we discussed when developing dynamic expressions, although we arrived at a bit simpler where the expression is an array where the function name comes first and is followed by arguments, so ["sum", ...]. Currently, support for calculation using dynamic expressions is described in #646, but will be separated out to its own issue when time comes for that.

[TomasEng]

@olemartinorg, okay, so functions are out of scope of this task, I see. Then I have no more objections 🙂