Apex Charts Not Found: Embr Charts Is the Fix, Not Rebuilds

Imported charts load normally after replacing the legacy Apex Charts module with an Embr Charts release that contains the ApexCharts package. The decisive log message is No registered component for type-id: "embr.chart.apex-charts": the destination gateway cannot resolve the component type stored in the imported project.

Stop repeating the quick fixes

Get production moving if necessary, but do not mistake a locally recreated chart for a repaired import path. These common responses leave the component registry mismatch in place.

Recreating a small number of charts can restore a screen temporarily, but it creates configuration drift between development and the client. Record any emergency rebuilds so they can be replaced with the original imported resources after the module correction.

Recognize the registry mismatch

A Perspective component is stored with a type identifier. During project loading, the gateway and client-side runtime use that identifier to locate the module code that defines the component, its properties, and its rendering behavior. The imported chart requests embr.chart.apex-charts.

The reported destination has no registered component for that identifier. That is not a bad chart query, malformed series, binding failure, or missing data source. Those faults occur after a chart instance has been created. Here, component resolution fails before chart configuration can run.

The embr prefix is the useful clue. ApexCharts support was added to Embr Charts in version 3. The installed Apex Charts Components 2.0.1 is the legacy module line and does not satisfy the imported resource's Embr component registration. Matching the gateway platform at 8.3.4 does not make two different third-party module families interchangeable.

Confirm the fault before changing modules

1. Open the destination gateway's module-management view. Confirm whether the installed chart package is the legacy Apex Charts module or Embr Charts. Record its exact displayed name, version, state, and any license state before making changes.
2. Check the gateway logs while opening a view containing an affected chart. Search for the exact entry No registered component for type-id: "embr.chart.apex-charts".
3. Check the client or session diagnostics for component-loading errors. A client error paired with the same gateway registration failure keeps the investigation on module deployment, not chart data.
4. Inspect the development gateway's module inventory using the same fields. Compare package identity and state, not just 8.3.4 or the number 2.0.1.
5. Confirm that ordinary built-in components load on the imported view. If the entire view fails, separate that fault from the missing chart registration before replacing modules.

Stop here if the destination already shows Embr Charts running but the type ID remains unregistered. Save the gateway and client log entries, module inventory, and import timestamp; that combination points to a failed module startup, incompatible package, or incomplete deployment rather than the known legacy-module substitution.

Replace the legacy module in the right order

Schedule the change for a controlled window. Removing a component module can affect every project that uses its registered types, so inventory the destination's existing chart views first. Keep the original module installer and a current gateway backup under the site's normal recovery procedure.

1. Close active designer sessions that could save chart resources during the change.
2. Use the gateway's module-management controls to uninstall the legacy Apex Charts module. The required sequence is removal first; do not leave the legacy package installed while adding its replacement.
3. Obtain an Embr Charts package intended for the gateway 8.3 family through the package publisher's supported distribution channel. Select version 3 or later because ApexCharts entered Embr Charts at that version boundary.
4. Install Embr Charts through the gateway's module-management interface.
5. Wait for module loading to finish, then confirm that the module reports a running state. Read any dependency, signature, licensing, or startup message shown by the gateway instead of repeatedly uploading the package.
6. Reopen the designer and imported project. Reimport an untouched chart resource if earlier testing replaced it with a locally recreated component.
7. Launch a fresh client session and open each affected view.

If production depends on charts implemented only by the legacy module, do not remove it blindly. Identify those resources and plan their migration first. A rollback restores the recorded module set and gateway backup; manually rebuilding more imported charts is not a rollback.

Verify registration and chart operation

Separate module verification from application verification. A running module is necessary, but the repair is complete only when imported resources resolve and render correctly.

Test more than the chart that triggered the call. Open each chart type used by the project, exercise its bindings, and check the logs during a fresh session. The repeat-import test proves that later project deliveries will not recreate the outage.

Keep future imports portable

Treat third-party component modules as deployment dependencies. Store a module manifest with each project release containing the package name, module family, version, and required state. Compare that manifest with the target gateway before importing the project.

Do not use a shared version number as proof of compatibility. The platform version, legacy component version, and Embr Charts version identify different software layers. Compare the package that owns the serialized type ID.

Promote the same project artifact through development and client environments, then run a view-opening smoke test after every import. Avoid saving over unresolved components in the destination designer: that can turn a deployment problem into permanent project divergence.

FAQ