-
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
Focused Launch: Add persistent success view after launch #47808
Focused Launch: Add persistent success view after launch #47808
Conversation
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Async-loaded Components (~83 bytes added 📈 [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. |
@ollierozdarz Another open point is when to use this behaviour:
|
@razvanpapadopol I think we should try delay this by a couple of seconds (let's say 2 seconds) once a user enters the editor - that way it doesn't feel like a bug or so jarring. If we can add some CSS easing (ease-out) to the Thank you page/modal as well then it'll also take the edge off. |
696bbfd
to
d8decc5
Compare
91ec62b
to
b51e1b8
Compare
d8decc5
to
8a7a404
Compare
b51e1b8
to
3c435ce
Compare
It took a while, but I should have correctly rebased this branch on top of All checks should pass now — I'll start addressing the remaining feedback |
packages/launch/src/launch/index.tsx
Outdated
@@ -35,6 +35,9 @@ const FocusedLaunchModal: React.FunctionComponent< Props > = ( { | |||
const isModalTitleVisible = useSelect( ( select ) => | |||
select( LAUNCH_STORE ).isModalTitleVisible() | |||
); | |||
const shouldDisplaySuccessView = useSelect( ( select ) => | |||
select( LAUNCH_STORE ).shouldDisplaySuccessView() | |||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More of a curiosity of mine, but I wonder if it'd be more efficient to select
from the Launch Store only once:
const { isModalDismissible, isModalTitleVisible, shouldDisplaySuccessView } = useSelect(
( select ) => {
const launchSelect = select( LAUNCH_STORE );
return {
isModalDismissible: launchSelect.isModalDismissible(),
isModalTitleVisible: launchSelect.isModalTitleVisible(),
shouldDisplaySuccessView: launchSelect.shouldDisplaySuccessView(),
};
}
);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally I think we should call useSelect
only once in a component if the dependencies Array (second argument of useSelect
) is the same and in this case is undefined
.
Example with deps: https://github.com/Automattic/wp-calypso/blob/trunk/client/landing/gutenboarding/hooks/use-free-domain-suggestion.ts#L15-L26
Example with multiple stores accessed in one call: https://github.com/Automattic/wp-calypso/blob/trunk/apps/editing-toolkit/editing-toolkit-plugin/wpcom-block-editor-nav-sidebar/src/components/nav-sidebar/index.tsx#L47-L57
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the change in 9fc3bc7
I'm not going to create a janitorial issue for this but let's keep in mind and use this pattern at least until we have something better from readability & performance PoV.
FYI @Automattic/luna
This part should be addressed (needs to be reviewed / tested)
@ollierozdarz Just to make sure, what do you mean by "Thank you page/modal"? |
Hey @ciampo, sorry, confusing wording 🙂 This is the page I'm talking about: |
// @TODO: | ||
// - if this is a block editor specific feature, move to the LaunchContext | ||
// and only specify when including Focused Launch thorugh Editing Toolkit | ||
// - think about a less hacky way to achieve this (e.g. @wordpress/hooks?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Let's move this to Editing Toolkit for now since this side effect is applied only inside the editor (hiding the Launch button).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 1a7836f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if we should still add a janitorial issue to implement this functionality in a less hacky way? Adding a class to the body
works for now but it's not very robust
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it is 👉 #47988
It's not assigned to any milestone since this more a general [editor - launch] integration issue.
Caution: This PR affects files in the Editing Toolkit Plugin on WordPress.com D53663-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing the Editing Toolkit Plugin for more info: PCYsg-ly5-p2 |
d5b58b6
to
9fc3bc7
Compare
* Update isFocusedLaunchOpen to use shouldDisplaySuccessView * Use shouldDisplaySuccessView to render Success view as the initial route when opening Focused Launch * Dispatch hideSuccessView when interacting with action buttons on the Success view
…tSuccessView and disablePersistentSuccessView
9fc3bc7
to
dcae170
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first round of feedback has been addressed. Probably better if someone who hasn't worked on this PR has a look too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The success view is truly persistent, even after refreshing the block editor, it shows up until user clicks on one of the buttons.
Code wise, in a nutshell, everything revolves around these 3 things:
- shouldDisplaySuccessView
- enablePersistentSuccessView
- disablePersistentSuccessView
LGTM. Tested. Good to go.
@donlair should the interstitial offer above be shown during the launch flow as well as signup? Is it supposed to be seen after all checkout experiences? I agree that it deflates the launch flow a bit, but wanted to confirm the intention. |
@rickybanister we'll prevent any redirect from Focused Launch after completing checkout and display the Success View which was designed by @ollierozdarz exactly for this purpose. More details in #48081 |
Changes proposed in this Pull Request
There are two special cases after launching a site from the editor using Focused Launch:
In these cases, when returning to the editor, Success View is displayed.
Testing instructions
Run the project locally
yarn && yarn start
cd apps/editing-toolkit && yarn dev --sync
Open the Focused Launch modal
/start
to your sandbox (for convenience,SITE_ID
)calypso.localhost:3000/page/SITE_ID/home?flags=create/focused-launch-flow
and click on the "Launch" button. The Focused Launch modal should appear.Focused launch — selecting the free options
Run the project locally
andOpen the Focused Launch modal
sectionsFocused launch — selecting paid options, but exiting checkout without paying
Run the project locally
andOpen the Focused Launch modal
sectionsFocused launch — selecting paid options, with successful payment
Run the project locally
andOpen the Focused Launch modal
sectionsFixes #47392
(it fixes #47392 only partially, but it is the last spec left in that issue)