Hero component failed to render after removing text

See https://git.drupalcode.org/project/experience_builder/-/blob/0.x/compone... — heading is required. So then the "failed to render" message is normal.

This seems like another case where deleting the required value should restore the original example.

But … we discussed this 2 days ago, and didn't we agree that we'd go for exactly this behavior everywhere, as a way to convey: "dear user, you removed a required input, so of course it cannot render" — where that is shown to the user in:

1. client-side validation in the component instance form
2. the preview (which you're reporting here)
3. the "Publish all changes" button will report this same validation error

So … what's the bug? 🤔

Would like Ben's assessment on this — do you agree, Ben?

After removing the heading from the hero component, a frontend validation error is correctly displayed. However, if the user switches tabs and attempts to edit another field, the component fails to render. This could be improved from a user experience perspective.
Ideally, the component should not fail to render when a required field is left blank. Instead, the error should be shown when the user tries to publish changes with an empty heading field.
In my view, adding validation for required fields during publishing is one issue, while the component failing when text is removed from a required field is a separate concern and which is not a good user experience.

Ideally, the component should not fail to render when a required field is left blank.

I disagree, if a component has an invalid prop, it shouldn't be rendering. That said, the. component should do a better job informing the user why it isn't rendering, which we will address here:

📌 Invalid prop errors should be detailed in Component preview Active

I don't think the current UX is acceptable; invalid form value should not result in the component rendering an error.

I'm wondering why are we throwing an error instead of rendering the component with the empty string? JSON Schema required allows empty string so the component itself should be able to render with that.

Even though JSON Schema allows that, we could enforce a stronger validation and show it as a validation error on the form / review changes panel, but that could be separate from the rendering part.

@lauriii we discussed this at length with a big group while you were on PTO. 📌 Invalid prop errors should be detailed in Component preview Active is what @effulgentsia, @bnjmnm, myself and others arrived at.

Please merge in 0.x before doing more work, because ✨ Add a Video prop type to the Code Component editor Active landed a few hours ago, and made significant changes in this area — enough to also fix 🐛 Default image is not loaded when adding a pattern Active .

This issue is about something else though: it's not about DefaultRelativeUrlPropSources at all, but it's still touching the same code, so merging in upstream now will prevent a very painful conflict later on. Plus, the clean-up that #3534601 did just might end up helping you here! 😊

Switching to needs review, but specifically a back end person should look at my MR + Code comments to make sure the things I'm removing are OK to remove. All the BE changes needed to get this working required removing stuff that I assume was added for a good reason, but since the tests pass maybe it's fine? LMK!

HEAD

When following the steps to reproduce, the client sends this to the server:

{
  "source": {
    "subheading": {
      "expression": "ℹ︎string␟value",
      "sourceType": "static:field_item:string",
      "value": ""
    },
    "cta1": {
      "expression": "ℹ︎string␟value",
      "sourceType": "static:field_item:string",
      "value": "View"
    },
    "cta1href": {
      "expression": "ℹ︎link␟url",
      "sourceType": "static:field_item:link",
      "value": "https://example.com",
      "sourceTypeSettings": {
        "instance": {
          "title": 0
        }
      }
    },
    "cta2": {
      "expression": "ℹ︎string␟value",
      "sourceType": "static:field_item:string",
      "value": "Click"
    },
    "heading": {
      "required": true,
      "jsonSchema": {
        "type": "string"
      },
      "sourceType": "static:field_item:string",
      "expression": "ℹ︎string␟value",
      "default_values": {
        "source": [
          {
            "value": "There+goes+my+hero"
          }
        ],
        "resolved": "There+goes+my+hero"
      }
    }
  },
  "resolved": {
    "subheading": "",
    "cta1": "View",
    "cta1href": "https://example.com",
    "cta2": "Click"
  }
}

(note no key-value pair for heading under resolved!)

MR

This changes the above by ensuring that heading is present, and with a fallback value of "" 👍

I reviewed the server-side changes, and responded on the MR with 3 concerns, and matched those with 3 commits to address those concerns.

Here's hoping @bnjmnm finds my concerns, commits and rationales convincing! 🤞😊

Improve title accuracy.

Major usability impact, so marking .

This has been pretty thoroughly FE / BE reviewed but still needs MR approval for

Redux-integrated field widgets /ui/src/components/form/inputBehaviors.tsx 

I haven't reviewed the whole MR, since others have, but the inputBehaviors.tsx change looks correct, so I approved it since that was the only file not covered by other code owner approvals.