Client-Side API Reference

Code Effects ships its browser code in two npm packages. Each one is a set of files that you add to your web application, and each has its own reference page in this section.

Package	Reference	Needed by
@codeeffects/editor	codeeffects.editor.js	Every application. A stand-alone Rule Editor needs this package alone, and the Rule Repository (RR) needs it too.
@codeeffects/repository	codeeffects.repository.js	Applications that use RR, always together with @codeeffects/editor.

In short: a page with a stand-alone Rule Editor references the files of @codeeffects/editor; a page with RR references the files of both packages, because every rule RR shows is a Rule Editor.

@codeeffects/editor

The @codeeffects/editor package contains all client-side files needed to implement the Rule Editor in a stand-alone application: the codeeffects.editor.js script and the codeeffects.editor.common.css, codeeffects.editor.light.css, and codeeffects.editor.dark.css stylesheets. The script exposes the $rule and $ce global variables. The editor is configured by two JSON strings that the server-side Control class produces, and your code decides how rules are loaded, saved, and deleted. See Initialization of the Rule Editor for the two ways to start it.

@codeeffects/repository

The @codeeffects/repository package contains the Rule Repository's own client files: the codeeffects.repository.js script and the codeeffects.repository.common.css, codeeffects.repository.light.css, and codeeffects.repository.dark.css stylesheets.

You need this package only if you have the Rule Repository .NET library and its license. If your application does not use RR, you never install or reference it. If it does, install @codeeffects/editor as well: RR does not work without the Rule Editor's script and stylesheets.

RR is a complete user interface for managing rules, their versions, and their source objects. Your page gives it one empty element and a function that forwards RR's requests to your server, and RR does the rest. See the Rule Repository guide for what a user does with it and Rule Storage in Rule Repository for what it stores.

How the Two Packages Relate

• The packages are independent files, but RR contains Rule Editors. Every rule RR shows is a Rule Editor, and its date range filter draws the editor's calendar. A page that shows RR therefore needs the files of both packages. The editor does not need RR.
• Load order does not matter. Both scripts register the same CodeEffects namespace, and whichever loads first defines it. The editor is looked up when RR needs it.
• RR configures its editors itself. You do not call $rule.init(..) for the editors inside RR, and you do not produce their globalData or editorData. To change how they behave, use the editor property of $repo.init(..).

Common Facts

• Both scripts are ES modules. Add them with <script type="module"> or import them in a React, Angular, or Vue application. Module scripts run in the order written once the page is parsed, so list your own script after them.
• Only the editor uses globals. It sets $rule and $ce. RR adds only the CodeEffects namespace to the global object, and its shortcut $repo exists only as the module export, or as CodeEffects.Rule.Repository.
• Neither script depends on a third-party library.
• Stylesheets: one common file and one theme per package. Reference the common stylesheet and either the light or the dark stylesheet of each package you use. See CSS Styles for the themes and what you can customize.
• The server does the work. The editor only builds and edits rules in the browser; your server evaluates them with the Rule Engine. RR keeps no data in the browser either: filtering, sorting, and paging all happen on the server.
• Your page owns the transport. The editor hands saved rules to your callbacks. RR hands every request to the requestCallback that you give to $repo.init(..). Neither one sends a request to your server by itself.
• Secure your endpoint. RR has no sign-in of its own. The endpoint it posts to must require your application's sign-in, must take the user from that sign-in rather than from the request, and must not allow cross-origin requests with credentials. Show RR's messages as text, never as HTML.
• Trusted Types. The editor needs no setup on a page that enforces Trusted Types. RR needs useTrustedTypes: true and a policy name allowed by your Content Security Policy; see $repo.init(..).
• Browsers. The Rule Editor supports all current versions of all major browsers.

Where to Go Next

• codeeffects.editor.js - the global functions, objects, events, and instance functions of the Rule Editor.
• codeeffects.repository.js - $repo.init(..) and the handle it returns.
• CSS Styles - the stylesheets of both packages, their themes, and how to customize them.
• Initialization of the Rule Editor - the server-centric and client-centric ways to start the editor.
• .NET API Reference - the server-side classes that produce the data these scripts consume, such as Control and the Repository namespace.
• Demo projects - working examples for different web platforms.