15 ways to make a slow React app:

Put all state in the root

Don’t cache, refetch

Pass needless props

Change state constantly

Request more data than you need

Drill props (instead of composing children)

Render 1000s of elements

Use heavy, non-native inputs

1/x…

#react
Bloat the bundle via monolithic libraries

Overuse context

Use named imports on 3rd party libs (may load the entire lib)

Put everything in 1 component

Don’t memo

Pass funcs that aren’t wrapped in useCallback to expensive children

Don’t lazy load - publish a monolithic bundle
Here’s how to make your React app faster:

• • •

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

5 Nov
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
29 Sep
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
14 Sep
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.
#2: Class components are dead to me.
Read 12 tweets
26 Jul
It’s remarkable how much better life is on a development team with this simple rule:

Code is automatically deployed to production when merged.

No more long release coordination threads.
No tedious approval processes.
No manual, repetitive, time-consuming steps.

Just merge.
This one rule fosters many other helpful behaviors:

✅ Get feedback early and often.

✅ Write good tests you can trust.

✅ Use feature flags so you can deploy incomplete features, or roll back if there are issues.
And, if a bug slips into prod, getting a fix in is straightforward:

1. Toggle the buggy new feature off (you used a toggle, right? 😉)
2. Merge a fix. It’ll automatically deploy in a few minutes. 😎
Read 4 tweets
26 Apr
When a measure becomes a target, it ceases to be a good measure."
— Goodhart’s Law

Example 1: Story points measure difficulty. But, if you set a target for story points completed per week, developers inflate their story point estimates to assure they hit the target.
Example 2: Tracking code coverage helps the team understand what code is tested. But if you target a certain code coverage percentage, developers game the system by writing useless tests.
Example 3: Burn down charts help estimate the completion date. But if you set a goal of burning down to zero every sprint, developers commit to less work in each sprint. And they avoid proposing any work that’s hard to estimate. This assures they can burn down to zero.
Read 4 tweets
19 Apr
Let’s talk about the implications of researching decisions (Thread)

If I quickly make a decision, it feels unimportant. I go with my gut. I’m typically happy.

Occasionally, I decide to research a decision. More research leads to better outcomes, right?

Not necessarily...
If I heavily research a decision, the decision feels more important. I want to justify my research time. So, I search for every tradeoff. I optimize for perfection. But, because my expectations are now so high, I’m more likely to be disappointed! 🤦‍♂️
So, here’s the trap: The more I research a decision, the more important the decision seems. This leads to problems:

1. Overspending due to over-valuing minor differences and fear of missing out.

2. Dissatisfaction due to heightened expectations
Read 6 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

Too expensive? 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!

:(