Redux vs sharing state to components as props from top level-CodePudding

I have minimal experience with react-redux and am developing a smaller, web-based, (currently) non-redux application designed for use by about 100 users.

I have been avoiding using redux as it seems it would be too complex for such a small app. I have been making api calls in child components and passing the response in callback functions to the top level component, storing it in state and then passing the top level's state as props to child components as needed. I'm doing this because it seems like it would reduce the number of api calls I need to make in each component.

Is this a bad practice? And, somewhat related, what are the general thoughts on what should be stored in state/props vs how often to make api calls and get the data from the server? Is it common practice to make the same api calls in different components across the app?

CodePudding user response：

It sounds like what you're looking for is Context which is built into React.

Around 2016-2017, React's Context API was experimental. Developers needed a top level state API that was stable and easy to use, and Redux was the answer. If the internals of React's Context API changed, that would be handled by the Redux team, and developers using Redux didn't have to worry about making any changes to their apps.

In 2022, Redux isn't needed. A co-creator of Redux (Dan Abramov) has said this publicly. React's Context API solve some of the problems that you're facing, but not all.

One remaining problem is managing server data. To manage server data, you can use a variety of options, including SWR, React Query, and many other options depending on your use case (i.e. Relay for GraphQL data).

But you could also use Context for all server data and make the decision to use something specific for server data later on when you know more about what problems you are looking to solve.

Is this a bad practice? And, somewhat related, what are the general thoughts on what should be stored in state/props vs how often to make api calls and get the data from the server? Is it common practice to make the same api calls in different components across the app?

This blog post by Kent C. Dodds will answer those questions. In general, you want to keep your React state as close to the components that need that state as possible. When two or more components need the same state, you can lift that state up the React tree, but no higher than it needs to be, for performance reasons that are explained in that blog post.

CodePudding user response：

If your application is small, and your end objective is to reduce the number of API calls, you can either use the suggested useContext or you can use useSWR

Example use of useSWR

    const fetcher = (url) => fetch(url).then(res => res.json())

    const Component = () => {
       const { data, error } = useSWR('/api/url/', fetcher)

       ... do something with the data

    }

    const ChildComponent = () => {
       const { data, error } = useSWR('/api/url/', fetcher, { revalidateOnMount: false }) // load from cache

       ... do something with the data

    }

The name “SWR” is derived from stale-while-revalidate, a HTTP cache invalidation strategy popularized by HTTP RFC 5861. SWR is a strategy to first return the data from cache (stale), then send the fetch request (revalidate), and finally come with the up-to-date data.

By using the desire options, if your parent uses e.g. useSWR('/api/url', fetcher), your child can use useSWR('/api/url', fetcher, { revalidateOnMount: false }) so the data is automatically loaded from cache (from parent component).

The cache is identified by the cache key, e.g. /api/url. Compared to useContext, it avoided alot of unnecessary re-rendering (useContext rerenders the entire component wrapped by Provider).

You can read more from the docs.