Cory House Profile picture
Jun 13 4 tweets 2 min read
🚨 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.
Two clarifications:

1. React Router 6.4 isn't here yet, but it adds data support via a new loader prop and looks 🔥: beta.reactrouter.com/en/dev/getting…

2. I plan to continue using react-query with React Router 6.4, so I can enjoy react-query's unique benefits like caching.

• • •

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

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
May 9
Common scenario: A team has two types of tests:

1. Unit tests (testing functions and components in isolation, often via @fbjest)

2. In-browser tests (testing the app in the browser, often via @Cypress_io)

The struggle: How do we avoid testing the same things twice?
Two approaches I've seen:

1. Focus mostly on unit testing, and create a small number of in-browser "happy path" tests.

2. Focus mostly on in-browser testing, and only create unit tests when desired.

Trying to cover all scenarios in both leads to a lot of duplicated effort.
That said, I'm not saying redundant coverage is bad. It's often impractical to exercise all code via the browser, especially since in-browser tests are slower.

So comprehensive unit tests are often useful. I'm just searching for a practical balance between the two approaches.
Read 4 tweets
Mar 19
An untrusted developer is a net loss.

The impact:
Each line must be carefully reviewed in hopes of catching all the mistakes.

We can’t assume anything works reliably, makes sense, does what it claims, or matches requirements.

We must question every line.

That’s a big problem.
Reviewing untrusted, poor quality code is time-consuming and demoralizing.

We're unlikely to catch all the problems.

It's impractical to "review our way to quality" when starting with code that's low quality, or solving the wrong problem.
Thankfully, most my career, my teams have worked with developers we could trust. But when we couldn't, PR’s required HUGE amounts of time, multiple rounds of comments, and occasionally, a complete rewrite.
Read 6 tweets
Nov 5, 2021
Checklist: How to make your React app faster ⚛️:

✅ Keep state as local as possible. Start by declaring state in the component that uses it. Lift as needed.
✅ Store data that doesn't need to render in refs
✅ Minimize context usage

1/x...
✅ Avoid putting data that changes a lot in context
✅ Separate contexts based on when they change
✅ Place context providers as low as possible
✅ Memoize expensive operations via useMemo
✅ Avoid needless renders via React.memo

2/x...
✅ Put content that renders frequently in a separate component to minimize the amount that's rendered
✅ Split complex controlled forms into separate components
✅ Consider uncontrolled components for large, expensive forms

3/x...
Read 7 tweets
Sep 29, 2021
7 things that keep teams from doing Continuous Delivery (deploying daily or even hourly):

1. Non-atomic PRs.

Solution: Each PR must be ready for a prod deploy before it can be merged to `develop`. To separate deployment from release, use a feature flag.

1/x (thread)
2. Ad-hoc release notes.

Solution: Declare release notes in CHANGELOG.md. Require an entry in this file in each PR. Validate this file has changed on each CI build. This assures the release notes are customer friendly, accurate, and complete.

2/x
3. Flakey tests.

Solution: Most tests should be unit and integration tests. Mock the API. Simplify E2E tests. E2E should merely assure each section loads. Anything more granular may lead to flakiness due to changing data.

3/x
Read 8 tweets
Sep 14, 2021
10 lessons I've learned about handling React state over the last 7 years...

(thread)

#react #reactjs
#1: Know the 8 ways to handle state, and when to consider each. Image
#2: Class components are dead to me. Image
Read 12 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!

:(