ethanjli
commented
3 years ago @rohanpurohit This PR will almost certainly produce merge conflicts with your other open frontend PRs, we'll need to coordinate on how to merge things - i.e. for PR of yours which we merge into develop first, I'll need to make sure I understand every changed line of code, as I'll probably need to manually "replay" all of your changes on top of my changes. And for any PR of yours which we merge into develop after this PR, you'll need to understand what I changed and what assumptions you may have made which might be violated by the changes I've made in this PR.
rohanpurohit
This PR fixes #312 by making the frontend initialize all backend-derived messages in the store to
nullon startup, instead of initializing with numbers or default values. Because implementing this required changing the types produced by selectors for those messages, as well as changing the reducers forParametersRequest,AlarmLimitsRequest, and their standby versions (mainly because those reducers previously had inconsistent implementations and were difficult for me to understand), it led to a large refactor of the store-related code in the frontend (including improvements in organization, naming), with the following main changes:@controller/PARAMETER_COMMITTEDaction) and updateCommittedState (which could generate a infinite number of possible actions with the template@controller/{string}_COMMITTED), except one could theoretically also use updateCommittedState in place of updateCommittedParameter, and action types were unnecessarily stringly typed. Now we have exactly two actions: commitRequest and commitStandbyRequest, and the message type is specified as aMessageTyperather than a string, and the action generators work with Typescript to ensure that the data provided with the action matches the type constraints for the provided message type.alarmLimits,alarmLimitsRequest, andalarmLimitsRequestStandby), now they're broken up into fragments and organized in a more logical way (e.g.alarmLimits.current,alarmLimits.request, andalarmLimits.standby) in a pattern established by a reorganization I did of the event log-related parts of the store in #313, which movednextLogEvents,expectedLogEvent, andactiveLogEventsintoeventLog. This reorganization allows us to make generic, composable selectors instead of copying the same logic copied over and over. Previously, updating the code would've required way too much copy-pasting, and updating the code would've been error-prone (forgetting to update something in one place). Now the copy-pasting is restricted to copying a function call and just changing its arguments.BACKEND_HEARTBEAT&BACKEND_CONNECTION_LOSTstore logic from controller to app. This is in preparation for moving all connection-related logic into its own slice of the store.Additionally, now the backend sends the following messages to the frontend: AlarmMuteRequest, BatteryPower, ScreenStatus, RotaryEncoder, SystemSettingRequest, and FrontendDisplaySetting. However, the backend doesn't simulate these messages or load them from the filesystem during initialization; instead, the backend simulator merely initializes some default values; the frontend does indeed receive them from the backend.