New Admin UI - Grid / Column Components

[adrians5j]

This PR introduces the Grid / Cell components.

Extra Changes

1. Elevation Fix

Found an issue with the Elevation component (not able to receive custom CSS class). Resolved now.

2. svg HTML Element Displayed As Block

This is not a change, but a discovery. I've discovered Tailwind's preflight makes all svg HTML tags display as blocks by default. Which previously was not the case, and now, for example, in the dashboard, you can noticed icons in the bottom-right being aligned to the left, and not to center. For now did not do anything, just wrote it down in GH project as a reminder.

[github-actions]

Cypress E2E tests have been initiated (for more information, click here). ✨

[adrians5j]

Couple of comments...

1. Not sure if Switch TS issue was addressed @leopuleo ? I have a feeling I saw it being addressed by you, but don't know anything anymore. 😆

2. Do we want to be able to create responsive grids? Like for example, show 12-columns-grid in wide screen, and 1-column-grid on a small screen?

[adrians5j]

Re number 2... I would've already done it... but I'm actually having some trouble with the API design and the underlying implementation. I've seen that some libs have the following approach when it comes to responsive grids:

// 12 columns for all screen sizes.
<Grid columns={12}>...</Grid> 

// Use 12 columns for all sizes, except small screens, where we use 1.
<Grid columns={{ initial: 12, sm: 1 }}>...</Grid> 

But now.... the only thing that then becomes a bit complicated here is class generation with cva. Basically the lib only allows us to assign POJO when defining a variant, like:

   columns: {
            1: "grid-cols-1",
            2: "grid-cols-2",
            3: "grid-cols-3",
            4: "grid-cols-4",
            5: "grid-cols-5",
            6: "grid-cols-6",
            7: "grid-cols-7",
            8: "grid-cols-8",
            9: "grid-cols-9",
            10: "grid-cols-10",
            11: "grid-cols-11",
            12: "grid-cols-12"
        },

Looks to me we'd need to handle the above {{ initial: 12, sm: 1 }} proposal without cva. But even by doing that, still not sure how to deal with all of the TW classnames. I mean, they would still need to be listed somewhere as strings, so that they are all included in the CSS bundle ultimately.

Maybe we need a different API here? 🤔

Or maybe we don't even need the Grid component at all, but we use it just for old Admin UI? And we simply use TW classes directly? Not sure all in all.

[adrians5j]

An update on grid vs. flex (there are still other items to resolve in this PR btw, this is not the last one):

So I tried using flex, and here's my observation.

Before I start, here are the results I've achieved:

Also, for reference, old sshot showing the same thing done with regular grid (current implementation in this PR):

So, what I've found is that the flex-version of the grid was not that great. The first version of the code produced the following result:

As we can see, the result is nowhere near the desired output. This is not only because the existing @webiny/ui package's Grid/Col components are also using grid instead of flexbox, but also, because this dashboard code uses the Grid component and inside of it, just contains multiple columns, that are spanning across 24columns in total. And then, they are broken into 2 rows, that's why it looks like a grid.

Check this code here to get the full picture, I may not have explained it well:

webiny-js/packages/app-admin-rmwc/src/modules/Dashboard/Welcome.tsx

Line 179 in 1d1b872

<SimpleFormFooter>

Ultimately, a bit of code shuffling was needed to get the desired result. Basically, I needed to ensure that each row consists of 12 columns. If the row has more than 12 columns, then it should be broken into multiple rows.

Once I did that, I receive the following:

As we can see, that's better. Still, there will be a lot of views that will need to get refactored. For example, I just opened 'new content model' dialog:

With the grid-approach (code in this PR):

One other thing I noticed is how gap affects the layout. Here's the same layout with a gap set to 12, with the grid approach:

And here's the same with flex approach:

As we can see, with flex approach, we receive a horizontal scrollbar, because it looks like the gap making the columns wider than the container. This is not the case with the grid approach. So, this is something to keep in mind.

In both cases, I've tried different things, like shrink and flex-wrap, but could not get it to work.

In any case, didn't want to move in any approach before we both agree. If you ask me, I'd just continue with the initial grid approach, and move on. We can always address this later, if needed.

[adrians5j]

BTW some other items I have on the list are...

1. Remove columns from the main Grid component. With this initial version, we keep it at 12 always.
2. Check offseting.
3. Ignore responsive, we just do one mode.

[adrians5j]

Alright, let's try to review this one again. Note that here is some context on why still using grid/col, instead of flex.

[leopuleo]

/storybook

[github-actions]

🚀 Storybook Preview
You can preview the Storybook by visiting the link below:

Storybook Preview URL

[leopuleo]

Thank you, Adrian. I left some “cosmetics” comments, but overall, the PR is an excellent starting point.

[leopuleo]

What do you think about using <Column /> instead? I understand it's mainly a cosmetic choice.

[leopuleo]

I would not manage the outer <Grid /> spacing with padding; it should extend across the full width of its container.

Therefore, I believe we should create a <Container /> component or something similar that manages the spacing and positioning of its children within the viewport.

Its usage would be the following:

<Container> // it contains, pads and optionally centers the content.
  <Grid> // it contains colums.
    <Column>Column 1</Column>
    <Column>Column 2</Column>
  </Grid>
</Container>

[adrians5j]

I went over your comments, all sounds good. Thanks @leopuleo!

[adrians5j]

I was thinking merging this, and working on the Container via a separate PR.

Because there are a couple of things I need to check actually.
One is TW's own container feature.
The 2nd one is the general design of the Container props / API (it's gonna be simple ofc, prolly just one or two props).

Finally... I think we'll also want this be 1-1 with the DS. In other words, our DS should also have a separate Container page.

Started working on the Container right in this branch.. but after a bit, I think separate PR is easier.