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

Add List view for apps as default #690

Merged
merged 25 commits into from
Aug 17, 2022
Merged

Add List view for apps as default #690

merged 25 commits into from
Aug 17, 2022

Conversation

bharatkashyap
Copy link
Member

@bharatkashyap bharatkashyap commented Jul 25, 2022

  • 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,

    • Possible extension to allow collapsible rows for folders
  • Removed the "Apps" heading in favour of a Tabs list in the AppBar,

    • Possible extension to allow a global "Data" or "Connections" tab
  • Rewrote the EditableText component to use only TextFields and leak minimal implementation details

  • Added a AppNameEditable component (along with some other to allow reuse between Card and Row) to store app name specific renaming logic

  • Remove 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

@render
Copy link

render bot commented Jul 25, 2022

@oliviertassinari oliviertassinari requested a deployment to app-card-rename - toolpad-db PR #690 July 25, 2022 18:04 — with Render Abandoned
@Janpot
Copy link
Member

Janpot commented Jul 27, 2022

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 variant and sx props for both non-editable and editable state. If that's too hard we can perhaps compromise on sx only as a start.

In case it could be helpful, typograpy styles are aviable in the theme object under theme.typography[variant]

@render
Copy link

render bot commented Jul 29, 2022

@oliviertassinari oliviertassinari requested a deployment to app-card-rename - toolpad-db PR #690 July 29, 2022 16:04 — with Render Abandoned
@bharatkashyap bharatkashyap changed the title Make inputProps controllable Rewrite EditableText for a tighter abstraction Jul 29, 2022
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 31, 2022
@bharatkashyap bharatkashyap changed the title Rewrite EditableText for a tighter abstraction Add List view for apps as default Jul 31, 2022
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 31, 2022
packages/toolpad-app/src/components/EditableText.tsx Outdated Show resolved Hide resolved
errorText?: string;
onKeyUp: (event: React.KeyboardEvent<HTMLInputElement>) => void;
onBlur: (event: React.FocusEvent<HTMLInputElement>) => void;
onKeyUp?: (event: React.KeyboardEvent<HTMLInputElement>) => void;
Copy link
Member

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,...

@@ -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}"]`),
Copy link
Member

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?

Copy link
Member Author

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

@Janpot
Copy link
Member

Janpot commented Aug 1, 2022

@bharatkashyap It seems like the title and description of this PR are a bit off?

@bharatkashyap
Copy link
Member Author

@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) {
Copy link
Member

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}>
Copy link
Member

@Janpot Janpot Aug 5, 2022

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

Copy link
Member Author

@bharatkashyap bharatkashyap Aug 5, 2022

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

Copy link
Member

@Janpot Janpot Aug 5, 2022

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
Copy link
Member

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={...} />

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Aug 10, 2022
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Aug 10, 2022
@Janpot
Copy link
Member

Janpot commented Aug 10, 2022

Resolved the conflicts that emerged after merging #723

Copy link
Member

@Janpot Janpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌

@bharatkashyap bharatkashyap merged commit 4a05e24 into master Aug 17, 2022
@bharatkashyap bharatkashyap deleted the app-card-rename branch August 17, 2022 07:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Renaming apps breaks styling
5 participants