-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add/comingsoon v2 calypso #45606
Add/comingsoon v2 calypso #45606
Conversation
Taking great inspiration from #43831
Renamed wpcom_coming_soon_mode to wpcom_coming_soon
- private the singleton constructor - and a bunch of phpcs workarounds
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Webpack Runtime (~88 bytes removed 📉 [gzipped])
Webpack runtime for loading modules. It is included in the HTML page as an inline script. Is downloaded and parsed every time the app is loaded. App Entrypoints (~134 bytes added 📈 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~54709 bytes added 📈 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Async-loaded Components (~2200 bytes removed 📉 [gzipped])
React components that are loaded lazily, when a certain part of UI is displayed for the first time. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
Fixed some broken tests then fixed a couple of logic errors moving from v1 to v2. I think I have this right but definitely need some eyes on it, was testing the difference between what happens when loading settings on wpcom vs calypso and swapping between the two to see the difference. I applied the filters in #45604 to my 0-sandbox.php for testing without needing anything from #45581. I'm glad we've split these / kept them separate now as I think it would have confused things a fair bit. ... Just watching the full test suite run, looks like some integration tests need updating after the UI change:
|
Testing D49571-code got myself into a WSOD on wpcom (live) using a test account. Suspect my testing here caused/got the settings into an incompatible format. (calypso.localhost worked fine) See slack for user info if you want to have a look. I think if we want to feature flag this we may need to support both old and new settings at the same time. Feature flag would just control which settings UI is displayed. Thoughts? |
Bit of a WIP state, trying to get tests to pass before adding v1 support back in behind a feature flag. (I have a hunch its going to be easier to add v1 support to v2 than the otherway around) Phil's |
Should be green now Todo: - Add coverage for the extra scenarios especially for the transition period from v1 to v2. - Remove old tests as they'll probably be redundant (keeping them around for now as a baseline)
Pretty sure these are correct (except the last one) Currently 4 failures which I need to confirm in the UI as happening and fix or that my test case is not needed / incorrect.
Changes proposed in this Pull Request
Testing instructions
Fixes #