Although this feature is rather small (our 3kb bundle size didn't even change), it opens up some pretty significant doors:
1) Better Support for Using a Framework's Render Functions
There are frameworks like Lit and Preact which expect to always have control of the content of the DOM node to which they render entities. With this renderByDefault option, we can guarantee that for these frameworks, 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 to directly modify an element's textContent (instead of relying on the framework's render function).
2) Support Managing UI Errors Via State
This is mainly a feature for React/Preact devs. It may not be that significant for devs using other frameworks.
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 a 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 memo).
Although this feature is rather small (our
3kb
bundle size didn't even change), it opens up some pretty significant doors:1) Better Support for Using a Framework's Render Functions
There are frameworks like
Lit
andPreact
which expect to always have control of the content of the DOM node to which they render entities. With thisrenderByDefault
option, we can guarantee that for these frameworks, the renderer will always be used. So there should never be a time where the renderer suddenly stops working because theFormValidityObserver
used the browser's default error message to directly modify an element'stextContent
(instead of relying on the framework's render function).2) Support Managing UI Errors Via State
This is mainly a feature for React/Preact devs. It may not be that significant for devs using other frameworks.
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 a 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
ormemo
).