-
Notifications
You must be signed in to change notification settings - Fork 5
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
feat(callbacks): device-profile-node addition #121
Conversation
Your preview environment pr-121-ryanbas21 has been deployed. Preview environment endpoint is available here |
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.
Just leaving some comments since I was looking over the code. Can you remove all the files in the components/compositions
and components/primitives
directories. I think that's leftover from a misunderstanding of the story.
src/lib/journey/callbacks/device-profile/device-profile.mock.ts
Outdated
Show resolved
Hide resolved
849ac8b
to
fda7a37
Compare
// because this is a a function now, i'm using the function defined so | ||
// the memory is the same and its picked up as such by toEqual. |
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 think I know what you mean here, but could you reword and clean up the comment a bit for better clarity?
b4ce64a
to
88b56dc
Compare
// because this is a a function now, i'm using the function defined so | ||
// the memory is the same and its picked up as such by toEqual | ||
// rather than creating a new function which would be different | ||
// in memory. |
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.
If this comment is going to persist in our source code, let's ensure it's written well.
/**
* Unlike the other properties, `isStepSelfSubmittable` is a function,
* so for `toEqual` to pass, the "expected" object needs to reference
* the same function as the `result` object.
*
* TODO: Modify this to assert against the returned value, rather than
* relying on function reference.
*/
const location = cb.isLocationRequired(); | ||
const metadata = cb.isMetadataRequired(); | ||
|
||
const dvice = await device.getProfile({ location, metadata }); |
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.
Rather than relying on a misspelling of "device", can we just call name this profile
or deviceProfile
?
|
||
import { asyncEvents } from '../../utilities/async-events.js'; | ||
|
||
test('Inline widget with login in Canadian French', async ({ page, context }) => { |
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.
Looks like the test name needs rewording.
await page.waitForRequest(/\/authenticate/, async () => { | ||
const text = page.getByText('Collecting Profile'); | ||
await expect(text).toBeVisible(); | ||
}); |
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 believe this is redundant as the clickButton
already accounts for waiting until the request is resolved. Once clickButton
itself resolves, you can test whatever you expect to be in the next view.
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 idk this was required for me to get it working.
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 device profile text disapeared too quickly.
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 pulled this in locally, and I believe I know what's happening. This block of code is never executed. So, the assertion is never applied, which gives you a false sense of "passing". The reason for this is the /authenticate
request is already resolved within the clickButton
method, which is awaited, so the following waitForRequest
event listener is never triggered. If you write a console message within it, you'll never see it logged.
The reason it doesn't work when it's not wrapped in this waitForRequest
is because the "Collecting Profile" message is never displayed by the UI, ever. It's not that it disappears to quickly. You can see that the message is missing in your GIF provided in the PR description.
That's due to the fact that the node in the journey uses message
as the key. Keys have to be locales or languages, so the key would be en
or en_US
with the value of "Collecting Profile"
. Once you change the key to en
you can then directly assert using the below without wrapping it in a waitFor*
:
await expect(page.getByText('Collecting Profile')).toBeVisible();
const text = page.getByText('Collecting Profile'); | ||
await expect(text).toBeVisible(); | ||
}); | ||
await context.grantPermissions(['geolocation']); |
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 feel like this test isn't finished. We don't seem to be asserting anything, just granting a permission. Can we write this so we assert something regarding device profile to ensure the profile is being generated?
88b56dc
to
c09376e
Compare
c09376e
to
86c3b7a
Compare
86c3b7a
to
7485481
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.
I think this looks great overall. Great improvements. We do have a failed test, and accidential file commit, and some small changes, if you don't mind.
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.
We should probably add a story within this that composes device profile with a standard login form ... Just to ensure it composes well without breaking.
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.
Have you addressed this comment? I don't see this in the updated code.
7485481
to
f082993
Compare
f082993
to
7495dc4
Compare
7495dc4
to
8644839
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.
This looks good. I just have a question about the README and the missing change that addresses the comment I made a week or so ago about Storybook stage story to ensure device profile composes with a typical login UI without issue. You only have a stage story for Device Profile alone.
README.md
Outdated
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.
Is this change coming from Chris? I'm trying to understand why the README is so heavily changed.
package/CHANGELOG.md
Outdated
|
||
### Bug Fixes | ||
|
||
* **files:** files in package.json means it only updates whats in there ([bdc23ae](https://github.com/forgerock/forgerock-web-login-framework/commit/bdc23ae6c8030b84aea9e92db83a72bee442263a)) |
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.
Since our commits are going to drive our CHANGELOG conent, we need to write better commits. This commit is an example of one that doesn't make much sense read in this log. Plus, there's a grammatical error, which doesn't look great.
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.
Have you addressed this comment? I don't see this in the updated code.
8644839
to
d6c574b
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.
Thank you. Looks great.
Looks like we have a failure on one of the Interaction tests: https://www.chromatic.com/test?appId=64075ad87b9e160633c33298&id=64810969ad7b6340d675c048 |
d6c574b
to
dc0e45e
Compare
yeah i fixed it and forgot to push, sorry |
add the device profile node to the login widget. can use a device profile node in a page node (with small limitation of timing) or on its own.
dc0e45e
to
a41fa12
Compare
🎉 This PR is included in version 1.1.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 1.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
add the device profile node to the login widget. Supports the ability to render a device profile node as its own component. It will work within a page node but it has some edge cases that are difficult to account for. Password managers may make it so an error state is not tracked appropriately while a device profile is being collected and the form will silently fail.
This is a known limitation at the moment.
https://bugster.forgerock.org/jira/browse/SDKS-2000
Screen.Recording.2023-05-25.at.10.15.04.AM.mov