DEV Community: Adaptive Shield Matrix

React Basics: Essential Knowledge for Every React Developer

Adaptive Shield Matrix — Sun, 12 Nov 2023 11:53:20 +0000

This post is meant to cover essential information that every react developer should know or be aware of.

Another article name could be "Most common problems encountered in React"

Why is this important?

Since React is not really a framework and only a view library it does not offer an all-in-one solution to most web development needs and relies on its ecosystem to round out its rough edges.

Most common problems in react frontend development are

Typescript usage with React
When and how to use core APIs and Hooks
State Management

Because not knowing the basics (especially for beginners) leads to countless repeat of mistakes, confusion, suffering
and complaining loudly on the internet about how frontend development in general and react in particular sucks (even if it is not true).

Basics / Fundation

You don't require any paid courses for react frontend development if your read through and have a strong grasp of the following resources

Javascript - https://javascript.info/
Typescript - https://www.typescriptlang.org/docs/handbook/2/basic-types.html
React - https://react.dev/
React with TypeScript - https://github.com/typescript-cheatsheets/react

Tsconfig

Enable strict typescript compiler settings

The strict is most important
Other entries after that are optional
I disabled noUnusedLocals and noUnusedParameters in my projects because It more often gets in the way than helps (especially if you refactor code more often)

// tsconfig.json
{
  "compilerOptions": {
  // code quality settings
  "strict": true,
  "noUncheckedIndexedAccess": true,
  "noUnusedLocals": false,
  "noUnusedParameters": false,
  "noImplicitAny": true,
  "noImplicitReturns": true,
  "noFallthroughCasesInSwitch": true,
  "forceConsistentCasingInFileNames": true
  }
}

Read about the individual fields here
https://www.totaltypescript.com/tsconfig-cheat-sheet

React core APIs to avoid

Hooks that should only be used in library code (if your write public or internal ones) and avoided in web app code

useContext
useRef
useId

Try to avoid and use only rarely / then necessary

useEffect - Why? Best explanation - https://react.dev/learn/you-might-not-need-an-effect

Avoid and do not use following hooks

use, useState, useContext -> Replaced by custom methods provided by the state management library
useMemo, useCallback, cache -> The most common premature optimization addressing re-render issues, which are unnecessary and can be skipped completely if using a proper state management library

React State Management

React build-in core libraries offer only primitives like useState and useContext to manage state.
React evolved over the years and relies heavily on its community to cover its weaknesses, particularly in the realm of state management.

Why are the build-in hooks `useState` and `useContext` not good enough?

They are ment to be primitives, meant to be extended
They work only good enough in a single isolated component
Are are inadequate to pass and share state across multiple components
All above incentivises you to write very big components (-> that are hard to read), since passing state between components causes uneccesary re-renders and bad performance

Why are the build-in hooks useState and useContext not good enough to share state between components?

Using useState
- Causes you to pass down state from parent components to child component by props
- Having to pass down additional functions to change said state (from parents to child components)
- If a child component calls a state mutation function (passed from a parent) -> the parent and all of its child have to re-render -> performance problems
Using useContext
- You will have a high amount of wrapped <A..Provider><B..Provider</B..Provider></A..Provider> Context Providers that makes it hard to read and follow thats going on
- Modifing state of a single context providers -> forces a reload of all components using this context
Both useState and useContext cause unnecessary re-render that are hard to track down

Here are this and more react problems mentioned in more detail if you want to read futher

React I Love You, But You're Bringing Me Down - https://marmelab.com/blog/2022/09/20/react-i-love-you.html
Comments on Hacker News - https://news.ycombinator.com/item?id=32911492
Commends on Reddit - https://www.reddit.com/r/reactjs/comments/xja3y5/react_i_love_you_but_youre_bringing_me_down/

What is the best way to manage state in React?

The industry-accepted solution to re-render problems is a signal based state manager.
Learning from Reacts quirks (and mistakes) newer frameworks like Solid.js and Svelte have incorporated signal based state management into their core libraries.

As of now, React doesn't come equipped with a built-in signal based state manager.
Consequently, a significant number of new React developers, myself included (then I started), encounter the problems stemming from the issues mentioned above.

How to do state in react the right way

