Tech Story: [M3-8281] - Introduce Mock Service Worker v2

[abailly-akamai]

Description 📝

🔧 This PR implements the first iteration of MSW tooling V2.

🙏 I apologize for throwing 5000+ lines at you all. But hey, we may all benefit from this in the near future. It was already a bit too late to break it down when inherited then it grew some more. Apart for a few files, it is very contained code, and not bundled with our production application. To that effect it can be imperfect (and it is) and is very subjected to iteration and contributions.

👀 Please read the whole PR description before reviewing to manage certain expectations - especially regarding:

• the completeness of the new feature
• the contributions needed to grow it).

As we are reducing our reliance on ALPHA (lower env getting deprecated), development in Cloud Manager needs a better way of emulating what developing against a real API feels like. Our previous MSW tooling, while very helpful, is very static and lacks model relationships among other things (aka, update this volume which should update this linode).
This is a problem when moving forward with a feature we only can assume the behavior of, especially with the reactivity that comes with react-query.

While big and fairly complex, this contribution only builds the foundation for a full suite of tools aimed to facilitate local development for existing and new features. It features current best practices for building upon it by providing both simple and complex examples on how to mock our features.

Warning

This is (and will remain for a while) very much a work in progress! There will be bugs, which is acceptable considering this is a non-public facing development tool. I encourage contributions and engagement for the team who will end up benefiting greatly from fine tuning this suite. However, it needs to be used in order to grow, and for that reason can't be nursed forever, and needs to be merged as an in-progress suite. As such I also encourage contributions as feedback!

What it does:

• revamp the dev tools
• implements MOCK presets and CRUD-like mocking
• implements few convenient presets (API state, accounts, regions)
• implements few handlers partially (linodes, volumes, placement groups)
• sets up persistent mock data via indexedDB
• implements basic sorting and paginating mock data
• implements a seeding system for quick testing and emulating large accounts
• implements a custom API response time handler
• implements CRUD event tooling
• updates documentation

What is next

• implements more handlers for various content types as needed (we want to eventually deprecate legacy handlers)
• implement seeding for more content types
• improve reliability, stability and code quality
• team contribution!!

Note

While pushing forward a new approach, legacy MSW tooling is available as a baseline preset. We do want to write any new handlers in the new CRUD mode, but we can still use old tooling as "read-only", at least until the new suite is mature and well rounded.

CREDITS for @jdamore-linode for the initial effort and pushing for a brave new world 🤟

Preview 📷

How to test 🧪

Best way is to play with the tool and read along the documentation!

💡 I plan to pick and choose what feedback can be implemented as this point, since the PR is already large. Important bugs will be addressed, feature requests will be captured for subsequent tickets.

Important

Besides new tooling bugs, these are the two items we want to be confident about:

• not breaking existing MSW tools
• not introducing any issue bleeding to the production environment
• documentation. while far from exhaustive (this will need a lot of iteration), it needs to be accurate in its initial rendition

As an Author I have considered 🤔

Check all that apply

• 👀 Doing a self review
• ❔ Our contribution guidelines
• 🤏 Splitting feature into small PRs
• ➕ Adding a changeset
• 🧪 Providing/Improving test coverage
• 🔐 Removing all sensitive information from the code and PR description
• 🚩 Using a feature flag to protect the release
• 👣 Providing comprehensive reproduction steps
• 📑 Providing or updating our documentation
• 🕛 Scheduling a pair reviewing session
• 📱 Providing mobile support
• ♿ Providing accessibility support

[abailly-akamai]

An interesting omission which @jdamore-linode added initially. Def returned by the /regions endpoint. Not adding a changeset for it since it's not very impacting.

[abailly-akamai]

Mostly things moving around

[hkhalil-akamai]

Agree with switching Grids to divs -- no need for fancy themed components in devtools

[abailly-akamai]

It's a pretty large file, which could be broken down further (already exported some components, constants, types and methods)

[abailly-akamai]

This could be certainly be improved and that's on my list. In general this file is dense, complex and lacking optimization which I plan to work on and test. Out of scope for this first rendition as this isn't client facing code.

[abailly-akamai]

See handleRoot() definition. This fix is to circumvent HMR issues while developing Dev Tools. It should be non-impacting but need to point out the change in self review since it touches our APP entry point and needs to be looked at accordingly.

[abailly-akamai]

one very small thing with the CRUD preset when deleting Linodes - there was a very long delay for the Linode to disappear from the page in comparison with volumes/placement groups. Assuming this is because we first have to wait for the msw db to 'shut down' the Linode - is there a way to shorten the delay, or is that not in scope for this PR?

@coliu-akamai it is because we simulate a shut down + corresponding eventing so yeah it takes extra time. may be worth adjusting this later on