Share this page!

Cory House Profile picture
Twitter logo
Sep 22 • 5 tweets • 1 min read
React: The Good Parts™

Core API:
1. Function components
2. JSX
3. useState
4. useReducer
5. useRef
6. lazy
7. Suspense

Ecosystem:
1. TypeScript
2. Vite/Next/Remix
3. React Router
4. React Query
5. react-error-boundary
6. clsx
7. testing-library

#react
What I mean by “The Good Parts”:

React’s API has grown. And the ecosystem is massive. So it's hard to choose.

"The Good Parts" are React’s best features and most trusted ecosystem projects.

The other stuff isn’t “bad”. But "The Good Parts” are often all I need.
Why didn't I list context?

- It's often unnecessary with react-query (most state is remote)
- Not designed for frequent updates
- Many third party state libraries provide similar benefits and better performance (Zustand, Signal, Jotai, Valtio, Redux, and Legend to name a few).
Why did I only list 3 hooks?

Because the other hooks are rarely necessary, and frequently overused.

Using frameworks or third party state often eliminates the need for using most of React's advanced hooks.

So, the hooks in "The Good Parts" are often all I need.
Why didn't I list various performance-related features?

Because if I compose my components properly, and keep my state as local as possible, performance optimizations are typically unnecessary.

• • •

Missing some Tweet in this thread? You can try to force a refresh
　

Keep Current with Cory House

Cory House Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @housecor

Cory House Profile picture
Sep 7
I ❤️ React. But, it’s not perfect.

There are features you should avoid.

Here’s “React: The Bad Parts”

👇
Class components - I can’t think of a good reason to use class components anymore.

Use functions. The API is simpler

Use react-error-boundary so you don’t need to use classes for boundaries.
useEffect - A confusing name and API, and it’s overused. Especially for HTTP. Prefer react-query, and/or React Router loaders in 6.4.

Avoid using to sync state. Instead, derive state on render (and memo if needed).

Use rarely for syncing third party state.
Read 8 tweets
Cory House Profile picture
Aug 13
I enjoy reading the biographies of wildly successful people.

I’ve found a number of commonalities in their stories.

Here are 7 common threads of world-class performers:

👇
1. They worked harder than almost anyone would be willing to work.

They put in outrageous hours - often for a decade or more. They were totally imbalanced. They sacrificed nearly everything else to achieve greatness in a narrow field.
2. They didn’t just work hard. They got lucky.

Bill Gates’ parents got him access to a terminal when hardly anyone in the world could do so.

Will Smith bumped into Quincy Jones in LA by chance. Quincy contacted Will months later and proposed “The Fresh Prince of Bel Air”.
Read 9 tweets
Cory House Profile picture
Jul 27
Software development estimates are frequently *way* off.

Why? Because many aspects of software development are nearly impossible to estimate.

Here are 9 reasons software development estimates fail:

👇
1. “Done” is debatable.

Aspects of acceptable quality like performance, code quality, security, accessibility, reusability, readability, and usability are hard to specify and quantify. This leads to time-consuming arguments and negotiations over when code is truly done.
2. Merge conflict overhead is unpredictable.

The frequency and complexity of conflicts varies based on team size, code coupling, ticket size, branching strategy, tech, and merge frequency.
Read 11 tweets
Cory House Profile picture
Jun 26
🚨 Web developers 🚨

<a> and <button> are often misused. They have different purposes.

<a> is for navigating
<button> is for actions

This leads to 2 common mistakes:

1. Using anchors for actions.
2. Using buttons to navigate.

1/4 👇 <!-- Button used for navigation. Avoid 👎 --> <button oncl
4 reasons this matters:

1. Usability
Users expect links to take them somewhere.
Users expect buttons to trigger actions.

2. Accessibility
Screen readers announce "button" and "link". They also group links in the rotor. Only anchors show in the rotor's "Links" list.

2/4 Voiceover rotor showing a list of links
3. Keyboard user support

Anchors are triggered via the enter key.

Buttons are triggered via the enter key or spacebar.

Submit buttons are triggered when the enter key is pressed while any input within a form is focused.

Keyboard users expect these behaviors.

3/4
Read 6 tweets
Cory House Profile picture
Jun 13
🚨 React developers: 🚨

You don’t have to fetch data via useEffect.

Here are 7 compelling alternatives to fetching data via useEffect:

1. react-query
2. swr
3. XState
4. React Router 6.4
5. @remix_run loader
6. @nextjs getServerSideProps/getStaticProps
7. rtk query

#react
And yes, many of these use useEffect behind the scenes. But that’s the point - instead of calling useEffect directly, you should probably use a mature abstraction at this point.

Here’s why.
My decision tree:

Using @remix_run? Fetch in loader.

Using @nextjs? Fetch in getServerSideProps/getStaticProps and via swr on client.

Using React Router 6.4? Fetch in the route’s loader prop.

Using Redux? Fetch via rtk query.

Nothing above applies? Use react-query.
Read 4 tweets
Cory House Profile picture
Jun 11
Just learned a new monorepo pattern from @rwieruch: Incubate and hatch.

Goal: Compose a separate repo within a monorepo. This is useful when the repo will be developed initially in a monorepo (incubated), and handed to a separate team (hatched).

1/4👇
Here's the incubate and hatch approach:

1. Create a separate repo.

2. Close the new repo into your existing monorepo. (Called incubation). Ignore the repo via .gitignore. This allows rapid dev by referencing local versions of relevant monorepo dependencies.

2/4
3. When the project is ready to be handed to the separate team, the repository is "hatched". Since the project had a dedicated repo all along, this is easy. Relevant dependencies are set to the current published version. The new team can upgrade deps over time, as desired.

3/4
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

Send Email!

Email the whole thread instead of just a link!

Separate emails with commas

:(