Custom Elements

The dist-custom-elements output target creates custom elements that directly extend HTMLElement and provides simple utility functions for easily defining these elements on the Custom Element Registry. This output target excels in use in frontend frameworks and projects that will handle bundling, lazy-loading, and custom element registration themselves.

This target can be used outside of frameworks as well, if lazy-loading functionality is not required or desired. For using lazily loaded Rindo components, please refer to the dist output target.

To generate components using the dist-custom-elements output target, add it to a project's rindo.config.ts file like so:

rindo.config.ts

import { Config } from '@rindo/core';

export const config: Config = {
  // Other top-level config options here
  outputTargets: [
    {
      type: 'dist-custom-elements',
      // Output target config options here
    },
    // Other output targets here
  ],
};

Config

copy

default: undefined

An array of copy tasks to be executed during the build process.

customElementsExportBehavior

default: 'default'

By default, the dist-custom-elements output target generates a single file per component, and exports each of those files individually.

In some cases, library authors may want to change this behavior, for instance to automatically define component children, provide a single file containing all component exports, etc.

This config option provides additional behaviors that will alter the default component export OR custom element definition behaviors for this target. The desired behavior can be set via the following in a project's Rindo config:

// rindo.config.ts
import { Config } from '@rindo/core';

export const config: Config = {
  outputTargets: [
    {
      type: 'dist-custom-elements',
      customElementsExportBehavior: 'default' | 'auto-define-custom-elements' | 'bundle' | 'single-export-module',
    },
    // ...
  ],
  // ...
};

Option	Description
default	No additional re-export or auto-definition behavior will be performed. This value will be used if no explicit value is set in the config, or if a given value is not a valid option.
auto-define-custom-elements	A component and its children will be automatically defined with the CustomElementRegistry when the component's module is imported.
bundle	A utility defineCustomElements() function is exported from the index.js file of the output directory. This function can be used to quickly define all Rindo components in a project on the custom elements registry.
single-export-module	All component and custom element definition helper functions will be exported from the index.js file in the output directory. This file can be used as the root module when distributing your component library, see below for more details.

note

At this time, components that do not use JSX cannot be automatically defined. This is a known limitation of Rindo that users should be aware of.

dir

default: 'dist/components'

This config option allows you to change the output directory where the compiled output for this output target will be written.

empty

default: true

Setting this flag to true will remove the contents of the output directory between builds.

externalRuntime

default: true

Setting this flag to true results in the following behaviors:

