-
Notifications
You must be signed in to change notification settings - Fork 3.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
feat: IATR-M0 Page Header #24722
feat: IATR-M0 Page Header #24722
Conversation
Test summaryRun details
View run in Cypress Dashboard ➡️ Failures
Flakiness
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
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.
Still looking through details, but wanted to get this feedback to you.
] | ||
const acc: status[] = [] | ||
|
||
if (props.order) { |
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 the order even be configurable? The results this component displays should be consistent across features, otherwise it becomes confusing.
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 is an attempt to make the ResultCounts.vue
component more generic. In its current implementation, the status can only appear in a certain order i.e. skipped, pending, passed, failed. You can see this generic component in the Runs tab for the app.
Based on the design requirements for this issue, the order of these "statuses" is different. Hence, instead of building a whole new component we can utilize ResultCounts.vue
and just pass in a different order incase in the future the order of "statuses" is different.
As for the component being consistent, I agree with that. I don't see why the "status" order should differ across pages. However this has been added to meet the design requirements
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 would sync back with design regarding this, this result of this list (in my mind) should be consistent regardless of if you're looking at the runs page or the debug page
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.
Sure looks pretty, left some comments
|
||
</script> | ||
<style scoped> | ||
ul:nth-child(2) li:not(:first-child)::before { |
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.
Woah, this is specific. I think this CSS could break easily.
I'm not sure what it does, but can we use a class or id or something that isn't tied to a specific DOM structure?
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 adds the " . " after each component in the bottom section of the UI. That way we don't manually have to add " . " in our template. It is similar to styling here
<div | ||
class="text-red-400 font-semibold text-sm flex items-center border-r-1px px-2" | ||
> | ||
<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.
Why not just
<FailedSolidIcon
class=...
data-cy=...
/>
<component>
is good for dynamic content - but this isn't. (Could be missing something).
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 will not always be a FailedSolidIcon
. In future iterations, this could be a PassedIcon
or hold other statuses hence the <component>
import type { DebugResultsFragment } from '../generated/graphql' | ||
import { gql } from '@urql/core' | ||
import FailedSolidIcon from '~icons/cy/status-failed-solid_x24.svg' | ||
import ResultCounts from '@packages/frontend-shared/src/components/ResultCounts.vue' |
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.
Curious what the team things but this seems like it's not really a good candidate for frontend-shared
. It doesn't seem like something we will use in other packages (like launchpad).
Thoughts? cc @marktnoonan, we had a brief discussion around this.
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.
@lmiller1990 The ResultsCounts
is an existing component that was just getting reused here with a minor addition. I do agree that it is only used in app
so does not need to be in frontend-shared
, but we can refactor that another time.
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 to me
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 one minor nit-pick
import type { DebugResultsFragment } from '../generated/graphql' | ||
import { gql } from '@urql/core' | ||
import FailedSolidIcon from '~icons/cy/status-failed-solid_x24.svg' | ||
import ResultCounts from '@packages/frontend-shared/src/components/ResultCounts.vue' |
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.
@lmiller1990 The ResultsCounts
is an existing component that was just getting reused here with a minor addition. I do agree that it is only used in app
so does not need to be in frontend-shared
, but we can refactor that another time.
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 good, left one last comment but not a blocker.
import type { DebugResultsFragment } from '../generated/graphql' | ||
import { gql } from '@urql/core' | ||
import FailedSolidIcon from '~icons/cy/status-failed-solid_x24.svg' | ||
import ResultCounts from '@packages/frontend-shared/src/components/ResultCounts.vue' |
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 to me
Updating the feature branch and merging it in here, should fix CI. I'll merge once this is green. |
Looks like we have a CI failure - re-ran but still failing, want to take a look @amehta265? https://app.circleci.com/pipelines/github/cypress-io/cypress/46041/workflows/a86994bb-0f07-454a-bfaf-60c6048476a0/jobs/1936007/tests#failed-test-0 |
Actually @amehta265 it might be flake, see #24575 |
…press-io/cypress into ankit/IATR-M0-debugPageHeader Merging with remote branch
User facing changelog
This component is the header of the new debug page that represents the chosen run and its metadata.
The design for this page can be found here
Additional details
DebugPageHeader
contains metadata related to a user's test. In order to render the status of the test (i.e. number of passed, failed, skipped, pending tests) I have also created another componentDebugResults
.DebugResults
utilizes an already existing componentResultCounts
to render the UI for this section. Changes have beenResultCounts.vue
to accommodate for a change in theorder
of statuses shown as per design requirements.debugPageHeader
acceptsgql
values as a prop. In case these props are not passed to the component it will render default values.commitsAhead()
are merely placeholders and will be implemented later on. Furthermore thegql
query will potentially change in the futureSteps to test
This issue has 3 component tests. Checkout to this branch to run the tests
Both
DebugPageHeader.vue
andDebugResults.vue
exist in thepackages/app/
folder. To run these tests:packages/app
yarn dev
DebugPageHeader.cy.tsx
andDebugResults.cy.tsx
To test
ResultsCounts.vue
yarn cypress:open
frontend-shared
as a projectResultCounts.cy.tsx
How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?