Exploration around supporting no JS

[blittle]

Hydrogen should provide primitive features to progressively enhance a web experience, even supporting a browser that has JavaScript disabled. This RFC explores some ideas on how that might look in Hydrogen.

Embrace Native Forms

1. When a network request needs to be made based on an action from the user, use native forms. Those forms can post data to an API route, which in turn can respond with a 304 redirect to the appropriate page (this might be the existing page the user is already on, which would cause a page reload).
2. When JavaScript is enabled, we don't want a page reload. Instead of directly using a <form> element, provide a <Form> wrapper. This wrapper will only execute when JavaScript is enabled, and will prevent the default form submission, and instead manually construct a fetch request.
3. On fetch success, re-render the page by reinitiating RSC.

Example

Preview video: https://screenshot.click/19-20-5btql-o8cvg.mp4
Preview branch: https://github.com/Shopify/hydrogen/tree/bl-nojs

// contact.server.jsx
import Form from '../components/Form.client';
​
const names = [];
​
export async function api(request) {
  // `.formData()` doesn't support multipart form requests at the moment
  const formData = await request.formData();
​
  for (let entry of formData) {
    names.push(entry[1]);
  }
​
  // This response causes a page reload when JS is disabled.
  // That page reload also automatically re-renders the page.
  return new Response(null, {
    status: 303,
    headers: {
      Location: '/form',
    },
  });
}
​
export default function Contact() {
  return (
    <Form action="/form" method="POST">
      <label htmlFor="fname">First name:</label>
      <input type="text" id="fname" name="fname" autoFocus></input>
      <input id="fsubmit" type="submit" value="Submit"></input>
      <ol>
        {names.map((name) => (
          <li key={name}>{name}</li>
        ))}
      </ol>
    </Form>
  );
}

// Form.client.jsx
import {useServerState} from '@shopify/hydrogen/client';
import {useCallback, useRef} from 'react';
export default function ({
  action,
  method,
  children,
  enctype = 'application/x-www-form-urlencoded',
}) {
  const formRef = useRef();
  const {setServerState} = useServerState();
  const submit = useCallback(
    async (e) => {
      // if JS is enabled, this will execute and the normal
      // form POST with refresh will be prevented
      e.preventDefault();
      // Instead, use fetch to make the request
      await fetch(action, {
        method,
        body: new FormData(formRef.current),
      });
      // On success we need to re-trigger a hydration request.
      // This is ugly, maybe there's a better way to do it?
      setServerState('', '');
    },
    [action, method, formRef]
  );
  return (
    <form
      action={action}
      method={method}
      onSubmit={submit}
      ref={formRef}
      encType={enctype}
    >
      {children}
    </form>
  );
}

Questions and Ideas

1. We could enhance API routes with a Hydrogen provided primitive that if returned from the API route, would automatically do the redirect stuff.
2. We should expose a better way to retrigger RSC. Maybe a useRefresh() hook.
3. Maybe the server could automatically know if the request is originating from a <Form> fetch vs a vanilla <form action> POST. If so, then the server could respond with a redirect (for <form>) or a RSC response (for fetch).
4. Currently fetch with new FormData() is a multipart form request, and undici doesn't support multipart form requests. Open issue for it to be added: Implement multipart parsing nodejs/undici#974
5. How would the starter template change to take more advantage of this?
6. How do these changes relate to updating serverState, both with and without JS?

[benjaminsehl]

Wow, really awesome!

I think whenever possible, if we can support shipping less javascript, we should. It’s something I love about https://kit.svelte.dev/ (also a Vite app!), Remix. The closer to fundamentals, the better; older stuff ironically helps us future proof, it helps cross compatibility, it can positively impact SEO and accessibility, and it decreases maintenance.

That said — there are a lot of times we’ll need to ship JS for interactivity, and we shouldn’t break our backs to not do that. I'd enthusiastically support all of these ideas, so long as the implementation doesn't significantly increase the lift, or de-prioritize critical merchant DX features/critical shopping features.

For instance: 
If there is a way to implement a critical feature in 2 days, but requires JS (without impacting accessibility, modern browser compatibility, or SEO) — and the non-JS alternative implementation is possible but requires an extra 2 weeks (and assuming we can come back and improve it to be non-JS compatible w/o breaking change at a later date) then we should choose the 2 day option. I think there would be exceptions to this, but I'd use that as the guiding principle.

[frandiox]

I might be misunderstanding but I think that, in order to support No-JS, the developer needs to make things thoughtfully because there won't be any hydration:

• No JS event listeners added, only forms + anchor tags would work (e.g. our cart in the starter template wouldn't even open right now).
• RSC response embedded in SSR won't be used but we have no way to know this automatically to skip it. Not too important, just useless bytes downloaded. I guess RSC is completely useless in this use case because it's just the same as pure SSR, right?

Therefore, this might require more work than only relying on API routes 🤔

In any case, the Form component is a good idea if we want to support this use case. For the API, what about response.redirect(path: string, status? = 303])? We already use this in server components. I guess we could also redirect to the current path automatically if nothing is returned?

[blittle]

💯 if you wanted to fully support no js, there'd need to be a lot of other changes. This exploration is just to make sure we have the functionality to easily support it if desired. The current API routes design is a bit different than RSC, in that we don't pass the route function a response object, rather the function creates the response. Would it be weird to do:

export async function api() {
  const response = new Response(null);
  response.redirect('some path', 303);
  return response;
}

[frandiox]

Ah you are right! I saw request parameter and somehow mixed it up in my mind thinking it was response 😅