I have a situation when it would be really convenient to have a promise object as a part of the state. In short - there is a state which contains all the info which user gave in the question-answer mode and after some answer it would be nice to send a call, result of which will be needed after several more questions:
Q1 -> Q2 -> Q3 - -> Q4 - - -> Q5 -> Q6 -> Q7
\ - - Call to API - - /
Before Q7 I need to check result of call after Q3. It would be really easy to do with promise as a part of the state and then just subscribe to result. But I have inner feeling that it should not happen. Is it ok to do it this way?
I don't think that my code will help to understand, so feel free to just ask questions if it's not clear.
You should not do that because serializing your state would not be possible anymore. How much of a problem that is, not sure, it might only break the devtools or some persistence/hydration library you are using or will use. But to stay true to redux and its simplicity, reduce your scenario to a single truth:
Based on that you send the request:
if (currentQuestion > 3 && currentQuestion < 7 && !isDataRequested) {
dispatch(callToApi()); // this sets isDataRequested to true.
}
This will work with persisting and hydrating the state.