Exploring the form and data retrieval mechanism of remix

Recently, the emergence of remix has generated considerable buzz on Twitter, with many front-end communities discussing it. Coincidentally, there's an internal tool that needs to be developed, so I decided to give it a try. It feels quite similar to next.js, primarily based on routes, and it allows servers to fetch data for SSR through well-defined functions like getServerSideProps.

remix was created by Ryan Florence, the author of react-router. Initially, it was intended to be a paid product, but later it was made open source. While many might think, "Oh no, not another framework," remix indeed has its unique features. Anyone who has read the documentation and followed it closely will notice that remix is particularly focused on forms, which is likely the biggest distinction between remix and other SSR frameworks. Looking back, handling forms can be quite confusing for those just starting in front-end development.

Huh, but doesn’t submitting a form in the browser refresh the page? That doesn’t meet the requirements!

remix has put a lot of effort into form handling. Not only can you implement asynchronous requests using forms, but if JavaScript is disabled, it falls back to the built-in form operations of the browser. Although it requires a refresh, at least the submission functionality still works. (Moreover, I think sometimes a straightforward form submission with a page refresh can provide a better user experience than async operations 🤔)

This article will not delve deeply into all of remix's features but will explore form handling and data fetching specifically.

What are the benefits of form handling?

You don’t need to write a lot of JavaScript code, nor do you have to use variables (or state) to store input values. For example, consider the following:

<form action="/my/api" method="post">
  <input name="user_name" type="text" />
  <input name="world" type="text" />
  <button type="submit">
    Submit
  </button>
</form>

In a default setup (without any code intervention), when you press the button, the browser automatically sends a request to /my/api using the POST method, submitting the user_name and world fields as form data.

However, the default behavior requires server assistance to function completely. For instance, if the server only returns JSON, the user's page will remain on the same page. Therefore, in a typical application, the server usually returns a 301 redirect to another page, such as a success or failure page.

Sometimes, refreshing the entire page simplifies things significantly because the front end doesn’t need to manage various states and history operations. However, for applications that emphasize real-time interactions, like instant messaging or chat, page refreshes are less than ideal.

So how do we make form submissions asynchronous? By preventing the default behavior on the submit event and writing code to send the submission:

<form action="/my/api" method="post" onSubmit={e => {
  e.preventDefault()
  // call API!
}}>
  <input name="user_name" type="text" />
  <input name="world" type="text" />
  <button type="submit">
    Submit
  </button>
</form>

The main advantage of this approach is that it hands over the entire form operation to the browser's mechanisms, allowing you to easily obtain the form values using FormData:

<form action="/my/api" method="post" onSubmit={e => {
  e.preventDefault()
  const formData = new FormData(e.currentTarget)
  const userName = formData.get('user_name')
  const world = formData.get('world')
}}>
  <input name="user_name" type="text" />
  <input name="world" type="text" />
  <button type="submit">
    Submit
  </button>
</form>

With this approach, there’s no need to use refs or state to obtain input values. If you don’t utilize the native form mechanisms, you might write something like this in React:

const Component = () => {
  const [value1, setValue1] = useState()
  const [value2, setValue2] = useState()
  const [value3, setValue3] = useState()
  return <>
    <input value={value1} onChange={handleChange} />
    <input value={value2} onChange={handleChange} />
    <input value={value3} onChange={handleChange} />
  </>
}

As you can see, as the input fields increase, so does the number of useState declarations, making the code more cumbersome. Of course, this can also be abstracted away, but that adds another layer of abstraction and overhead.

However, once you convert the form submission to asynchronous, there are many states to consider:

• Loading: The form is being submitted, so all fields should be set to disabled to prevent user interaction.
• Form validation errors: You need to retain the field values and display error messages.
• API success: Display corresponding messages and clear the form.

In remix, APIs are provided to support both form submission redirects and asynchronous form applications. I like this approach because often, there's no need to go through extensive efforts for asynchronous processing, writing a lot of code just for simple form submissions.

Synchronous (using native form mechanisms)

In a native context, you can simply define the form content step by step without declaring any state.

// routes/users/index.js
export default function UserProfile() {
  return <form method="post" action="/users">
    <label>
      Name: <input type="text" name="userName" />
    </label>
    <label>
      Age: <input type="text" name="age" />
    </label>
    <button>Submit</button>
  </form>
}

On the server side, you need to include the corresponding handling. In remix, this is done by adding a function called action in the same file:

import { redirect } from 'remix';

