Setup foundation of centralizing user state

[paavanb]

This PR sets up the root components necessary to help us centralize the management and persistence of user state.

Description

I used a context-based state-reducer approach to give descendent components access to two values: UserState and UserStateActions.

• UserState contains the current state of data related to the user, while
• UserStateActions is an object consisting of functions that allow components to modify the user state (e.g. actions.setBirthDate(value)). Both of these are typed so that we don't make any mistakes while getting or setting these values.

Then, I created a component called UserStateManager which is like a "double context provider". It's the single component responsible for managing/persisting the state and defining the actions, which are then provided via the two context providers UserStateContext and UserStateActionsContext. It sits at the top of the component tree inside Layout. So far all it does is manage BirthDate and RetireDate.

Usage

To use it, check out Prescreen1a, which I partially migrated for managing BirthDate and RetireDate. All I needed to do was create a wrapper component that uses the useUserActions and useUserState hooks to pass the two values as props into the main component. The main component never has to worry about managing internal state anymore, and can become more or less a controlled component.

Computed Fields

The nice thing is that we can also define derived fields trivially. For example, I noticed that RetireDate is calculated using BirthDate, and we don't actually need to persist it to storage separately. Once all components are using UserState, we can just get rid of setRetireDate and have retireDate defined off of birthDate. Then, it will automatically update for all components any time birthDate changes!

Migrating

When we want to add new fields to the user state, all we have to do is:

1. Update the UserState type definition. That will flag Typescript errors in the user-state-manager file, so we'll know where we need to add those fields
2. If we want this new field to be mutable, update the UserStateActions definition. That will also flag Typescript errors so we add the right function definitions in the manager file

And if we want to convert a new component to use the state/actions:

1. Create a wrapper component that passes userState and userStateActions as props to the main component, and export it from the file instead.
2. Remove all the internal state-management and instead use the props to access and set the state value!

Persistence

In order to handle persisting to storage, I brought in the super-useful use-persisted-state library, which allows us to completely black-box the persistence behavior and just pretend as if we have a normal state variable like when using useState. We just tell it what key to store the value under, and we're done!

Eslint

I also set up a dead-simple eslint configuration because it's kind of necessary to use hooks. All it does it use the eslint-plugin-react-hooks plugin in order to warn us if we break the Rules of Hooks or forget a dependency in the dependency array. Later, we can extend well-known eslint configurations (like airbnb's) to more aggressively lint the project.

[thadk]

Looks great! Thanks for explaining.