-
Notifications
You must be signed in to change notification settings - Fork 368
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
tech-story: [M3-9052] - Migrate PlacementGroups to Tanstack router #11474
Conversation
d4590c6
to
18984b0
Compare
0797511
to
610ed4b
Compare
packages/manager/src/features/PlacementGroups/PlacementGroupsUnassignModal.tsx
Outdated
Show resolved
Hide resolved
...ures/PlacementGroups/PlacementGroupsDetail/PlacementGroupsLinodes/PlacementGroupsLinodes.tsx
Outdated
Show resolved
Hide resolved
@@ -155,7 +155,7 @@ describe('resize linode', () => { | |||
}); | |||
}); | |||
|
|||
it.only('resizes a linode by decreasing size', () => { |
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.
whoops didn't catch this earlier in its respective pr 😅
label: 'PG-1', | ||
placement_group_type: 'anti_affinity:local', |
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 and a bunch of other test files may just be eslint fixes. Otherwise, they'll have changes to use renderWithThemeAndRouter
/other tanstack changes
@@ -11,6 +11,7 @@ import { createPlacementGroupSchema } from '@linode/validation'; | |||
import { useFormik } from 'formik'; | |||
import { useSnackbar } from 'notistack'; | |||
import * as React from 'react'; | |||
// eslint-disable-next-line no-restricted-imports |
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.
since PlacementGroupsCreatedDrawer is used in LinodesCreate, we need to keep react-router-dom
here (for now)
@@ -105,28 +99,6 @@ export const PlacementGroupsDeleteModal = (props: Props) => { | |||
return null; | |||
} | |||
|
|||
if (!assignedLinodes) { |
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.
for here and PlacementGroupsUnassignModal
, now that we fetch the values in the parent component via useDialogData
, and pass isFetching here, we can remove this existing check - a loading state will get rendered if the data is fetching
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.
yup!
|
||
const { | ||
data: placementGroup, | ||
error: placementGroupError, | ||
isLoading, | ||
} = usePlacementGroupQuery(placementGroupId); | ||
const { data: linodes, isFetching: isFetchingLinodes } = useAllLinodesQuery( |
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 and related logic was moved down to a child component, PlacementGroupsLinodes, to avoid excessive prop drilling
<OrderBy data={linodes} order="asc" orderBy={orderLinodeKey}> | ||
{({ data: orderedData, handleOrderChange, order, orderBy }) => ( | ||
<Paginate data={orderedData}> | ||
{({ |
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.
rather than OrderBy, we're now using useOrderV2
- see PlacementGroupsLinodes
paginate - tbd, running into some issues
const orderLinodeKey = 'label'; | ||
const orderStatusKey = 'status'; |
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.
see Changes section in PR main comment - removed status option bc it's not supported by the API
action, | ||
}), | ||
}, | ||
path: 'linodes/$action', |
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.
since assigning a Linode and unassigning it use slightly different routes, updating to use params.action === action
pattern wasn't as straightforward as placementGroupAction
- I ended up making placementGroupsUnassignRoute
be a child of this placementGroupLinodesActionBaseRoute
route
...(query && { label: { '+contains': query } }), | ||
}; | ||
|
||
const { data: linodes, isFetching: isFetchingLinodes } = useAllLinodesQuery( |
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.
pagination for the linodes table: having trouble testing with mock testing - it looks like filtering isn't applied, so all linodes are being returned, not just the ones that match lines 72-73 above. (also, repeat linodes are being returned/the same query is firing several times?, so I need to do more investigation with this)
I do think that pagination with actual data should work, (if it gets to that point - for actual data, most PGs I see can only have up to 5, maybe 10 linodes, so I haven't yet seen the footer) bc the actual queries are returning filtered and paginated data. However, bc I'm having trouble confirming, I don't want to say this with 100% confidence...
If it's better, I can switch this back to the original code which uses the Paginate
hoc, but would need to do more work to get routing working for pagination then
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 think this is ok. Seems like an edge for mock data only so i am not worried about this.
...ures/PlacementGroups/PlacementGroupsDetail/PlacementGroupsLinodes/PlacementGroupsLinodes.tsx
Outdated
Show resolved
Hide resolved
>(); | ||
const { isLinodeReadOnly, placementGroup, region } = props; | ||
const navigate = useNavigate(); | ||
const params = useParams({ strict: false }); |
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.
Out of curiosity, is there any realistic way we can avoid using strict: false
so often? It feels wrong, but does the job
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.
We can only avoid strict: false
for routes that don't have mounted routed content. So for pages containing modals/drawers/tabs we need to have it - it is by design (and also because of the way our application was composed)
getting closer revert rest of createDrawer router changes maybe a bit closer?? fix landing state prevent query from firing when NaN trying to add routing for search and order by pg linodes table
@abailly-akamai for the notice issue, this is what I'm seeing - I just rebased with develop which has this pr that fixed a lot of notices 🚀 Looking into the extra reload thing - wondering if update - changing deleteModal to use isLoading instead + each unassign Linode button has its own loading state |
Cloud Manager UI test results🔺 1 failing test on test run #36 ↗︎
Details
TroubleshootingUse this command to re-run the failing tests: yarn cy:run -s "cypress/e2e/core/linodes/resize-linode.spec.ts" |
Description 📝
Changes 🔄
Preview 📷
How to test 🧪
Pagination testing:
Author Checklists
As an Author, to speed up the review process, I considered 🤔
👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support
As an Author, before moving this PR from Draft to Open, I confirmed ✅