Shared UI Components

Reuse erxes-ui and ui-modules instead of building parallel primitives. This guide follows version 3.1.7 (03acdf712c).

For the loading model, see Frontend & Plugin Loading.

Which library to use

erxes-ui (frontend/libs/erxes-ui/src/): generic primitives — buttons, forms, selects, page headers, breadcrumbs, board and record-table building blocks, filter and input components, layout and display helpers, shared hooks and state.
ui-modules (frontend/libs/ui-modules/src/): business-domain composition — contacts, products, sales, segments, tags, automations, activity logs, and related states and hooks.

Both are shared as Module Federation singletons. Import via the package names:

import { Button, Form, PageHeader } from "erxes-ui";
import { AutomationForm } from "ui-modules";

Do not import Radix primitives directly in plugin code, do not deep-import internal library paths, and do not fork library source into a plugin.

Keep plugin-specific assets, translations, components, hooks, and utilities inside frontend/plugins/<name>_ui/src/.
Type props and hook results; avoid any in application code (tool configs may require a default export).
Validate forms with React Hook Form plus Zod and show labels, validation, and submission feedback.
Provide loading, empty, success, and error states for every data view; every button needs a working handler.
Use Apollo Client for server state and Jotai only for plugin-wide client state.

Render the plugin with the host's theme and confirm spacing, typography, and focus states match.
Exercise empty, loading, and error states with a fresh database and a failed request.
Confirm no duplicate erxes-ui or ui-modules bundles are built per plugin (they are shared singletons).

Was this helpful?

On this page