Make the "Choose a component" dialog wider/consistent

Created on 14 February 2023, almost 2 years ago
Updated 11 April 2023, over 1 year ago

Problem/Motivation

When adding a component, the modal dialog that opens is quite small and locked to the size set by the module. I'd like to either make this dialog match the width of the rest of Layout Paragraphs, or possibly add a second setting for the width of this particular dialog.

User interface changes

Before:

After:

With additional styling (custom on my site):

✨ Feature request
Status

Needs review

Version

2.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States quicksketch

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

Comments & Activities

  • Issue created by @quicksketch
  • Status changed to Needs work almost 2 years ago
  • πŸ‡ΊπŸ‡ΈUnited States justin2pin

    Hey @quicksketch - thanks for this. We almost always use the component selection modal in the narrower format... which makes me think that this should probably be a configuration option.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Wouldn't it be better to have it responsive with a fitting padding? I'd vote against further settings, where the modal component should be able to solve this automatically / responsive.

  • First commit to issue fork.
  • πŸ‡ΊπŸ‡ΈUnited States asherry

    We ran into this issue too. If you don't specify a width at all in the dialog options it looks like it defaults to 300px (at least in our case it does). This distorts the search bar and the component list quite a bit.

    @Anybody by "automatically / responsive" I'm assuming you mean a width of "auto" or "fit-content"? While this would work fine in our case I actually agree with Justin in that it's probably a safer bet to allow sites to separate these settings if they need to.

    Digging into this a bit, the downside is that seems to make things more complicated. I pushed some code to look at, just to see if we agree this is the right direction.

    • Adding another dialog type configuration means they should be named, for example "default" or "component_add".
    • Adding different types of dialog config changes the schema, this will need to have an update hook so sites do not break.
    • We should account for all dialogs. For the ones I'm aware of I gave them names: "component_add", "component_edit", "component_delete", "section_add", and "default".

    I did some refactoring with the config form and the Dialog class. Let me know what you all think.

  • Status changed to Needs review over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States asherry
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Thanks @asherry well with "automatically / responsive" I mean something that works best for >= 80% of the users on all relevant devices and browsers by default. I don't see the need to configure such things in Drupal config individually. If someone needs something special, it should be overwritable in CSS. For that being able to identify the modals would be quite helpful indeed!

    It doesn't have to be "auto" or "fit-content", can also be a more dynamic solution using media queries if needed or whateve, but in the current situation my experience is, that it would be better to have modals better use the available screen space with a high limit by default.

    I often run into situations with large screen and still need to argue with small forms. On mobile deviced the space is very limited, but the modal is still smaller than the screen and consumes a lot of space itself. That's what I'm seening as imperfect.

    I know that's only half the truth... but there are best practices for the max / min width of forms and such should be used, without needing a setting in the UI. That's my point. Not only in layout paragraphs, but in Drupal in general. No technical solution yet, but perhaps @thomas.frobieter can go more into details or provide some good examples for reference.

    TL;DR:
    Drupal Modals are not using the available screen spaces on different devices well by default yet. That should be solved first, and it should stick to best practice. Afterwards individual modals can be improved, if needed. But we have to be sure it doesn't make things worse again. So I guess this should be a core issue first.

Production build 0.71.5 2024