Ant Design integrations
Version baseline: Ant Design 6.x (6.4.3 current stable at this review), with the current v6 documentation and React 18 or 19 compatibility; prefer React 19 for new work. Inspect the exact installed patch and migration notes before changing an existing project.
Treat each integration as one seam between two systems that both want control of the same thing: markup, styling, state, or dates. Find which side already owns it in this project, then adapt Ant Design to that owner rather than adding a second source of truth.
Name the seam
Identify which of these the task actually touches:
- Routing —
Menu,Breadcrumb,Tabs,Pagination, andTablelinks must produce the router's navigation, not full page loads. - Server state —
Table,Select, andFormneed loading, error, and pagination state that a data library already tracks. - Dates —
DatePickerandTimePickeruse one date library; the app may use another. - Styling — Ant Design generates its own CSS; Tailwind or an existing stylesheet may reset or outrank it.
- Locale —
ConfigProvidercarries component text and date formats separately from the app's translation library. - Testing — component queries depend on the DOM Ant Design renders, including portals.
Wire one deliberately
- Read the project first: the router, the data-fetching library, the date type used in models and on the wire, the CSS pipeline, and the test setup.
- Change one seam at a time and keep the adapter in one place. A shared
renderLinkhelper beats per-component link handling. - For routing, render the router's link component inside the Ant Design item rather than handling
onClickand callingnavigateyourself. Keephrefreal so middle-click and open-in-new-tab still work. - For server state, let the data library own loading and pagination and pass its values down. Do not mirror them into component state.
- For dates, pick the adapter that matches the project's existing date library and convert at the form boundary, not inside each field.
- For styling, scope the other system away from Ant Design's markup instead of raising specificity. A CSS reset that strips button and input styling is the usual cause of a half-styled component.
- For locale, pass a locale to
ConfigProviderand keep the app's own translated strings in the app's translation library. They are two separate concerns.
Read references/integrations.md for the router link patterns, the table plus server-state shape, the date adapter choices, the Tailwind coexistence settings, and the testing setup for portal-rendered components.
Verify end to end
Exercise the real path rather than the component in isolation: click a menu item and confirm the URL changes without a reload, change a table page and confirm one request goes out with the right parameters, submit a date and confirm the value that reaches the server matches the model's type, and switch locale and confirm both component text and formats change.
Review traps
Look for a router link wrapped so that the clickable area is the text rather than the whole item, pagination that fires two requests because both the table and the data library own the page, a date picker returning a library object where the model expects an ISO string, a CSS reset that outranks generated styles, and tests that fail only for Modal, Drawer, Select, or Tooltip because their content renders in a portal outside the queried container.