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
Story education viewer messaging. #27194
Story education viewer messaging. #27194
Conversation
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.
Approval for build-system/tasks/presubmit-checks.js
.resolves(); | ||
|
||
storyEducation.buildCallback(); | ||
await Promise.resolve(); // whenFirstVisible icrotask tick. |
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.
nit: s/icrotask/microtask
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.
Trying to fix this with the "suggestion" feature 👀
@@ -104,6 +118,23 @@ export class AmpStoryEducation extends AMP.BaseElement { | |||
true /** useCapture */ | |||
); | |||
|
|||
// Prevent touchevents from being forwarded through viewer messaging. |
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.
Should we remove these at some point?
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.
It's actually what has been discussed, the issue being that the second screen says "swipe" but if we don't prevent the touchevents from being forwarded, users would be sent to the next story. :(
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.
PTAL
@@ -104,6 +118,23 @@ export class AmpStoryEducation extends AMP.BaseElement { | |||
true /** useCapture */ | |||
); | |||
|
|||
// Prevent touchevents from being forwarded through viewer messaging. |
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.
It's actually what has been discussed, the issue being that the second screen says "swipe" but if we don't prevent the touchevents from being forwarded, users would be sent to the next story. :(
extensions/amp-story-education/0.1/test/test-amp-story-education.js
Outdated
Show resolved
Hide resolved
.resolves(); | ||
|
||
storyEducation.buildCallback(); | ||
await Promise.resolve(); // whenFirstVisible icrotask tick. |
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.
Trying to fix this with the "suggestion" feature 👀
@@ -51,6 +52,11 @@ const buildNavigationEl = element => { | |||
`; | |||
}; | |||
|
|||
/** @enum {string} */ | |||
const Screen = { | |||
ONBOARDING_NAVIGATION: 'on', |
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.
nit: maybe be more descriptive about what this screen is? These names (the minified on
version) are permanent since they'll be embedded in other viewers that we can't change, but I wonder if e.g. we experimented with multiple versions of onboarding, how we would tell them apart
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.
Do you mean descriptive as in adding a comment in our codebase, or changing the on
word to something more verbose?
If the latter, wdyt of something like: ONBOARDING_NAVIGATION_TAP_AND_SWIPE: 'ontas
?
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.
I meant the latter, and yep, your suggestion LGTM!
) | ||
.then(response => { | ||
const shouldShow = !!( | ||
response && |
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.
Man, optional chaining would be great.....
// screens, if/when needed. | ||
this.viewer_ | ||
.sendMessageAwaitResponse( | ||
'canShowScreens', |
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.
nit: I'm not entirely sure about making this plural; this seems like it could lead us to want to request multiple and cache the result, whereas I think the idea is to lookup can show at the instant the screen is to be displayed, in case things have changed
The inner object notation LGTM, but we should document
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 motivation behind making it plural is that we want to know how many total screens we are going to display at a given time to:
- Have accurate "Tip 1/n" labels
- Not animate out / animate in again between different screens
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.
But, this is one "screen" right? So (1) can't the tip labels be hardcoded? (2) would it do that?
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.
Maybe I'm over engineering this: if tomorrow we add more screens, say audio controls, we might ask players if they want to show the navigation screens, and the audio controls screen on load.
If we don't ask that in the same message, there might be a delay in between both screens causing (2), and inaccurate "Tip 1/n" hardcoded labels
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.
👍
I guess I'm also fine with an array and a comment on the format side that says we shouldn't cache these values
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.
Sounds good.
The format side should always display all the screens right away (one by one), but not store the response to be used later.
4b7bed4
to
43da571
Compare
d8a206b
to
db760c4
Compare
I'll merge this before the canary cut today cc @newmuis |
* Story education viewer messaging. * s/icrotask/microtask * s/on/ontas * Add comment to not cache viewer responses. * Update tests.
Story education viewer messaging:
EDUCATION_STATE
in the store service and expose it to viewers, so they can block swiping interactions while it's on if they're using native gestures#27097