You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 17, 2023. It is now read-only.
We currently store isInstalling on the install button's component. If this is stored in the Redux store, the email modal component would be able to monitor its value and pop up whenever it changes from false to true, rather than needing to be manually-triggered.
There's a lot of good discussion about this out there:
There is one important benefit to everything going into the Redux store: it turns your app into a finite state machine. The Redux store becomes the input, and the output is the rendered DOM. This makes some good things easy: testing complex interactions between components, time travel, bug reproduction, and testing.
For the sake of being consistent and explicit, I'd suggest implementing a guideline to not use component state, instead putting everything into the Redux store and passing values down as props.
The text was updated successfully, but these errors were encountered:
In most cases, things you'd consider storing as component-level state may be helpful for other components to know. For example:
testpilot/frontend/src/app/components/MainInstallButton.js
Line 11 in 622e528
We currently store
isInstalling
on the install button's component. If this is stored in the Redux store, the email modal component would be able to monitor its value and pop up whenever it changes fromfalse
totrue
, rather than needing to be manually-triggered.There's a lot of good discussion about this out there:
reduxjs/redux#1287
http://redux.js.org/docs/FAQ.html#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate
There is one important benefit to everything going into the Redux store: it turns your app into a finite state machine. The Redux store becomes the input, and the output is the rendered DOM. This makes some good things easy: testing complex interactions between components, time travel, bug reproduction, and testing.
For the sake of being consistent and explicit, I'd suggest implementing a guideline to not use component state, instead putting everything into the Redux store and passing values down as props.
The text was updated successfully, but these errors were encountered: