-
-
Notifications
You must be signed in to change notification settings - Fork 287
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
Add List view for apps as default #690
Conversation
Your Render PR Server URL is https://toolpad-pr-690.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cbfdm90nlki93ndc64rg. |
I believe one of the goals of this component should be to hide away the implementation details of how we switch between editable/non-editable state. This PR seems to leak more implementation details than before. In the ideal scenario, consumers of this component don't know whether it's built by switching between typography and textfield, or by styling a single input. I suggest we base the styling purely on In case it could be helpful, typograpy styles are aviable in the |
Your Render PR Server URL is https://toolpad-pr-690.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cbi0a4di0e896j46s7qg. |
errorText?: string; | ||
onKeyUp: (event: React.KeyboardEvent<HTMLInputElement>) => void; | ||
onBlur: (event: React.FocusEvent<HTMLInputElement>) => void; | ||
onKeyUp?: (event: React.KeyboardEvent<HTMLInputElement>) => void; |
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 not super fond of leaking these key handlers. Would it be make sense to build this using controlled properties only? i.e. value
and onChange
that act like a regular TextField
. And to change editable state, open
and onClose
, analog to e.g. the MUI Dialog
, Menu
, Drawer
,...
test/e2e-smoke/basic.spec.ts
Outdated
@@ -19,9 +19,13 @@ test('basic app creation flow', async ({ page }) => { | |||
|
|||
await page.click('[aria-label="Home"]'); | |||
|
|||
const appCardSelector = `[role="article"]:has-text("${appName}")`; | |||
const appRow = await page.locator(`[role="row"]`, { | |||
has: await page.locator(`input[value="${appName}"]`), |
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'd prefer if we could keep the old locator. I have a hunch that there's an accessibility issue here. What happens if we add the aria-readonly
to the input when it's not editable?
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.
Adding the aria-readonly
still doesn't help use the original selector, which relied on a has-text
; but now since the name resides in the value
of an input
, has-text
fails to find the element.
I've modified it a bit to use the selector format instead of locators, and now seems like the tests pass for Firefox as well
@bharatkashyap It seems like the title and description of this PR are a bit off? |
The description explains some of the changes done to add the List view |
value: number; | ||
} | ||
|
||
function TabPanel(props: TabPanelProps) { |
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.
In other places we use the MUI TabContext
and TabPanel
.
})()} | ||
</Box> | ||
</Container> | ||
<TabPanel index={0} value={tabIndex}> |
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.
Does this have to be part of this PR? I'm not quite sure what it's for
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 to move the "Apps" heading into an "Apps" tab; it could potentially be moved to a separate PR but feels like it is close enough feature wise to be part of the Home UI revamp
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 there a need for this right now? It seems a bit redundant. Also, it looks (and works) completely different from how this menu is in the editor. we should probably aim for more consistency (there's also breadcrumbs in the release workflow). Maybe let's leave it out of the scope of this PR?
</ToggleButtonGroup> | ||
</Toolbar> | ||
{viewMode === 'grid' ? ( | ||
<Box |
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.
Would it make sense to extract a AppsGridView
and a AppsTableView
component, with the exact same interface and switch between them bases on viewMode
? e.g.
const AppsView = viewMode === 'grid' ? AppsGridView : AppsTableView
// ...
<AppsView apps={...} />
Signed-off-by: Jan Potoms <[email protected]>
Resolved the conflicts that emerged after merging #723 |
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 have followed (at least) the PR section of the contributing guide.
Added a list view for apps with a toggle button to switch to grid,
Removed the "Apps" heading in favour of a Tabs list in the AppBar,
Rewrote the
EditableText
component to use onlyTextFields
and leak minimal implementation detailsAdded a
AppNameEditable
component (along with some other to allow reuse betweenCard
andRow
) to store app name specific renaming logicRemove tooltips from app names
Fixed a typo in getting readable duration
Fixes Renaming apps breaks styling #689
Screen.Recording.2022-07-31.at.11.40.47.PM.mov