-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: Support Rendering Error Messages to the DOM by Default
Although this feature is rather small, it opens up some pretty significant doors: 1. There are frameworks like `Lit` and `Preact` which expect to always have control of the content of the DOM node to which they render. With this `renderByDefault` option, we can guarantee that in these situations, the renderer will ALWAYS be used. So there should never be a time where the renderer suddenly stops working because the `FormValidityObserver` used the browser's default error message and directly modified an element's `textContent`. 2. There are developers who earnestly desire to keep their error messages in some kind of stateful object. They now have this option available if they "render" errors to their stateful object instead of rendering errors to the DOM directly. Then, they can use the stateful object to render error messages to the DOM instead. This isn't our preference or our recommendation. But if we can give people what they want with ease, then it's worth supporting. (More importantly, although we favor stateless forms in React, it's understandable why some might prefer the error messages to be _stateful_ -- primarily to avoid having to think about things like `useMemo` or `React.memo`. We're pretty happy that the types seem to be working fine, and our new changes are backwards compatible. However, it is somewhat... astounding how much TS effort was required compared to JS effort here (including when it came to tests). We've come to the point that @ThePrimeagen talked about where we're "writing code" in TypeScript. Not willing to lose the DX from the IntelliSense at this moment, though.
- Loading branch information
1 parent
14505c4
commit f1b9270
Showing
3 changed files
with
368 additions
and
60 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.