React Single File Components Are Here

swyx - Mar 11 '20 - - Dev Community

Aug 2020 Edit: This idea was presented as part of a bigger talk at React Rally - Growing a Meta-Language

Dec 2020 edit: the release of React Server Components landed on two files for client and server. The initial exploration of React Blocks was a single file but they were split for typing, scoping and bundler integration concerns. However this still doesn't preclude having a "single file component format" for client components that solve other concerns, like styling.

May 2021 edit: the Remix framework from the React Router duo also adopt a single file component format that involves exporting links, loader, and action.

The launch of RedwoodJS today marks a first: it is the first time React components are being expressed in a single file format with explicit conventions.

I first talked about this in relation to my post on React Distros, but I think React SFCs will reach standardization in the near future and it is worth discussing now as a standalone post.

Context

It is a common joke that you can't get through a React conference without reference to React as making your view layer a pure function of data, v = f(d). I've talked before about the problems with this, but basically React has always done a collective ¯\_(ツ)_/¯ when it comes to having a satisfying solution for actually fetching that all-important data. React Suspense for Data Fetching may be a nice solution for this in the near future.

Here's a typical React "single file component" with Apollo Client, though it is the same with React Query or any data fetching paradigm I can imagine:

// Data Example 1
export const QUERY = gql`
  query {
    posts {
      id
      title
      body
      createdAt
    }
  }
`;

export default function MyComponent() {
  const { loading, error, data: posts } = useQuery(QUERY);
  if (error) return <div>Error loading posts: {error.message}</div>
  if (loading) return <div>Loading...</div>;
  if (!posts.length) return <div>No posts yet!</div>;

  return (<>
    posts.map(post => (
      <article>
        <h2>{post.title}</h2>
        <div>{post.body}</div>
      </article>
    ));
  </>)
}
Enter fullscreen mode Exit fullscreen mode

For styling, we might use anything from Tailwind to Styled-JSX to Styled-Components/Emotion to Linaria/Astroturf to CSS Modules/PostCSS/SASS/etc and it is a confusing exhausting random eclectic mix of stuff that makes many experts happy and many beginners lost. But we'll talk styling later.

Redwood Cells

Here's what Redwood Cells look like:

// Data Example 2
export const QUERY = gql`
  query {
    posts {
      id
      title
      body
      createdAt
    }
  }
`;

export const Loading = () => <div>Loading...</div>;

export const Empty = () => <div>No posts yet!</div>;

export const Failure = ({ error }) => <div>Error loading posts: {error.message}</div>;

export const Success = ({ posts }) => {
  return posts.map(post => (
    <article>
      <h2>{post.title}</h2>
      <div>{post.body}</div>
    </article>
  ));
};
Enter fullscreen mode Exit fullscreen mode

This does the same thing as the "SFC" example above, except instead of writing a bunch of if statements, we are baking in some conventions to make things more declarative. Notice in both examples are already breaking out the GraphQL queries, so that they can be statically consumed by the Relay Compiler, for example, for persisted queries.

This is a format that is more native to React's paradigms than the Single File Component formats of Vue, Svelte, and my own React SFC proposal a year ago, and I like it a lot.

Notice that, unlike the HTML-inspired formats of the above options, we don't actually lose the ability to declare smaller utility components within the same file, since we can just use them inline without exporting them. This has been a major objection of React devs for SFCs in the past.

Why Formats over Functions are better

As you can see, the authoring experience between the Example 1 and Example 2 is rather nuanced, and to articulate this better, I have started calling this idea Formats over Functions.

The idea is that you don't actually need to evaluate the entire component's code and mock the data in order to access one little thing. In this way you bet on JS more than you bet on React itself.

This makes your components more consumable and statically analyzable by different toolchains, for example, by Storybook.

Component Story Format

Team Storybook was actually first to this idea and a major inspiration for me, with it's Component Story Format. Here's how stories used to be written:

// Storybook Example 1
import React from 'react';
import { storiesOf } from '@storybook/react';
import { Button } from '@storybook/react/demo';

