Redux/sagas: Approach for larger API's

Question

I've worked with Redux/sagas workflows on small projects based off of this real-world example, but the logic of those is not nearly as complex. How should I be approach working with a more comprehensive api (i.e., Reddit's API), without making things overly verbose?

• Do I make a const for every endpoint? i.e., export const fetchUser = login => callApi(`users/${login}`, userSchema)
• Should I be worried about managing the entity cache?
• Is there a way how to further reduce complexity/boilerplate (i.e. further grouping request types with get/put/post/delete for the same endpoint)?
• Are there any examples out there that deal with bigger/more complex than the real-world?

Answer 1

I think the answer depends on how fluid you want your components to be.

I'm working on a large codebase using sagas, our pages are separated into "types", for example a "list" type, "form" type etc.

We have one saga responsible for fetching content, while each pageComponent when being rendered is responsible for supplying the endpoints.

this allows a very modular approach, to add a component you need to deal with one subsection of your file system.

Our pages are mostly a configuration file that contains all this information, and we use this configuration to render a "generic" component with the correct data.

Saga reusability

I see Sagas as sequential processes, they can be for async fetching data, but they're also useful for anything that needs to be dealt with in sequence.
These "Flows" are sometimes very similar in a codebase, and those are the ones you want to generalize.
Like you said, the most common operations are CRUD for any endpoint, that can be easily grouped together.

Login is extremely different than loadUserList and different things need to happen afterwards, however loadUserList and loadRepoList is extremely similar.

Things that impact reusability

1. Your ability to control your API's, if you can dictate the shape of the API you consume, you can get away with even more generalizations in front end.

2. The shape of the application(Front-wise) - are your pages strangely dependent on one another's state? for example it's not uncommon for insurance programs to have forms that link to one another, you can fill the first 3 forms in any order you want, but once all three are complete the 4th unlocks.
   Each of these dependancies will normally have their own saga that controls the flow of your use story.

3. Does your application require syncing? You can easily create sagas that automatically sync data with your different endpoints and update your Redux State, there's much to consider here, including if we decide to interrupt the user with new data(we might want to let him know that the form he's editing has out dated data) - syncs require a distinct saga as there are usually various business rules when to sync what data - if the rules are very different this can force you to create multiple sagas)

Common Sagas that can be unified

1. UserSagas - login, logout.
2. FetchData - fetch a single record, or a collection.
3. DeleteData - Delete a single record, or a collection of IDs
4. Data Syncing - Updating your local data from a remote periodically.

Regarding the entity cache

Entity cache is just a name they picked, but this goes back the points mentioned before.

Does your application run on stale data, or do you fetch from the server every time your component is loaded?
If the data is only fetched once and you display stale data, you'll store it in a type of cache(that's basically the redux store).
If you show stale data, this is the way to go.