Correct way to invalidate data in redux store when working with API?

Question

RESTful API

Hello!
Often, when working with redux and api, a problem arises, the store stores data that is not relevant for the current moment.
I will give an abstract example:
There is a form of comments. When a comment is sent, a POST request is made to the server, the server may return different responses, 200, 401, 403, 422, 500. Depending on the server response, a certain Failure Action is triggered and some error will be sent to the store. The component that is attached to the store receives the props and throws an error on the page. Next, the user navigates the site (SPA) and returns to the page with comments, where our error is safely displayed again, although in theory, the error refers to the previous request.

I see several solutions, but not sure if they are good:
1. When unmounting the component (leaving the page), reset the state of the request. It turns out that for each request we have an Action that will return the state to its original state. If there are a lot of such requests on the page, there is a chance to forget something somewhere. In my opinion, the solution is not the best.
2. Add some unique identifier or timestamp to the Failure Action or Succes Action and make a comparison in the component. If it is a timestamp, then comparison with the current time plus some margin of error. This option seems to be better, but it is embarrassing that some undefined value appears.

I admit that I may be doing something wrong, making a mistake when designing or implementing, but I want to figure it out and understand how it is right.
Colleagues, how do you solve this problem?

Answer 1

The first thing to understand is that the logic should be distributed over individual functions / actions. The second thing to remember is that the components should be as simple as possible. They should act as an intermediary between the application logic and the template. It follows that the responsibility of the page component is only to notify the application about a change in the state of the page itself (logged in\logged out\maybe_something_else_like_passing_data_of_a_specific_route). Very little cognitive load.
But modern applications are often very complex and require a lot of logic, which was discussed in "first" and which should be concentrated in actions (in / out). That is, actions should be a tree-like structure of calls.
The situation with the error message that you identified as a problem is quite normal for a spa + single app state. Now, if you had an event model, then you would not have encountered such a thing, but you also had to make nonsense if you needed to save the last state. Therefore, while only one architectural approach is used when building an application, this is inevitable.
You voiced the decision - you need to start actions that reset the error state. All other solutions will be just unnecessary abstractions over this.

Answer 2

A small hack is to hide such messages by timeout.
The second small hack is to use one component to display notifications on all screens. Initialized alert with message(“server error”) and type(“error) and hidden by callback after 3 seconds. The alert is not visible and waits for a new call from any component.
Keeping a state is cool. But the context data should not persist if the context has changed. It's just illogical.