Mini Cart Block: Move away from using Modal component

[Aljullu]

As per #8452, we want to stop using @wordpress/components in the frontend of our blocks. This PR is about stopping using Modal in the Mini Cart block.

[albarin]

This WIP PR removes the dependency from wordpress-components, I think it makes sense to wait for it, I think it will solve this issue 🤔 @Aljullu

[Aljullu]

Oh, thanks, I wasn't aware about that PR! @kmanijak shouldn't we move away completely from @wordpress/components? #8421 seems to copy @wordpress/components into our repo, is that right? Is that an interim solution or do you plan this as a long-term solution so in practice we 'fork' @wordpress/components?

[kmanijak]

@kmanijak shouldn't we move away completely from @wordpress/components?

Eventually we should, but there are two "factors" that contribute to that:

wordpress-components

As a first step, I wanted to remove the dependency by cherry-picking the components we actually use on the frontend. Let's remember we cannot simply remove the usage, but we still have to replace the components with some alternative. I'm pretty sure it would be time-consuming to reimplement each of these components, so incorporating the code from wordpress-components is a cheap (work-wise) middle step.

Then we can think if and how to replace the components. At the bottom, I attached the map I drew to visualize the internal dependencies for myself (components in rectangles are the ones we have a direct dependency on, but they have internal dependencies between themselves as well). Given that, we would just incorporate a small subset of components (~20) from the whole library. Note that in the PR there are still too many components included.

I'm open to suggestions though - in the particular case of Drawer which is an abstraction to Modal component from wordpress-components we could either:

• use 3rd party library that provides Modal functionality and adapt it so it provides the functionality we need (but that means another dependency)
• reimplement the Modal by ourselves preserving the functionality we use and removing the unused parts,
• take the wordpress-component Modal and include that in our codebase as a single step towards removing the dependency (so atomic step from my PR) 🤔

@wordpress/components

The other part is to remove the unnecessary dependencies on the library (for example through hooks) that get us to include an additional ~700kB because of the externalized dependencies. The #8421 doesn't address this part.

Is that an interim solution or do you plan this as a long-term solution so in practice we 'fork' @wordpress/components?

It's an interim solution for me. As a next step, the components could be re-implemented within WooCommerce Blocks based on @wordpress/components implementation including improvements from newer versions. That would be happening at a slower pace.

wordpress-components dependencies map

[Aljullu]

Thanks for the detailed explanation, @kmanijak! It makes a lot of sense.

I'm open to suggestions though - in the particular case of Drawer which is an abstraction to Modal component from wordpress-components we could either:

• use 3rd party library that provides Modal functionality and adapt it so it provides the functionality we need (but that means another dependency)
• reimplement the Modal by ourselves preserving the functionality we use and removing the unused parts,
• take the wordpress-component Modal and include that in our codebase as a single step towards removing the dependency (so atomic step from my PR) 🤔

Did you think about the best approach for this specific case (the Modal component)? I feel that given that our usage is significantly different from the way modals are used in Gutenberg I would lean towards options 1 and 2 (thus this issue), so we create our own component completely separate from GB's. But I would like to know your thoughts on this. cc @kmanijak @albarin

[kmanijak]

Days ago I would vote for option 3, but that was without much dive into how Mini Cart uses Modal.

After recently taking a look at the Mini Cart layout and checking all the styles, I think it actually makes a lot of sense to re-implement it. Seems like we're not using much of the Modal functionality in Mini Cart anyway (even sliding animation is a Drawer's thing, not Modal's).

Having said that... I think it's worth a try to implement Drawer without Modal (especially since it's only used by Mini Cart) 👍

To be honest, I'd be happy to work on this (but obviously after the Products work)

[Aljullu]

Makes sense. The decision to use Modal was mostly from an a11y point of view, as it brings some things for "free" like moving the focus inside the Mini Cart, keeping it in there, etc. But I guess we could achieve the same without having to use Modal.

To be honest, I'd be happy to work on this (but obviously after the Products work)

Nice! We can leave this as low priority for now so Alba and I focus on other tasks.

[Aljullu]

Heads-up that it looks like if Coblocks is active, the Drawer styles are broken. See #6874 (comment) from @danielwrobert.

Moving away from the Drawer WP component would probably fix that.