Since there’s no server to handle the request here, I wrote a fakeFetchProducts function to fake a delay and then return the data. Like I said, there are a lot of ways to do this :) Working Code ExampleĬheck out this CodeSandbox to see a working version of this app. Soon (or maybe even now) you’ll be able to use React’s built-in Suspense feature to fetch and cache data.Use recompose to pull out the componentDidMount lifecycle into its own higher-order wrapper component – and although the library will keep working, it seems its creator has decided to stop working on it in light of React’s new hooks feature.Then the “Page” takes care of fetching, and the “List” just accepts data and renders it. Make a wrapper component to do the fetching – in the above example, that might be called ProductListPage.Use a library like redux-dataloader or redux-async-loader or one of the other libraries from Mark Erikson’s list of data fetching libs.Have the component call the API module directly, and then dispatch the action from inside the component when the data comes back, like Dan Abramov shows in this video.Move the API call out of the Redux action and into an api module, and call it from the action.If you don’t like the idea of doing it this way, though, here are some other things you could try: “Fetch the data in componentDidMount” is not the one true way, but it’s simple, and it gets the job done. There is no “best way,” because these things exist on a spectrum, and because the “best” for one use case may be the “worst” for another. There are many many ways to factor this code. They might require more code instead of less. Magic data loaders are magic (harder to debug, harder to remember how/when/why they work). There are ways to fix this, but as with everything, they come with tradeoffs. Then components could be blissfully unaware of any dirty API nonsense they could simply wait around to be handed data on a silver platter. But The Component Shouldn’t Have to Fetch!įrom an architecture standpoint, it would be nicer if there was a parent “thing” (component or function or router or whatever) that automatically fetched data before it loaded the components. This gives you an opportunity to make that user experience shine. You probably don’t want to just show a blank screen until the data is ready. Think of it this way: the app needs to show something when there are no products, or when they’re loading, or when there’s an error. If you’re working on an app where they are slow enough to notice, do some profiling and figure out why that’s the case. You may be worried about unnecessary renders because of performance, but don’t be: single renders are very fast. The horror! 3 renders! (you could get it down to 2 if you skip straight to the “loading” state) It will render in an empty state, then re-render in a loading state, and then re-render again with products to show. Pass the error flag and the message (if you have one) into components that need to handle errors, and condtionally render the error however you see fit.Handle that FAILURE action in the reducer by setting some kind of flag and/or saving the error message.Dispatch a FAILURE action when the call fails.The error handling here is pretty light, but the basic structure will be the same for most actions that make API calls. const store = createStore ( rootReducer ) Error Handling in Redux Import rootReducer from './rootReducer' //. To make this work, we can write a rootReducer.js file that pulls them all together: because I’m making the assumption that you’ll probably have more than one reducer, each handling its own slice of state. I’m referring to the data with state.products. Export function fetchProducts () ) export default connect ( mapStateToProps )( ProductList )
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |