@eonui/core

@eonui/core is the main EonUI component library package. It ships the core web-component runtime, generated type surfaces, collection output, and component source for the Eon custom element family.

Workspace Note

This folder currently documents the published package surface. The implementation source for @eonui/core is not mirrored into revamp/eonui/packages/core yet, so this README serves as the local documentation home for the package.

Docs And Live Reference

Use this README for package-level component runtime guidance. For the fuller EonUI product surface, visual references, and future public docs, refer to https://eonui.com.

Purpose

Use this package when you need:

• the actual Eon custom elements
• a framework-agnostic component layer
• Stencil-generated build output for browser delivery
• access to component source and generated type definitions from the published package

The current manifest ecosystem around EonUI indicates roughly 73 component entries documented in the related manifest package.

What The Package Ships

The published package currently includes:

• dist/ runtime output
• src/ component source files
• Stencil collection output
• generated component type definitions
• component-level readme files inside the published source tree

Its dependency graph also shows that the core package is designed to sit with:

• @eonui/a11y
• @eonui/styles
• @eonui/icons
• @eonui/tokens
• @eonui/i18n
• @eonui/utils

Install

npm install @eonui/core

Recommended Adoption Flow

Teams usually get the best results with @eonui/core when they adopt it in layers:

1. register the custom elements once in the browser runtime
2. compose a small set of primitives such as inputs, buttons, stacks, and sections
3. align tokens, icons, and styling expectations with the rest of the Eon stack
4. add framework wrappers only where application ergonomics demand them

This package is the right center of gravity when you want EonUI to stay framework-agnostic and when multiple app surfaces may share the same underlying component runtime.

Example 1: Use Eon elements in markup

<eon-section heading="Profile">
  <eon-stack gap="1rem">
    <eon-input label="Email"></eon-input>
    <eon-combobox label="Role" options="Admin,Editor,Viewer"></eon-combobox>
    <eon-button>Save changes</eon-button>
  </eon-stack>
</eon-section>

Use this when:

• building with native custom elements
• prototyping Eon layouts quickly
• staying framework-agnostic

Example 2: Compose a denser product surface

<eon-section heading="Files">
  <eon-toolbar slot="actions">
    <eon-button>Upload</eon-button>
    <eon-button variant="secondary">Create folder</eon-button>
  </eon-toolbar>

  <eon-card>
    <eon-file-manager></eon-file-manager>
  </eon-card>
</eon-section>

Use this when:

• validating component breadth
• reviewing layout primitives and product widgets together
• building more realistic admin or SaaS surfaces

Example 3: Register custom elements from a local build

The published package ships a loader entry with defineCustomElements().

import { defineCustomElements } from '@eonui/core/dist/loader';

defineCustomElements(window);

Use this when:

• wiring the Stencil output into an app shell
• testing direct browser registration
• integrating the package outside a framework wrapper

Note: Depending on the consuming toolchain, you may choose a local-loader path or a bundler-specific setup around the shipped Stencil output.

Example 4: Explore the published source layout

The package includes component source and generated files such as:

• src/components/button/button.tsx
• src/components/chat/chat.tsx
• src/components/tree-view/tree-view.tsx
• src/components/file-manager/file-manager.tsx
• dist/types/components/*.d.ts

Use this when:

• auditing package capabilities
• studying component APIs
• generating secondary docs or wrappers

Troubleshooting

• If elements render as plain tags, the custom-element loader likely has not run in the browser.
• If components load but look unstyled, verify the expected tokens, styles, or host CSS assumptions are present.
• If framework apps struggle with event handling, prefer the framework integration packages rather than forcing every team to learn the raw custom-element surface.
• If teams need stronger SSR behavior, separate server markup generation from browser-only upgrade logic.

Where This Package Fits

@eonui/core is the component foundation that framework-specific packages should sit on top of. In a longer-lived EonUI stack:

• @eonui/core owns the web components
• @eonui/angular, @eonui/react, and @eonui/vue provide framework-specific bridges
• @eonui/manifest describes the component catalog

Current Limitations

• the local revamp/eonui/packages/core folder is documentation-only today
• registration patterns may vary by bundler or runtime shell
• framework-native ergonomics still depend on wrapper packages

Future Prospects

The strongest next steps for this package are:

• bringing the source tree into this workspace directly
• shipping clearer top-level setup guidance
• tightening integration with manifest generation
• expanding first-party wrapper coverage across Angular, React, and Vue