Form
Following up on this, there’s also an intermediate approach if you use the react-hook-form
library which is based on uncontrolled components, but does require state (being an island) due to its useForm()
hook helper. So in this sense, we could say there’s 3 approaches to forms: uncontrolled -> uncontrolled+state -> stateful
. As Marvin says, I agree that one should always start with uncontrolled
forms using only HTML. However, there might be cases when you need a bit more control, and that’s where the middleground (uncontrolled+state
) with a library like react-hook-form
might come into play. For example, in my case, I needed to use PATCH/PUT to interact with my RESTful API and the native HTML <form>
element only supports GET/POST, so I had to had an onSubmit handler (in an island), in which case you might as well use the react-hook-form
wrapper which provides some nice features while keeping things uncontrolled👍.
In general, forms have been sort of a pain to deal with (primarily since <form>
does not support all HTTP methods (for REST APIs), this lead to me prototyping an isomorphic <FormFetch />
component (check out the gist), it’s not an island, since client-side code is inlined in a <script>
tag) which augments the HTML-native <form>
to allow e.g.
by preventing the form’s default submit
event handler, and making a fetch
request instead (thus no dependencies.
This worked marvelously. @marvinh. would a built-in component like this e.g. <Form />
(similar to e.g. <Head >
) be interesting for fresh? This could be used as a component, no need to place it within an island, so ergonomics are I think great, and it relies only on HTML/Web APIs… In general, this could complement the incoming partials-based improvements for forms in fresh
Nguồn:: Discord