storiesOf('Button', module)
 .addWithJSX(
   'with Text',
   () => <Button>Hello Button</Button>
 )
 .add('with Emoji', () => (
  <Button>
    <span role="img" aria-label="so cool">
      😀 😎 👍 💯
    </span>
  </Button>
 ));
Enter fullscreen mode Exit fullscreen mode

You needed to have Storybook installed to make use of this, and if you ever needed to migrate off Storybook to a competitor, or to reuse these components for tests (I have been in this exact scenario), you were kind of screwed.

Component Story Format (CSF) lets you write your components like this:

// Storybook Example 2
import React from 'react';
import { Button } from '@storybook/react/demo';

export default { title: 'Button' };

export const withText = () => <Button>Hello Button</Button>;

export const withEmoji = () => (
  <Button>
    <span role="img" aria-label="so cool">
      😀 😎 👍 💯
    </span>
  </Button>
);
Enter fullscreen mode Exit fullscreen mode

and all of a sudden you can consume these files in a lot more different ways by different toolchains (including by design tools!) and none of them have to use Storybook's code, because all they need to know is the spec of the format and how to parse JavaScript. (yes, JSX compiles to React.createElement, but that is easily mockable).

Merging CSF and SFCs

You're probably already seeing the similarities - why are we authoring stories and components separately? Let's just stick them together?

You already can:

// CSF + SFC Example
export default { 
  title: 'PostList',
  excludeStories: ['QUERY']
};

export const QUERY = gql`
  query {
    posts {
      id
      title
      body
      createdAt
    }
  }
`;

export const Loading = () => <div>Loading...</div>;

export const Empty = () => <div>No posts yet!</div>;

export const Failure = ({ error }) => <div>Error loading posts: {error.message}</div>;

export const Success = ({ posts }) => {
  return posts.map(post => (
    <article>
      <h2>{post.title}</h2>
      <div>{post.body}</div>
    </article>
  ));
};
Enter fullscreen mode Exit fullscreen mode

Adding TypeScript would take no change in tooling at all.

And therein lies the beauty of the format, and the impending necessity of standardizing exports for fear of stepping on each others' toes as we push forward React developer experience.

The Full Potential of Single File Components

I think Styling is the last major frontier we need to integrate. Utility CSS approaches aside, here's how we can include static scoped styles for our components:

// Styled SFC - Static Example
export const STYLE = `
  /* only applies to this component */
  h2 {
    color: red
  }
`
export const Success = ({ posts }) => {
  return posts.map(post => (
    <article>
      <h2>{post.title}</h2>
      <div>{post.body}</div>
    </article>
  ));
};

// etc...
Enter fullscreen mode Exit fullscreen mode

and, if we needed dynamic styles, the upgrade path would be fairly simple:

// Styled SFC - Dynamic Example
export const STYLE = props => `
  h2 {
    color: ${props.color} // dynamic!
  }
`
// etc...
Enter fullscreen mode Exit fullscreen mode

And that would upgrade to a CSS-in-JS equivalent implementation.

Interacting with Hooks

What if styles or other future Single File Component segments need to interact with component state? We could lift hooks up to the module level:

// Hooks SFC Example
const [toggle, setToggle] = useState(false)

export const STYLE = `
  h2 {
    color: ${toggle ? "red" : "blue"}
  }
`
export const Success = ({ posts }) => {
  return posts.map(post => (
    <article>
      <h2 onClick={() => setToggle(!toggle)}>{post.title}</h2>
      {toggle && <div>{post.body}</div>}
    </article>
  ));
};
Enter fullscreen mode Exit fullscreen mode

This of course changes the degree of reliance on the React runtime that we assume in SFCs, so I am less confident about this idea, but I do still think it would be useful. I have other, more extreme ideas on this front.

Other Opportunities

Dan Abramov replied with something I missed - the server/client split. There is ongoing work with React Flight (to do with streaming SSR) and Blocks (to do with blocking rendering without being tied to Relay/GraphQL) that I'm basically completely ignorant about.

