feat: Add table component to viewer

[vsgoulart]

I was having some issues with the tests, I'll add them tomorrow morning

Closes #892

• This PR adds a new form-js element or visually changes an existing component.
  • => In that case, we need to ensure we follow up on this, e.g. by creating an issue in Tasklist

[Skaiir]

Before I start looking into the code, just a few first impressions / remarks on my side. I checked the parent issue, after this PR there's carbonization but I guess you're still planning to change non-carbon styles as well a bit? Anyways there's a few style issues but I won't discuss them for now assuming the above.

---

Adding tables pollutes the input data:

This section shouldn't be programmatically updated as a side effect of adding a component. I guess this is probably related to the way we add the sample data. I also have some reservations about that but we'll discuss on the full PR.

---

Pagination by default is quite a lot right out of the gates:

Very visually complex, do we really need to introduce pagination immediately to our users? Especially with a height of 1 which makes it:

• Not a reasonable default, meaning it's a property everyone will have to modify to get a "standard" behavior
• Not the default you usually get from toggling pagination, leading to these kinds of interactions where toggling the checkbox actually changes things

The that second point, I think we could also just keep the page size in the schema, up for debate.

---

Keys and data-sources should probably not be overlappable

Binding a key to the same path as the dataSource destroys the data and hence leads to the table showing nothing. This is normal sanitation behavior though. So at the very least they should be exclusive.

---

Data-sources bypass groups paths

This is kind of an interesting one. Because the way we've gone about this is, text path definitions stack with eachother, but feel expressions require using of 'this' keyword to access the local scope (they default to the root). Should we copy the model here? I'm not sure.

---

Drag and drop is compressed on small screens

The minimum width makes things difficult when it comes to having two items side by side:

[pinussilvestrus]

This section shouldn't be programmatically updated as a side effect of adding a component. I guess this is probably related to the way we add the sample data. I also have some reservations about that but we'll discuss on the full PR.

I think the demo data makes sense with the rationale provided via #905. What makes it a bit clumsy is the fact you will likely update the dataSource after first create, which needs another update in the data editor everytime.

[vsgoulart]

I also have some reservations about that but we'll discuss on the full PR.

@Skaiir I split this task into smaller PRs, everything is merged into 888-table-component, so this is the last big PR we'll have for epic. After the canonization we can just merge the feature branch into develop since everything is already reviewed

but I guess you're still planning to change non-carbon styles as well a bit? Anyways there's a few style issues but I won't discuss them for now assuming the above.

Yeah, I'll create a separate last PR for that

This section shouldn't be programmatically updated as a side effect of adding a component. I guess this is probably related to the way we add the sample data.

This was agreed on the define phase. As @pinussilvestrus mentioned the goal is to provide some data to render so the user isn't completely lost when adding a new table into the schema, this will probably be immediately edited out when modelling it and I don't believe users will add too many tables too. Anyway, it's too late to not go with it now, we have iterate over it when we have user feedback.

Very visually complex, do we really need to introduce pagination immediately to our users? Especially with a height of 1 which makes it:
Not a reasonable default, meaning it's a property everyone will have to modify to get a "standard" behavior
Not the default you usually get from toggling pagination, leading to these kinds of interactions where toggling the checkbox actually changes things

The default is 10 rows (it was 1 originally because it was the value I was using for testing). The pagination buttons will also only be visible if there's more than 1 page.
Having pagination is basically the whole purpose of having the table component, because otherwise the form would be giant and the user would have to scroll all the way down to complete the form. (Another option would be limiting the height and having a vertical scroll, but we decided this is a bad UX because we would have a scroll area inside of a scroll area)

The other points are bugs, I'll fix them tomorrow

[Skaiir]

The default is 10 rows (it was 1 originally because it was the value I was using for testing). The pagination buttons will also only be visible if there's more than 1 page.

