DX & authoring experience: for SDC+code components, the example is treated as the default, may not be desirable

Created on 21 March 2025, 12 days ago

Overview

Say you have a component with 2 optional properties: and .

Say that only an example is provided for .

The corresponding ComponentInputsForm looks like this:

It renders just fine. But:

  • Did the SDC developer really intend for that example text to end up being saved? What if it wasn't text, but an image? A date? A SKU? A … whatever?
  • Did the SDC developer not actually intend for this to be a pure schema example?
  • Did the SDC developer at most intend for this example to be used as the grayed out placeholder text, but never even considered it could end up being saved?

Proposed resolution

  1. Stop using the first example value as the default value.
  2. Instead, pass it as the example value to the Field Widget, for a UX like this: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/placeholder...
  3. Adopt JSON Schema's support for default, as surfaced months ago .
  4. Only the default in the SDC metadata can become the default value for an instantiated component.

User interface changes

TBD

🐛 Bug report
Status

Active

Version

0.0

Component

Component sources

Created by

🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

Sign in to follow issues

Comments & Activities

  • Issue created by @wim leers
  • 🇺🇸United States mglaman WI, USA

    +++++++1 for default value being a placeholder. I've placed a paragraph component so many times and starting typing only to start adding letters after the example content.

    However, that's really hard for non-text inputs. In that case I think it's fine to render the example as the default but leave the form empty.

  • 🇬🇧United Kingdom f.mazeikis Brighton
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    It is hard for non-textual prop shapes .

    But even for some textual ones, like date and time. Let alone images.

    For images, @lauriii has been saying that we need to make XBenhance what core’s image widget and media library widget do, precisely to show the default as a kind of placeholder.

    No designs exist for it yet to my knowledge.

    Given your +1, assigning to @lauriii.

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    Given a meeting last night surfaced this as a challenge/stable blocker for code components, and @effulgentsia’s firm +1 to label default value as “initial value” in the UI, to set clear expectations for content authors, bumping to Critical.

  • 🇫🇮Finland lauriii Finland

    My experience is that most page builders treat default values exactly the way Experience Builder does now: if there’s text in a field, that’s what will be saved. This matches how forms typically behave: when you see prefilled text, you expect it to be submitted unless you overwrite it.

    That said, we need to decide whether to rely on default or examples in JSON Schema for this. Personally, I don’t have a strong preference either way.

    Additionally, we may want to consider supporting both a placeholder value which is purely a form display concern and a true fallback value which is a rendering concern (i.e. fallback value determined at render time). I don’t think these should block the stable release.

  • 🇫🇮Finland lauriii Finland
  • 🇫🇮Finland lauriii Finland

    FWIW, this is called "Default value" in the Field UI module today and it behaves the same way as XB.

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    @lauriii in #10:

    FWIW, this is called "Default value" in the Field UI module today and it behaves the same way as XB.

    You dropped from the call with @f.mazeikis, @jessebaker, @effulgensia and others, in which they explained that precisely this behavior has actually led to a LOT of support requests for Acquia Site Studio. Short version: users expected that changing the default would make the new default appear in all component instances where the default had not been modified.

    Hence my proposal from #7.

    #8 is a very narrow reading/interpretation of the problem described with nuance in the issue summary, which @f.mazeikis had nothing to add to, and @mglaman added #2 to.

    Crucially, #8's ignores that it cannot work like that for SDC's default images — otherwise they'd end up being saved into Drupal's Media Library. Or is that what you're implying? 🤔 That'd be counter to what you said before.

Production build 0.71.5 2024