1. Minification will follow what is specified in the Rindo config.
2. Filenames will not be hashed.
3. All imports from packages under @rindo/core/* will be marked as external and therefore not included in the generated Rollup bundle.

generateTypeDeclarations

default: true

By default, Rindo will generate type declaration files (.d.ts files) as a part of the dist-custom-elements output target through the generateTypeDeclarations field on the target options. Type declaration files will be placed in the dist/types directory in the root of a Rindo project. At this time, this output destination is not able to be configured.

Setting this flag to false will not generate type declaration files for the dist-custom-elements output target.

note

When set to generate type declarations, Rindo respects the export behavior selected via customElementsExportBehavior and generates type declarations specific to the content of the generated output directory's index.js file.

includeGlobalScripts

default: false

Setting this flag to true will include global scripts in the bundle and execute them once the bundle entry point in loaded.

isPrimaryPackageOutputTarget

default: false

If true, this output target will be used to validate package.json fields for your project's distribution. See the overview of primary package output target validation for more information.

minify

default: false

Setting this flag to true will cause file minification to follow what is specified in the Rindo config. However, if externalRuntime is enabled, it will override this option and always result in minification being disabled.

Consuming Custom Elements

By default, the custom elements files will be written to dist/components/. This directory can be configured using the output target's dir config.

The generated files will each export a component class and will already have the styles bundled. However, this build does not define the custom elements or apply any polyfills. Static assets referenced within components will need to be set using setAssetPath (see Making Assets Available).

Below is an example of defining a custom element:

import { defineCustomElement } from 'my-library/dist/components/hello-world';

defineCustomElement(); // Same as manually calling: customElements.define('hello-world', HelloWorld);

The output directory will also contain an index.js file which exports some helper methods by default. The contents of the file will look something like:

export { setAssetPath, setPlatformOptions } from '@rindo/core/internal/client';

note

The contents may look different if customElementsExportBehavior is specified!

Making Assets Available

For performance reasons, the generated bundle does not include local assets built within the JavaScript output, but instead it's recommended to keep static assets as external files. By keeping them external this ensures they can be requested on-demand, rather than either welding their content into the JS file, or adding many URLs for the bundler to add to the output. One method to ensure assets are available to external builds and http servers is to set the asset path using setAssetPath().

The setAssetPath() function is used to manually set the base path where static assets can be found. For the lazy-loaded output target the asset path is automatically set and assets copied to the correct build directory. However, for custom elements builds, the setAssetPath(path) should be used to customize the asset path depending on where they are found on the http server.

If the component's script is a type="module", it's recommended to use import.meta.url, such as setAssetPath(import.meta.url). Other options include setAssetPath(document.currentScript.src), or using a bundler's replace plugin to dynamically set the path at build time, such as setAssetPath(process.env.ASSET_PATH).

import { setAssetPath } from 'my-library/dist/components';

setAssetPath(document.currentScript.src);

Make sure to copy the assets over to a public directory in your app. This configuration depends on how your script is bundled, or lack of bundling, and where your assets can be loaded from. How the files are copied to the production build directory depends on the bundler or tooling. The configs below provide examples of how to do this automatically with popular bundlers.

Distributing Custom Elements

See our docs on publishing a component library for information on setting up the library's package.json file and publishing to a package manager.

By default, custom elements will need to be imported from the output directory specified on the output target config:

import { MyComponent } from 'best-web-components/dist/components/my-component';

However, the module property in the package.json can be modified to point to the custom element output:

package.json

{
  "module": "dist/components/index.js",
  "dependencies": {
    "@rindo/core": "latest"
  },
  ...
}

note

Be sure to set @rindo/core as a dependency of the package as well.

As a result, components can alternatively be imported from the root of the published package:

import { MyComponent } from 'best-web-components';

note

If you are distributing the output of both the dist and dist-custom-elements targets, then it's up to you to choose which one of them should be available in the module entry.

Usage in TypeScript

If you plan to support consuming your component library in TypeScript you'll need to set generateTypeDeclarations: true on the your output target in rindo.config.ts, like so:

rindo.config.ts

import { Config } from '@rindo/core';

export const config: Config = {
  outputTargets: [
    {
      type: 'dist-custom-elements',
      generateTypeDeclarations: true,
    },
    // ...
  ],
  // ...
};

Then you can set the types property in package.json so that consumers of your package can find the type definitions, like so:

package.json

{
  "module": "dist/components/index.js",
  "types": "dist/components/index.d.ts",
  "dependencies": {
    "@rindo/core": "latest"
  },
  ...
}

note

If you set the dir property on the output target config, replace dist/components in the above snippet with the path set in the config.

Example Bundler Configs

Instructions for consuming the custom elements bundle vary depending on the bundler you're using. These examples will help your users consume your components with webpack and Rollup.

The following examples assume your component library is published to NPM as my-library. You should change this to the name you actually publish your library with.

Users will need to install your library before importing them.

npm

npm install my-library

Yarn

yarn add my-library

pnpm

pnpm add my-library

webpack.config.js

A webpack config will look something like the one below. Note how assets are copied from the library's node_module folder to dist/assets via the CopyPlugin utility. This is important if your library includes local assets.

const path = require('path');
const CopyPlugin = require('copy-webpack-plugin');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },
  plugins: [
    new CopyPlugin({
      patterns: [
        {
          from: path.resolve(__dirname, 'node_modules/my-library/dist/my-library/assets'),
          to: path.resolve(__dirname, 'dist/assets'),
        },
      ],
    }),
  ],
};

rollup.config.js

A Rollup config will look something like the one below. Note how assets are copied from the library's node_module folder to dist/assets via the rollup-copy-plugin utility. This is important if your library includes local assets.

import path from 'path';
import commonjs from '@rollup/plugin-commonjs';
import copy from 'rollup-plugin-copy';
import postcss from 'rollup-plugin-postcss';
import resolve from '@rollup/plugin-node-resolve';

export default {
  input: 'src/index.js',
  output: [{ dir: path.resolve('dist/'), format: 'es' }],
  plugins: [
    resolve(),
    commonjs(),
    postcss({
      extensions: ['.css'],
    }),
    copy({
      targets: [
        {
          src: path.resolve(__dirname, 'node_modules/my-library/dist/my-library/assets'),
          dest: path.resolve(__dirname, 'dist'),
        },
      ],
    }),
  ],
};

How is this different from the "dist" output target?

The dist-custom-elements builds each component as a stand-alone class that extends HTMLElement. The output is a standardized custom element with the styles already attached and without any of Rindo's lazy-loading. This may be preferred for projects that are already handling bundling, lazy-loading and defining the custom elements themselves.

The dist output target, on the other hand, is more for projects that want to allow components to lazy-load themselves, without having to setup bundling configurations to do so.

Luckily, all builds can be generated at the same time, using the same source code, and shipped in the same distribution. It would be up to the consumer of your component library to decide which build to use.