Bugfix/google login returns to donations first step

[momchiii]

Google login returning to step 1 of the donation flow is fixed. Also the donation flow data is now stored in local storage and
lives there until the donation is completed or the user chooses to donate to another campaign. This way the users input will be
saved and he won't have to input everything again if he makes a mistake, like reloading the page etc...

PS: My main goal was to change as little as possible from the donation flow's implementation.

Closes #1260

Steps to test

Test the bugfix:
1.Initiate a donation without being logged in
2.Login via Google

Test where the donation flow data lives:

1. play around with the donation flow.

Affected urls

The whole donation flow

Environment

Local

[github-actions]

✅ Tests will run for this PR. Once they succeed it can be merged.

[dimitur2204]

@momchiii I think that we should think of a more elegant way to solve this. Nice work on making it work, but we can maybe think of some kind of more elegant adapter from local/session storage to the formik context.
Or even more generally, the context of the donation-flow itself (that would require creating a context or extending the StepsContext).

One way to do it might be to save the FormikContext and the StepperConext values after every step change. Then as initialValues to the Formik and StepperContext you can provide the ones from local storage

[momchiii]

@dimitrur2204 Firstly I extended the StepsContext to take the donation data not only the step, but then I started thinking that we don't need another state for the data because we already have it inside the formikContext. Why would we want to store the data one more time? Now the local storage is updated on every submit(next step click) and the formikContext sync with localStorage is done on every first render of each step based on some checks. This is done like that because the validation is done on the formikContext, meaning that even if we have another storage for the donation data we'll still have to update the formikContext because the next button won't be clickable. I tried doing this task in many ways, but every time there was some edge case which breaks the flow. I'm not sure that I'll be able change the implementation because I have been transferred to another project.

PS: The stepsContext is handled like you said, but the whole stepper is handled with formik and I don't think that there is an elegant way of handling it, one reason is that the initial state when you go from step 1 to step 2 will be only the data from step 1, which will trigger typescript to throw type mismatch error (I'm not sure about that).

[dimitur2204]

@dimitur2204 Firstly I extended the StepsContext to take the donation data not only the step, but then I started thinking that we don't need another state for the data because we already have it inside the formikContext. Why would we want to store the data one more time? Now the local storage is updated on every submit(next step click) and the formikContext sync with localStorage is done on every first render of each step based on some checks. This is done like that because the validation is done on the formikContext, meaning that even if we have another storage for the donation data we'll still have to update the formikContext because the next button won't be clickable. I tried doing this task in many ways, but every time there was some edge case which breaks the flow. I'm not sure that I'll be able change the implementation because I have been transferred to another project.

PS: The stepsContext is handled like you said, but the whole stepper is handled with formik and I don't think that there is an elegant way of handling it, one reason is that the initial state when you go from step 1 to step 2 will be only the data from step 1, which will trigger typescript to throw type mismatch error (I'm not sure about that).

I see what you mean. I was more thinking some way to abstract that local storage saving logic in some way. I am unsure actually how exactly. Considering also the new flow will be very much different than this current implementation if we want to reuse anything it would have to be very abstracted.

What I am thinking is to somehow wrap around Formik itself and save to local storage based upon some event that Formik exposes

[dimitur2204]

What I am thinking is to somehow wrap around Formik itself and save to local storage based upon some event that Formik exposes

@momchiii About that take a look at #1260 (comment)

[igoychev]

closing in favor of #1533