Problem/Motivation
Following #3530369: Make components from ancestor themes available I fear we can have performance issue loading all components with specific configuration and choices from UI Patterns.
Components
Components are defined by profile with configuration, should be easy to ensure cache, but first let measure performance impact to know if it's worth it.
Block
With configuration and flatten list, components are loaded the each time the same by Display Builder profile (configuration), entity_type and sometimes bundle:
- Entity view: Each bundle + profile = same components
- Views: Each profile = same components
- Page: Each profile = same components
So we can have 2 + 1 x entity bundle versions of components.
We should ensure they are cached for this context, even provide extra manual cache.
Comments
Comment #2
mogtofu33 commentedComment #3
pdureau commentedIs it something to do on UI Patterns side, in their ComponentPluginManager?
Comment #4
mogtofu33 commentedPerhaps UI patterns side, this to be done after #3529103: Remove Island's specific Form classes and #3529067: Make Island plugins configurable, as configurable islands will impact a lot.
Comment #5
pdureau commentedComment #6
pdureau commentedI move to beta phase because #3529260: Flatten the Fields list (pending ui_patterns 2.0.8) is moving some of the logic from Display Builder to UI Patterns 2.
Comment #7
mogtofu33 commentedBack to alpha as the complexity of the Island is growing.
Comment #8
mogtofu33 commentedComment #9
pdureau commentedOK,and back to "Active" because there is still no commit here.
Comment #10
pdureau commentedComment #11
pdureau commentedComment #12
mogtofu33 commentedComment #13
mogtofu33 commentedComment #14
mogtofu33 commentedComment #15
pdureau commentedComment #16
pdureau commentedThis issue may improve the current situation #3579298: Simpler ComponentLibrary configuration because in a site with 80 components and 120 variants, we are going from 280 draggables max to 120 draggables max. So, way less SortableJS object to track.
Will it make this ticket easier? And/or less relevant?
Comment #17
pdureau commentedDiscussed with Jean (@mogtofu33). Let's postpone this because we don't notice that much slowness nowadays.
Comment #18
mogtofu33 commented