-
Story
-
Resolution: Done
-
Critical
-
None
-
None
-
8
-
False
-
None
-
False
-
-
-
HAC Infra OCP - Sprint 246, HAC Infra OCP - Sprint 248
Once PR #12983 gets merged, Console application itself will use PatternFly v5 while also providing following PatternFly v4 packages as shared modules to existing dynamic plugins:
- @patternfly/react-core
- @patternfly/react-table
- @patternfly/quickstarts
Above mentioned PR will allow dynamic plugins to bring in their own PatternFly code if the relevant Console provided shared modules (v4) are not sufficient.
Let's say we have a dynamic plugin that uses PatternFly v5 - since Console only provides v4 implementations of above shared modules, the plugin would bring in the whole v5 package(s) listed above.
There are two main issues here:
1. CSS consistency
- Console application should be responsible for loading all PatternFly CSS, including older versions (like v4) for use with existing plugins.
- Plugins should not bring in their own PatternFly CSS in order to avoid styling related bugs.
2. Optimal code sharing
- Treating entire PatternFly packages as shared modules yields very big JS chunks, which means more data to load over the network and evaluate in the browser.
- Instead of per-package, PatternFly v5 code should be federated per-component.
This story should address both issues mentioned above.
Acceptance criteria:
- webpack generated Console plugin does not bundle PatternFly CSS
- webpack generated Console plugin treats individual PatternFly v5 components as shared modules