Always re-calculating current confirmation from redux state
Current confirmation is queried at about 20 places in the code currently, this count will increase as we port more and more confirmations to new designs.
I found that there was a very small optimisation in using current confirmation from redux state, about 10-100 ms. But this makes case of continuing use of confirmation from redux state.
Another food for thought at this stage is - as we started on confirmation re-designs our initial thought was to put all state in redux - transient or persistent. We ended up introducing context also for transient state, using context for this transient state is a convenient pattern. Should we move current confirmation also to context ? Where should we prefer to keep transient UI state - redux vs context ?
I checked the 2 scenario:
Current confirmation is queried at about 20 places in the code currently, this count will increase as we port more and more confirmations to new designs.
I found that there was a very small optimisation in using current confirmation from redux state, about 10-100 ms. But this makes case of continuing use of confirmation from redux state.
Another food for thought at this stage is - as we started on confirmation re-designs our initial thought was to put all state in redux - transient or persistent. We ended up introducing context also for transient state, using context for this transient state is a convenient pattern. Should we move current confirmation also to context ? Where should we prefer to keep transient UI state - redux vs context ?