export async function action({ request }) {
  const formData = await request.formData()
  const user = await createUser(formData)
  return redirect(`/users/${user.id}`)
}

// routes/users/index.js
export default function UserProfile() {
  return <form method="post" action="/users">
    <label>
      Name: <input type="text" name="userName" />
    </label>
    <label>
      Age: <input type="text" name="age" />
    </label>
    <button>Submit</button>
  </form>
}

The action function is called whenever the HTTP method is not GET, so you need to determine the HTTP method within the action function.

The redirect function is provided by remix and will redirect to the users/id page on the server side. An important point is that the redirection occurs on the server side, rather than using history.push. If form validation fails or the server returns an error, you can use useActionData to access the data returned from the server.

export async function action({ request }) {
  const formData = await request.formData()  
+  if (someError) {
+    return json({ error: message })
+  }
  return redirect(`/users/${user.id}`)
}

// routes/users/index.js
export default function UserProfile() {
+ const actionData = useActionData()
  return <form method="post" action="/users">
    <label>
      Name: <input type="text" name="userName" />
    </label>
    <label>
      Age: <input type="text" name="age" />
    </label>
+   {actionData.error && <p>{actionData.error}</p>}
    <button>Submit</button>
  </form>
}

Asynchronous

For asynchronous needs, remix provides the Form component for developers to use. To indicate the current form submission status, you can also use useTransition:

import { Form, useTransition } from 'remix'

// routes/users/index.js
export default function UserProfile() {
  const actionData = useActionData()
  const transition = useTransition()
  
  return <form method="post" action="/users">
    <label>
      Name:
      <input
        type="text"
        name="userName"
        disabled={transition.state === 'submitting'}
      />
    </label>
    {actionData.error && <p>{actionData.error}</p>}
    <button>Submit</button>
  </form>
}

In addition to these two mechanisms, you can use useSubmit to decide when to submit the form yourself. Whether synchronous or asynchronous, remix's philosophy on form handling is that when you send a form, it undergoes certain operations, then redirects to a specific page.

Data Fetching Mechanism - loader and fetcher

There are typically two common scenarios for data fetching in web pages:

1. When a user accesses a page via a <a> tag or the address bar, the page data is loaded, such as a blog post.
2. When a user performs an action, an API is called to fetch data, such as clicking on a comment section to retrieve data.

In the first case, remix provides a loader mechanism that only renders on the server side. Therefore, when the component renders, it already has the data, eliminating the need for loading and subsequent rendering operations.

In the second case, remix provides a fetcher mechanism, allowing you to use useFetcher for mutations and data fetching:

const MyComponent = () => {
  const fetcher = useFetcher()
  useEffect(() => {
    fetcher.load('/comments')
  }, [])

  if (fetcher.state === 'loading') {
    return <p>loading...</p>
  }

  return <div>
    <Comments comments={fetcher.data.comments} />
  </div>
}

Not only for fetching data, but fetcher can also be used for mutations:

const MyComponent = ({ content }) => {
  const fetcher = useFetcher()
  
  return <fetcher.Form method="post" action="/comments">
    <input type="text" name="content"></input>
    <button type="submit">Submit</button>
  </fetcher.Form>
}

Behind the scenes, remix handles the operations mentioned earlier:

• When you click submit, the state changes to submitting, enabling a loading UI.
• After the data is returned, you can access it via fetcher.data.
• fetcher.submit directly submits the form content without redirection (essentially calling the API and handling various states).

Edge Computing

Another point is that remix repeatedly emphasizes the concept of Edge servers (CDNs), which means not just deploying static webpages to a CDN, but rather deploying servers across various nodes to reduce network traffic.

Indeed, if the user's device performance is no longer a bottleneck, then the only factor that matters is network speed. Edge computing refers to deploying servers closer to users, thereby reducing the routing distance for packets. However, for some applications, if the target audience consists solely of local users, the distinction may not be as significant.

Conclusion

I appreciate remix's approach because its dedication to forms reminds me of my past thoughts on leveraging native form mechanisms to save a lot of value state declarations. The form handling mechanisms can also address some straightforward application scenarios without needing to write various asynchronous APIs. When development time is limited, there are many considerations for asynchronous operations, and often, a single misstep can lead to a worse experience than traditional forms.

remix accommodates various scenarios. In the absence of JavaScript, it can utilize native form mechanisms; for real-time needs, it can use the Form component; and for more SPA interactions, it can leverage fetcher. It effectively resolves a significant portion of the data handling issues that front-end developers care about.