-
Notifications
You must be signed in to change notification settings - Fork 0
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
[ENH] Implemented landing view #37
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #37 +/- ##
=======================================
Coverage 88.09% 88.09%
=======================================
Files 12 12
Lines 42 42
Branches 7 7
=======================================
Hits 37 37
Misses 5 5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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 @rmanaem . Not sure about the cypress selectors, but otherwise 🧑🍳
@@ -15,7 +15,7 @@ function NavigationButton({ | |||
}; | |||
|
|||
return ( | |||
<Button variant="contained" onClick={handleClick}> | |||
<Button data-cy={`${label.toLowerCase()}-button`} variant="contained" onClick={handleClick}> |
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.
that might be a bit risky as a cypress selector, no? What if we change the label, should that break the tests? Not sure what the best solution here is. Maybe numeric identifiers for the views you can navigate to? That might change less frequently
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.
hmmm what would that look like?
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.
Good question. I guess the goal would be to have persistent and unique identifiers for each page/view you can navigate to. Numeric identifiers are easy to make unique and persistent, but they are hard to read and debug. So maybe just a string identifier like column_annotation
and multi_column_annotation
and so on. Presumably such a list would have to live in the central store of the app.
But maybe let's discuss this first in an issue and then make a decision and implement.
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.
Yea, let's do that cause I'm not sure if it's a good idea to keep that in the store. Could you please open the issue?
Checklist
This section is for the PR reviewer
[ENH]
,[FIX]
,[REF]
,[TST]
,[CI]
,[MNT]
,[INF]
,[MODEL]
,[DOC]
) (see our Contributing Guidelines for more info)skip-release
(to be applied by maintainers only)Closes #XXXX
For new features:
For bug fixes: