@wonder-ops/design-system
v0.0.6
Published
Light styling and convenience on top of Material UI, for use in Supply Chain internal tools.
Readme
supply-chain-design-system
Light styling and convenience on top of Material UI, for use in Supply Chain internal tools.
I'm explicitly trying to keep this as minimal and lightweight as possible. As of writing, the supply-chain team has ZERO frontend devs. Using off-the-shelf components will hopefully both reduce the surface area we have to maintain, and help accelerate our designers' process (by feeding MUI to their AI).
As a result, if product/design ask for something that MUI doesn't provide, you, the reader, should push back, and they, the requester, need to understand that they're leaving the safe harbor of tested components with free maintenance for the stormier sea of "I want my zero engineers to manually build me something custom and then support it forever." Sometimes, maybe that'll be worth it (side menu?). Usually, it will not be.
How to use
Setup
This package has a chunk of explicit peer dependencies -- react, MUI, date-fns. Use those directly in your code.
In the root of your app (which I'm assuming is React/Typescript/NextJS), wrap the whole tree in <ThemeProvider>. Pass it the MUI license key (which should be an env var) to make sure the data grid and date pickers work. You'll also want to use the exported fontLinks to ensure your app has the Inter font loaded. It'll look like this:
import { fontLinks, ThemeProvider } from "@wonder/supply-chain-design-system";
const RootLayout: React.FC<{ children: React.ReactNode }> = async ({ children }) => {
const muiLicenseKey = process.env.NODE_PUBLIC_MUI_LICENSE;
return (
<html translate="no" lang="en" dir="ltr">
<head>
<link rel="icon" type="image/x-icon" href="/images/favicon.ico" />
{fontLinks.map((font) => (
<link key={font} href={font} rel="stylesheet" />
))}
</head>
<body>
<ThemeProvider muiLicenseKey={muiLicenseKey}>{children}</ThemeProvider>
</body>
</html>
);
};99% of Cases
Because this is designed to be as little surface area as possible, you'll have way more success consulting the MUI Docs. Go there first for questions and API details.
Side Menu
We export a shared sliding side menu. Consult the storybook for a usage example. I like to think the props are mostly self-explanatory. You pass it a series of Links (type example below), a handle for what happens when that link is clicked, and an optional set of initials/URL for the little user avatar at the bottom.
const links: SideMenuLinks = [
{
label: 'Dashboard',
url: '/dashboard',
icon: <AutoGraph />,
},
{
label: 'Reports',
url: '/reports',
icon: <ContentPaste />,
},
'divider', // <-- This'll render a little divider line
{
label: 'Bathtub',
url: '/bathtub',
icon: <Bathtub />,
},
];You'll likely want to wrap your page in a flexbox to allow the main content to shrink/expand as the box opens and closes.
ModalContainer
Being able to open modals imperatively is very useful, since it allows you to affect the screen from outside the React tree. (E.g., in response to a socket message, or a 401, open a modal).
The <ThemeProvider> component comes with a baked-in <ModalContainer>. When you call the exposed openModal() function, we render the passed modal contents in the <ModalContainer>. Consider the following example (and refer to storybook for more).
import { openModal } from "@wonder/supply-chain-design-system";
const MODAL_ONE: AddModalData = {
modalId: 'modal-one',
content: ({ hide, visible }) => {
if (!visible) return null;
return (
<>
<DialogTitle>Modal One</DialogTitle>
<DialogContent>
I'm an imperatively-opened modal. I was opened by calling `openModal()`, which
can happen from anywhere JS runs.
</DialogContent>
<DialogActions>
<Button onClick={hide}>Woah.</Button>
</DialogActions>
</>
);
},
};
const openModalOne = () => openModal(MODAL_ONE)