feature/9348-DemoModeAPIOverrides

[Sparowhawk]

Description of Change

Added override api screen and setup each get/fetch api to check for override api and to throw the corresponding error supplied

Screenshots/Video

Screen.Recording.2024-09-10.at.4.05.53.PM.mov

Testing

yarn test

• Tested on iOS
• Tested on Android

Reviewer Validations

Currently there isn't an easily written detox solution for implementing errors from a backend. With this change, it will open us up to the availability of error testing in detox and make QA/VQA easier to manage if it's accessible through the developer menu.

PR Checklist

Reviewer: Confirm the items below as you review

• PR is connected to issue(s)
• Tests are included to cover this change (when possible)
• No magic strings (All string unions follow the Union -> Constant type pattern)
• No secrets or API keys are checked in
• All imports are absolute (no relative imports)
• New functions and Redux work have proper TSDoc annotations

For QA

Run a build for this branch

[theodur]

It's cool to see this in action! After digging into the PR, I noticed this approach requires all existing queries, and future queries to include the code snippet that iterates through the overrideErrors cache and throws an error if the query key exists there. Although this works, I'm not sure that this is the best pattern for mocking errors.

Instead of having a new query for storing mocked errors and requiring all query functions to check for errors in the new error query cache, I think integrating MSW for demo mode would be a better route, and would avoid the need to change query functionality to accommodate for demo mode. It would also avoid using React Query in an antipattern way as a global synchronous storage for errors. Integrating MSW would require us to change our demo mode infrastructure, but we were already planning on doing that.

We had a discovery ticket to investigate using MSW, but it doesn't seem like any follow-up tickets were made for integrating it into the repo. Ironically, I made one earlier today based off of a ticket to add documentation for demo mode. Even though it's a much bigger lift that needs to be planned for, I feel like MSW should be integrated into the repo, and the functionality for mocking API calls to return errors would stem from that integration

[Sparowhawk]

It's cool to see this in action! After digging into the PR, I noticed this approach requires all existing queries, and future queries to include the code snippet that iterates through the overrideErrors cache and throws an error if the query key exists there. Although this works, I'm not sure that this is the best pattern for mocking errors.

Instead of having a new query for storing mocked errors and requiring all query functions to check for errors in the new error query cache, I think integrating MSW for demo mode would be a better route, and would avoid the need to change query functionality to accommodate for demo mode. It would also avoid using React Query in an antipattern way as a global synchronous storage for errors. Integrating MSW would require us to change our demo mode infrastructure, but we were already planning on doing that.

We had a discovery ticket to investigate using MSW, but it doesn't seem like any follow-up tickets were made for integrating it into the repo. Ironically, I made one earlier today based off of a ticket to add documentation for demo mode. Even though it's a much bigger lift that needs to be planned for, I feel like MSW should be integrated into the repo, and the functionality for mocking API calls to return errors would stem from that integration

I agree. Ideally we would migrate over to MSW and I think we need to have that happen at some point. I do think this solution has some merit as a temporary work around until we migrate over to MSW.

[theodur]

@Sparowhawk If we really want this in before the MSW migration, have you looked into using the demo store for this? Since we already use the demo store for mocking API calls, I'd imagine we could have an error state for each get endpoint that's used to determine whether it should return the mock data or an error. That would keep parity with the current demo mode infrastructure, instead of intertwining 2 different libraries to handle mocking demo mode responses. It would also be safer to use the demo store because it avoids the need to update query logic that's used in production for the sake of handling demo mode errors

[Sparowhawk]

@Sparowhawk If we really want this in before the MSW migration, have you looked into using the demo store for this? Since we already use the demo store for mocking API calls, I'd imagine we could have an error state for each get endpoint that's used to determine whether it should return the mock data or an error. That would keep parity with the current demo mode infrastructure, instead of intertwining 2 different libraries to handle mocking demo mode responses. It would also be safer to use the demo store because it avoids the need to update query logic that's used in production for the sake of handling demo mode errors

I did and this is what I found trying to do it that way.

1. needlessly difficult and not customizable(relying on json files of preset errors that wouldn't really be editable how we would like)
2. We would need to specify exactly which api's as opposed to query keys initially(which for claims/appeals/prescription tracking/messages would be fairly difficult for us to navigate when using the feature)
3. speaking more of the customizable issue it would limit us to basically known errors and responses that we have seen previously, where this solution is a little more dynamic and allows us to input more or less whatever we would like and would be fairly expandable in the future.
4. The other concern was time to implement here for immediate benefit as opposed to having to migrate to msw first.
5. Lastly all the demo mode store mocks have slightly different ways in how they are determined to be run so each demo mode store would need a slightly different solution as opposed to a universal solution which msw and this method provide.

[dumathane]

I talked to Dylan and he is going to suggest a simpler route forward with this one.

[Sparowhawk]

I talked to Dylan and he is going to suggest a simpler route forward with this one.

I updated it to how I think it should best be handled at least at this juncture. @dumathane