Use Query/Search URL parameters for saving and loading web app state.
- This should be the first and default choice
- Simplifying sharing with others and troubleshooting problems yourself
Combine state with data fetching with react-query
- This should be the second choice since you have to fetch data anyway
- Skip this option if you are using trpc or prefer not to use react-query
Using a signal based state manager
- Allows updating only the parts that change, called atomic updates
- jotai Is the signal based state manager I recommended, offering the best developer experience (in my opinion) as it eliminates the necessity to define and update a global store
- Or use one of the other signal based state manager libraries: Zustand, Valtio, React-Redux, Recoil, etc

Here is a more detailed comparison of react state manager libraries

The new wave of React state management - https://frontendmastery.com/posts/the-new-wave-of-react-state-management/
Comments Hacker News - https://news.ycombinator.com/item?id=31959289
Comments on reddit - https://www.reddit.com/r/javascript/comments/vpsuzt/the_new_wave_of_react_state_management/

Futher reading

Checkout the following link about the React ecosystem for routing, form handling, UI component, animation libraries and more

React Ecosystem in 2024 - https://dev.to/avinashvagh/react-ecosystem-in-2024-418k

Do I need a fetching library in React?

Adaptive Shield Matrix — Wed, 27 Jul 2022 10:37:43 +0000

Assumptions

server state - as a single source of truth
you want/need CSR

What does a fetching library do?

tracking loading and error state (ui spinner or notification/toast on error)
deduplicate requests (prevent race conditions, minimize requests)
manage cache (precisely control then to keep or revalidate data)
automatically re-fetch (on tab switching, network loss, periodically, pc/laptop sleep)

Why do I need deduplication?

if using React.strictMode (remounts all components twice, -just for fun- to be future proof for upcoming parallel rendering)
if calling the same API across multiple components
if opening the app in multiple tabs

Why do I need to manage the cache?

for fast/faster ui performance
to reduce server load or completely prevent an unresponsive/overloaded server

Why do I need automatic re-fetching?

if you experience a network disconnect and reconnect (data on the server may have changed)
if your pc/laptop goes to sleep and wakes up (a long time may have passed)
if you leave the tab open and browse elsewhere (again, a long time may have passed)

How to fetch

directly using (fetch/axios)
- (-) diy: ignore remounting in React.strictMode
- (-) diy: isLoading
- (-) diy: isError
useFetch (use-fetch)
- (+) loading state
- (+) separate result and error states
- (+) reusable
useSWR (swr)
- (+) built-in (in memory) cache
- (+) request deduplication - can call same api in multiple components
- (+) re-fetch/revalidate on focus - then switching windows/tabs
- (+) re-fetch/revalidate on network recovery - internet loss or then laptop goes to sleep
- (+) local mutation, optimistic UI updates
useQuery (react-query)
- (+) all from above
- (+) even more features
- (-) more complex, even the examples are complex, has more aggressive defaults (re-fetching every 2s)
Redux Query (rkt-query)
- skipped / not analyzed, since I already got burned by Redux's verbosity/complexity/overengineering on its introduction

Web app architecture

A fetching library influences how you structure a web app, it incentivizes you to structure your code in a way, that isn't obvious at first sight.

Web app architectures

centralized, top-to-bottom
decentralized, multiple fetch calls from different components

Centralized, top-to-bottom web arch

parent/root fetches all data and passes it down with prop drilling or react context
recommended by official React docs [1]
the most simple approach, works beautifully in small apps
very easy to reason about and debug
my recommendation: write a custom API that delivers all needed data in one fetch call, 1 api for each page
may not be possible in more complex web apps or if some parts need to be refreshed quite often

Decentralized web arch

each component fetches its own data
the only way to structure highly complex web apps
deduplication is a must-have feature -> a fetching library is required to be used

Downsides of using a fetching library

does not work with PWA / offline-first apps
- local/offline changes may/will be overwritten by fetching old server state
- may be circumvented / (-> need to write own custom logic -> how?)
CSR vs SSR: CSR may be more work than SSR.
- in SSR you just simply directly call the db and pass the ready data to the UI

(Not-)Alternatives

If applicable (no highly dynamic content)
consider using

SSR
Centralized, top-to-bottom web arch

SSR

is a much simpler approach and
you do not need to care about fetching or writing APIs at all
because all the calls happen on the server and you do not need to do extensive validation (or need to do less of it)