Performance: On-demand lazy-loading source selector

Created on 3 June 2025, 4 days ago

Problem/Motivation

ComponentForm has 2 issues:

  • it is complicated UX
  • it is sometimes slow

They are already addressed:

But there is another change we can do which will help on both subjects.

Proposed resolution

Today, when we load ComponentForm, the source selectors are populated for every props and slots, even if we will not edit them before saving the config.

Those selects are costly to build because we check source plugin availability and context matching for all of them.

Proposal: instead of populating the selects like today:

Let's generate a button with the selected/default source as a value:

πŸ“Œ Task
Status

Active

Version

2.0

Component

Code

Created by

πŸ‡«πŸ‡·France pdureau Paris

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @pdureau
  • πŸ‡«πŸ‡·France pdureau Paris
  • πŸ‡«πŸ‡·France goz

    It's a performance solution, but, in my opinion, a bad thing for UX.
    The idea is still great, may be we can find something to solve UX.

    UX issue:
    It's a button, we are not used to have a button in a form to display a select list / other options to configure switch a field. If i saw this button, i will don't know why it's here and what is its purpose. It's not intuitive.

    Proposal:
    1/ May be we could add some things with this button so we understand it's a default source and we can change it. May be adding an arrow inside the button, at right like a select list does ?
    2/ Be more verbose, with text AND a button : <span>Current source : URL</span><button>Change source</button>

  • πŸ‡«πŸ‡·France duaelfr Montpellier, France

    I like goz's second idea and I think this could also work when nothing has been configured yet:

    Props

    • URL: Data from field (field_link) Change source for URL
    • Color: -None- Change source for Color

    We would have to define a way to display a "summary" of the existing settings but this would be way more effective for performances because we would only need to load forms on demand. The downside is still usability because it's one more click in an UI that already needs a lot.

  • πŸ‡«πŸ‡·France pdureau Paris

    Thanks both for your feedbacks :)

    We would have to define a way to display a "summary" of the existing settings but this would be way more effective for performances

    We have this now ✨ [2.0.x] Add PluginSettingsInterface::settingsSummary() Active

  • πŸ‡ΊπŸ‡¦Ukraine SmovS Lutsk

    I like proposal #2 by @goz.

    It would improve performance by reducing unnecessary load and avoiding the need to build the dropdown each time, which also helps users notice that there are more options for selection.

Production build 0.71.5 2024