Yeah this was also a bug right? That's fine, we can have the table paginated by default I just mean we don't need to visually show them pagination in action the moment they open the table. But I see you fixed that.

---

This was agreed on the define phase. As @pinussilvestrus mentioned the goal is to provide some data to render so the user isn't completely lost when adding a new table into the schema, this will probably be immediately edited out when modelling it and I don't believe users will add too many tables too. Anyway, it's too late to not go with it now, we have iterate over it when we have user feedback.

On the basis that we don't have a better alternative right now, we can do this. I mean we'll most likely overhaul input and output data pretty soon so it's not going to be a problem for too long. Maybe we'll have requests for statically defined tables (who knows) and then we can use that for the defaulting.

In general though, I dislike this because it's a unique behavior to tables, it goes against "no surprises" entirely, and while convenient maybe for the first 1 or 2 times you add a table, becomes visual noise the moment you understand how they work. I'm not against generating some sample data but the way I see it, it should be an extra action. But yeah let's wait on feedback.

---

Another thing that's a bit inconsistent, the values displayed in the editor aren't matching those of the viewer, which is new:

Usually we have no values at all, but this is also not great:

I think we need to agree on some visual language practices for elements which are populated through a source. Something like the skeletons in carbon would work well I think. We can take this on as a follow-up. @volodymyr-melnykc If you have any opinions there, feel free to chime in.

[volodymyr-melnykc]

Another thing that's a bit inconsistent, the values displayed in the editor aren't matching those of the viewer, which is new:

@Skaiir @vsgoulart I see what's the issue. What we can do is show generic content for a table in the Form Definition, even for the sample data.
Meaning instead of showing columns "Id", "Name" and "Address", have generic "Column 1", "Column 2", "Column 3".
The actual table content is to be shown only in the Form Preview.

---

Usually we have no values at all, but this is also not great:

I think we need to agree on some visual language practices for elements which are populated through a source. Something like the skeletons in carbon would work well I think.

In the long term, it would be really good to merge these 2 views (Form Definition and Form Preview) into one, from where the user can edit and preview a form at the same time. We also got several user requests for this.

[volodymyr-melnykc]

@vsgoulart @Skaiir After testing the feature for a bit longer, I'd suggest a few improvements for table columns and rows preview on the canvas.

• If a table header source is static (the type is List of items), the header columns in both Form Definition and Form Preview canvases should reflect the user's input. Keeping the table headers up-to-date in the Form Definition canvas helps the user relate to what the table is about.
  • Currently, when changing a header name from the Properties panel, it's reflected in the Form Preview (correct) but not in the Form Definition (not correct).

--

• If a table header source is dynamic - coming from an expression, then show generic column header names in the Form Definition canvas:

--

• Since the table content comes from variables, previewing the content in rows in the Form Definition canvas can always be generic, even for the sample data. E.g.:

It's also related to the issue that @Skaiir brought up earlier:

Another thing that's a bit inconsistent, the values displayed in the editor aren't matching those of the viewer, which is new:

cc @christian-konrad

[Skaiir]

In the long term, it would be really good to merge these 2 views (Form Definition and Form Preview) into one, from where the user can edit and preview a form at the same time. We also got several user requests for this.

Well they aren't the same views so we can't exactly merge them, however something pretty close to that would be to have a single panel with an easily accessible toggle (both via keyboard and UI) between edit mode and view mode. This is pretty common in a lot of modeling tools.

So it's less about changing how things work and more about just shifting the UI around to have more space to work with. The only thing that is unclear there is where the input/output data should be going, but we can have some chats and wireframes on this.

[Skaiir]

Few review comments, nothing major though, nice work.

[volodymyr-melnykc]

@vsgoulart The latest update looks great! 🚀

I have a minor comment regarding the visual layout.
Can we add vertical spacing between the label and table? Currently, it's 0, to be 4px (e.g. via "row-gap").

[vsgoulart]

@volodymyr-melnykc done

[Skaiir]

Nice work :)