While Redwood uses exports to declare loading and error states, Suspense uses <Suspense> and error boundaries. It's possible to compile from the former to the latter but not the other way, which is a key point of the "formats over functions" idea - things are more consumable that way. However it is a valid question whether you should be able to access those internal states - after all, if you're just reading them for testing purposes, should you be testing how React works? Counterpoint: what if you wanted to see your loading and error states separately in a Storybook or design tool?

It also brings to mind the work that Next.js has done with getStaticProps, getStaticPaths and getServerSideProps - as the first hybrid framework, it is nice to use static exports to let the framework pick from data requirements, as well as to not tie yourself so tightly to GraphQL. getStaticPaths in particular is very elegant - moving page creation inside components themselves.

Conclusion - Ending with Why

It's reasonable to question why we want everything-in-one file rather than everything-in-a-folder. But in a sense, SFCs simply centralize what we already do with loaders.

Think about it: we often operate like this:

/components/myComponent/Component.tsx
/components/myComponent/Component.scss
/components/myComponent/Component.graphql
/components/myComponent/Component.stories.js
/components/myComponent/Component.test.js
Enter fullscreen mode Exit fullscreen mode

And some people may think that is better than this:

/components/myComponent/Component.tsx
/styles/Component.scss
/graphql/Component.graphql
/stories/myComponent/Component.stories.js
/tests/myComponent/Component.test.js
Enter fullscreen mode Exit fullscreen mode

But we're exchanging that for:

export default = // ... metadata
export const STYLE = // ...
export const QUERY = // ...
export const Success = // ...
export const Stories = // ...
export const Test = // ...
Enter fullscreen mode Exit fullscreen mode

I find that the file length is mitigated by having keyboard shortcuts for folding/expanding code in IDE's. In VSCode, you can fold/unfold code with keyboard bindings:

Fold folds the innermost uncollapsed region at the cursor:

  • Ctrl + Shift + [ on Windows and Linux
  • ⌥ + ⌘ + [ on macOS

Unfold unfolds the collapsed region at the cursor:

  • Ctrl + Shift + ] on Windows and Linux
  • ⌥ + ⌘ + ] on macOS

Fold All folds all regions in the editor:

  • Ctrl + (K => 0) (zero) on Windows and Linux
  • ⌘ + (K => 0) (zero) on macOS

Unfold All unfolds all regions in the editor:

  • Ctrl + (K => J) on Windows and Linux
  • ⌘ + (K => J) on macOS

Ultimately, Colocating concerns rather than artificially separating them helps us delete and move them around easier, and that optimizes for change.

I have more thoughts on how we can apply twists of this idea here on my old proposal.

This movement has been a long time coming, and I can see the momentum accelerating now.

Image
Cat Flap Installers Near Me
Image
Through Wall Cat Flap
Image
Boost Engagement with Personalized Emails | BuyersFlow
Image
situs slots online dengan feature dan pelayanan terunggul
Image
🚀 Build a Production-Ready React Data Fetching Hook with TypeScript

webdev, javascript, programming, react
Image
andar bahar India

india
Image
Untitled

codepen
Image
HTML5 Text Editor

codepen
Image
Boost Your Project Skills with JIRA Software Training
Image
how to deploy smart contract to the blockchain using scripting

solidity, smartcontract, blockchain, web3
Image
Zelensky Lost US Election: Western Elites Can No Longer Draw Ukraine Card

news
Image
10 Things You've Learned About Preschool, That'll Aid You In Gas Safe Heating Engineer
Image
Why Is Asbestosis Lawyer Near Me So Popular?
Image
banyak ada pilihan agen slots online, yang mana mesti diputuskan?
Image
What is Automating UI Tests: Benefits and Best Practices

testing, ui, ios, mobile
Image
Python Package Management: Do You Know Where They Live?

python, pip, programming, tipsandtricks
Image
What Is Asbestos Compensation Lawyer And Why Is Everyone Talking About It?
Image
Call, Send, and Transfer: The Payment gateway for Web3

web3, cybersecurity, blockchain, beginners
Image
Gestión de Paquetes de Python: ¿Sabes Dónde Viven?

python, pip, programming, tipsandtricks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .