Skip to content
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

Merged
merged 1 commit into from
Jun 12, 2023
Merged

Conversation

ryanbas21
Copy link
Contributor

@ryanbas21 ryanbas21 commented May 11, 2023

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

@ryanbas21 ryanbas21 temporarily deployed to Preview May 11, 2023 01:33 — with GitHub Actions Inactive
@ryanbas21
Copy link
Contributor Author

ryanbas21 commented May 11, 2023

Your preview environment pr-121-ryanbas21 has been deployed.

Preview environment endpoint is available here

@ryanbas21 ryanbas21 temporarily deployed to Preview May 11, 2023 17:49 — with GitHub Actions Inactive
Copy link
Contributor

@cerebrl cerebrl left a 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.

.svelte-kit/tsconfig.json Outdated Show resolved Hide resolved
vitest.config.ts Outdated Show resolved Hide resolved
vitest.config.ts.timestamp-1683768174756.mjs Outdated Show resolved Hide resolved
src/lib/journey/stages/step.mock.ts Outdated Show resolved Hide resolved
src/lib/journey/_utilities/metadata.utilities.test.ts Outdated Show resolved Hide resolved
@ryanbas21 ryanbas21 temporarily deployed to Preview May 11, 2023 20:01 — with GitHub Actions Inactive
@ryanbas21 ryanbas21 temporarily deployed to Preview May 11, 2023 21:13 — with GitHub Actions Inactive
Comment on lines 176 to 177
// 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.
Copy link
Contributor

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?

@ryanbas21 ryanbas21 temporarily deployed to Preview May 24, 2023 18:04 — with GitHub Actions Inactive
@ryanbas21 ryanbas21 temporarily deployed to Preview May 24, 2023 18:25 — with GitHub Actions Inactive
Comment on lines 176 to 179
// 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.
Copy link
Contributor

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 });
Copy link
Contributor

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 }) => {
Copy link
Contributor

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.

Comment on lines 11 to 20
await page.waitForRequest(/\/authenticate/, async () => {
const text = page.getByText('Collecting Profile');
await expect(text).toBeVisible();
});
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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']);
Copy link
Contributor

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?

@ryanbas21 ryanbas21 temporarily deployed to Preview June 1, 2023 18:57 — with GitHub Actions Inactive
@ryanbas21 ryanbas21 temporarily deployed to Preview June 1, 2023 19:15 — with GitHub Actions Inactive
@ryanbas21 ryanbas21 temporarily deployed to Preview June 1, 2023 19:41 — with GitHub Actions Inactive
Copy link
Contributor

@cerebrl cerebrl left a 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.

.vscode/launch.json Outdated Show resolved Hide resolved
Copy link
Contributor

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.

Copy link
Contributor

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.

@ryanbas21 ryanbas21 temporarily deployed to Preview June 1, 2023 21:44 — with GitHub Actions Inactive
@ryanbas21 ryanbas21 temporarily deployed to Preview June 1, 2023 21:56 — with GitHub Actions Inactive
@ryanbas21 ryanbas21 temporarily deployed to Preview June 2, 2023 14:53 — with GitHub Actions Inactive
@ryanbas21 ryanbas21 changed the base branch from main to beta June 2, 2023 15:42
Copy link
Contributor

@cerebrl cerebrl left a 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
Copy link
Contributor

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.


### 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))
Copy link
Contributor

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.

Copy link
Contributor

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.

@ryanbas21 ryanbas21 temporarily deployed to Preview June 7, 2023 22:46 — with GitHub Actions Inactive
Copy link
Contributor

@cerebrl cerebrl left a 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.

@cerebrl
Copy link
Contributor

cerebrl commented Jun 8, 2023

Looks like we have a failure on one of the Interaction tests: https://www.chromatic.com/test?appId=64075ad87b9e160633c33298&id=64810969ad7b6340d675c048

@ryanbas21 ryanbas21 temporarily deployed to Preview June 8, 2023 14:57 — with GitHub Actions Inactive
@ryanbas21
Copy link
Contributor Author

Looks like we have a failure on one of the Interaction tests: https://www.chromatic.com/test?appId=64075ad87b9e160633c33298&id=64810969ad7b6340d675c048

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.
@ryanbas21 ryanbas21 temporarily deployed to Preview June 9, 2023 21:45 — with GitHub Actions Inactive
@cerebrl cerebrl added this pull request to the merge queue Jun 12, 2023
Merged via the queue into beta with commit 76dfa5a Jun 12, 2023
@cerebrl cerebrl deleted the device-profile-node branch June 12, 2023 15:40
@ryanbas21
Copy link
Contributor Author

🎉 This PR is included in version 1.1.0-beta.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@ryanbas21
Copy link
Contributor Author

🎉 This PR is included in version 1.1.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants