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
Hbergam/signin callout UI #38953
Hbergam/signin callout UI #38953
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.
Also, could you paste an image on the component in the PR description? That makes it easier for reviewers to get some context about what the component looks like and how it fits in with existing pages/components. Thanks!
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.
@hannahbergam do you think you could include a screenshot of the component in the PR description? I'm a super visual learner so it would help me get some context
Yes! Thanks for the reminder. Done |
Yes- great reminder. Done:) |
…rn from empty div to null
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.
SignInCallout.jsx looks good. I think the wrapper could go in a separate PR, especially since it doesn't have tests yet, but up to you.
const HideSignInCallout = 'hide_signin_callout'; | ||
|
||
// The use of both session storage and cookies is to check for 1 day | ||
// and 1 session, and display the callout again only once BOTH have passed. |
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'm curious about why we need to put this value in session storage?
Also, is it possible to set the cookie for something like 20 hours? I'm thinking of the scenario where a student always does the activity at around the same time each day and wondering if the behavior might be weird if they do a level without seeing the popup and then see it on the next level. (Ideally I think we would want to reset this in the middle of the night each day.)
Finally, did we decide if we wanted to cap the number of times we show the callout (or just continue to show it once a day)?
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 spec stated that we wanted both, so if a student opens the same window the next day (example: student works on it at 2, and opens it again at 2:30 the next day), they don't see the message again in the same session. In fact, I think the use case for both is exactly what your example is actually covered by.
Even if the cookies flag expires, the student's session flag would still prevent it from being shown again unless they started a new lesson in a new window.
There was nothing stated in the spec about limiting the number of overall times it is shown, so I haven't included 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.
I see. I think the common case might be that students close their browser and open a new one the next day (e.g. this is what they teach my kids to do when using school laptops) but we can start with this and refine it if we get feedback.
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.
Hmm I definitely see what you mean re: students are closing down entirely and starting fresh the next day. And I guess in that case, I'm not sure what the most desirable behavior is (to your point earlier: the solution is potentially a midnight refresh time, which isn't currently set up with either of these tools). I'll keep as-is for now, and be ready to strip out session storage/refine cookies if needed!
|
||
// The use of both session storage and cookies is to check for 1 day | ||
// and 1 session, and display the callout again only once BOTH have passed. | ||
export default class SignInCalloutWrapper extends React.Component { |
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.
Could you add a header comment describing what this class does? (It's not immediately obvious from the name and I can't think of a better name.)
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.
So today I came across all of these Dialog components, which is kind of similar to what we're building here. There's a BaseDialog which handles whether the dialog is displayed, we could name this component SignInCalloutDialog
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 agree that there's some similarities, especially around the modal interactions, but the placement differences (anchored to an item vs. centered on the page) seems significant to me. My feeling is that we will eventually want a Callout component that's a peer of BaseDialog?
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've added a comment that hopefully can make it more clear! In regards to the comments about labeling this 'dialog'- it would seem more intuitive to me if the actual render/text component were labeled "dialog", as it's including what will be displayed (instead of the logic determining when it shows up). I'm definitely open to more discussion though.
Thanks! I think I wanted to keep it in here partially because we've already done so much to review it, and also because the current tests use it (though it isn't yet tested completely). I'll be sure to write a bunch more detail about it (and tests for it) in the next PR as well. |
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.
Other than renaming getContent to renderContent, looks good to me! Nice work!
…nd made onclick required
This is the visual component for the Sign In reminder popup.
It will appear attached to the header in code studio for CSF courses only, but this PR only represents the component without any of the attachment logic.
The cookies and storage logic are built here, but will be tested explicitly in the next pr.
Testing includes a test for the callout to render when its state says it should, and to be hidden otherwise. There is also a test to check that the background opacity is as-set at 0.5 instead of the default 0.8.
https://codedotorg.atlassian.net/browse/LP-1595