> For the complete documentation index, see [llms.txt](https://docs.rierino.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rierino.com/design/pro-code.md).

# Pro-Code

Rierino JavaScript SDK provides ability to build highly customized UI components and use them as part of the low-code development environment.

A custom component is a **single JSX code** that:

* is written in plain JavaScript (no TypeScript),
* exports a React component as its **default export**,
* may import from a fixed set of platform modules and from `esm.sh`,
* runs as part of the application, not in a sandbox.

The smallest working component:

```jsx
import React from "react";

export default function Hello(props) {
  return <div>Hello {props.data?.name}</div>;
}
```

Everything else in this documentation is about two questions: **what can I import** and **what props do I get**.

## Custom coded sections

There are five places you can put custom code. Each one decides how much of the surrounding screen the platform still builds for you and which props your component receives.

Pick the one that matches how much control you want:

| You want to…                                | Use                      |
| ------------------------------------------- | ------------------------ |
| replace record listings                     | **Custom lister**        |
| replace single record editors               | **Custom object editor** |
| reuse one custom widget across many screens | **Custom component**     |
| build a whole page from scratch             | **Custom page**          |
| replace the login & landing pages           | **Special template**     |

## Custom code formats

Whatever you are building a list, an editor or a page it goes through one compiler. You supply the code in one of two ways and the dashboard decides which based on how you configured the screen:

* **Inline code**: the JSX you type into the code editor. It is compiled in the browser as you edit, after a short debounce, so you get a live preview.
* **A stored component**: code saved as a reusable component record and referenced by id. It is compiled once on the server and delivered ready-to-run.

Inline code is the fast path while you are designing. A stored component is the right choice for anything reused across screens and it is lighter for the browser, since no compiler needs to load. Both accept exactly the same code.

## Main requirements

* **Default export**: The component is loaded from the module's default export. It must be a function component, a class component, or a `React.forwardRef(...)` result. A `React.memo(...)` result is **not** accepted directly, so wrap it like:

```jsx
const Inner = React.memo(MyComponent);
export default (props) => <Inner {...props} />;
```

* **Single file**: There is no file system behind your code. No relative imports (`./utils`), no splitting a component across files. If you need shared logic across screens, save it as a stored component and reference it.
* **JavaScript, not TypeScript**: Type annotations are a compile error.
* **Import React**: Always write `import React from "react"` even if you never reference `React` by name.

## Component caching

Compiled output is cached, keyed by the **component key** you configure (`editorType` in a screen configuration, or the record id for a stored component). The cache always verifies your source before reusing an entry, so editing code always recompiles, so you will never see a stale build.

The caveat is *collisions*: two different components sharing one key will keep evicting each other and recompile every time you switch between them. Give each custom component its own key.

Most screen types fall back to a key derived from the data source when you don't set one. That default is convenient but not always unique, for custom object editors in particular it can resolve to the same value for every editor in the app. **Set the component key explicitly.** If you leave it empty entirely, caching is skipped and your code recompiles on every mount.

## Custom code access

Because it runs in the page rather than in a sandbox, your component has access to the browser (`window`, `document`, `localStorage`), the session and the platform modules documented here. Treat custom code with the same care as application code: review it and don't paste in code you don't trust.

{% hint style="info" %}
You can use Rierino AI assistants to create custom coded components and listers from within the UI or using our [Rierino Claude Marketplace Plugin](https://github.com/rierino-open/rierino-claude-plugin).
{% endhint %}

{% embed url="<https://www.linkedin.com/pulse/vibe-code-edges-constrain-core-architecture-ai-built-enterprise-yglie>" %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rierino.com/design/pro-code.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.