You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: Don't Mistake Renderable Error Objects as ErrorDetails Objects
Our new `renderByDefault` feature left open a bug where someone
might intend to render an object for their error message, but
the object would be mistaken for an `ErrorDetails` object instead
(or a `<FRAMEWORK>ErrorDetails` object).
Now, we consider an object to be an `ErrorDetails` object if it's
an object that explicitly has the `message` property (since that
property is always required). Otherwise, we consider objects to
be renderable error messages (assuming that rendering is enabled).
The TypeScript types that we added previously should also help
people avoid any unexpected bugs here.
Copy file name to clipboardexpand all lines: docs/form-validity-observer/integrations/README.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -459,7 +459,7 @@ export default function createFormValidityObserver<
459
459
460
460
/* ----- Standrd HTML Attributes ----- */
461
461
// Value Only
462
-
if (typeof errorMessages[constraint] !=="object") {
462
+
if (typeof errorMessages[constraint] !=="object"||!("message"in errorMessages[constraint])) {
463
463
if (constraint ==="required"&&typeof errorMessages[constraint] !=="boolean") {
464
464
config[constraint] = errorMessages[constraint];
465
465
}
@@ -489,9 +489,9 @@ If you're encountering TypeScript errors with the code above, we'll address that
489
489
Here in `configure`, we're looping over each of the properties provided in the `errorMessages` object so that we can A) Derive the error configuration that needs to be passed to the _original_ `FormValidityObserver.configure()` method, and B) Derive the field props that need to be returned from the _enhanced_ `configure` method. Hopefully, from the code and the comments, it's clear why the code is written as it is. But in case things aren't clear, here's a summary:
490
490
491
491
1. If the constraint _value_ is `null` or `undefined`, then the constraint was omitted by the developer. There is nothing to add to the local error `config` or the returned constraint `props`. A `required` constraint with a value of `false` is treated as if it was `undefined`.
492
-
2. If the _constraint_ is `badinput` or `validate`, it can be copied directly to the error `config`. There are no `props` to update here since `badinput` and `validate` are not valid HTML attributes.
492
+
2. If the _constraint_ is `badinput` or `validate`, then its _value_ can be copied directly to the error `config`. There are no `props` to update here since `badinput` and `validate` are not valid HTML attributes.
493
493
3. If the constraint _value_ is not a `SvelteErrorDetails` object, then we can assume that we have a raw constraint value. (For instance, we could have a raw `number` value for the `max` constraint.) The developer has indicated that they want to specify a field constraint without a custom error message; so only the constraint `props` are updated. <p>The exception to this rule is the `required` constraint. If the _constraint_ is `required` **and** the constraint _value_ is an `ErrorMessage`, then we assign this value to the error `config` instead of the `props` object. In this scenario, the _value_ for the `required` constraint is implicitly `true` (even if the value is an empty string).</p>
494
-
4. If the constraint _value_ is a `SvelteErrorDetails` object, then we can give the `value` property on this object to the `props` object. For simplicity, the error `config` can be given the entire constraint object in this scenario, even though it won't use the attached `value` property. Notice also that here, yet again, a `required` constraint with a value of `false` is treated as if the constraint was `undefined`.
494
+
4. If the constraint _value_ is a `SvelteErrorDetails` object (determined by the existence of a `message` property in the object), then we can give the `value` property on this object to the `props` object. For simplicity, the error `config` can be given the entire constraint object in this scenario, even though it won't use the attached `value` property. Notice also that here, yet again, a `required` constraint with a value of `false` is treated as if the constraint was `undefined`.
495
495
496
496
After we finish looping over the properties in `errorMessages`, we configure the error messages for the field by calling the _core_ `FormValidityObserver.configure()` method with the error `config` object. Finally, we return any necessary form field `props`.
0 commit comments