⚡️Fleek Platform Agents UI

The Agents UI provides standalone functionality for the Eliza Agents. Originally it is implemented in the fleek-platform/website repository but the team took a decision to extract it into a separate, standalone package for maintainability purposes, separating concerns and easier management of requirements.
There was a transition period when code lived in both repositories and had to be encapsulated and synced to prevent diversion and maintenance overhead.
Overview
Install
Install the package by executing:
npm i @fleek-platform/agents-ui
⚠️ If you're planning to contribute as a developer, you must install pnpm, otherwise most commands will fail.
For a quick start, learn the basic usage.
Development
For developers looking to contribute to the @fleek-platform/agents-ui
, clone the repository and follow the contribution guide.
For runtime we utilize Nodejs and PNPM as the package manager.
Next, install the project dependencies:
pnpm i
Environment variables
If you'll be interacting with services, you'll need to set up the environment variables.
Create a local file named .env
and declare the following environment variables for the environment you're interested (below we're using the public~production settings):
PUBLIC_FLEEK_REST_API_URL="https://api.fleek.xyz"
PUBLIC_UI_APP_URL="https://app.fleek.xyz"
PUBLIC_BEEHIIV_PROXY_SERVER_URL="https://faas-lon1-917a94a7.doserverless.co/api/v1/web/fn-5aaf2a72-1b5b-4ac6-8c42-a2e735a32d8b/main/create-subscription"
The application uses the getDefined to lookup for environment variables.
Changeset
Manage the versioning of changelog entries.
Declare an intent to release by executing the command and answering the wizard's questions:
pnpm changeset:add
Basic usage
Package is distributed as ESM module that exports source code, transpiling and processing is left to the host application. To use it, you need to do the following:
- Make sure that it is included as a dependency.
"dependencies": {
"@fleek-platform/agents-ui": "*",
}
- Import
ElizaIntegrationLayer
component and pass the required props.
Interface
Package defines the expected interface inside the ElizaIntegrationLayer.tsx component. The host app is expected to pass the following props:
export interface ElizaIntegrationLayerProps {
isLoggedIn: boolean;
isLoggingIn: boolean;
login: () => Promise<void>;
fetchFleekToken: (projectId?: string) => Promise<string | undefined>;
getSubscriptions: getSubscriptionsType;
getPlans: getPlansType;
activeProjectId: string;
}
type getSubscriptionsType = (projectId?: string, token?: string) => Promise<{ ... }>;
type getPlansType = (token?: string) => Promise<{ ... }>;
Not all data is passed via props, additional data is passed via the src/settings.json
common configuration file. Components inside the src/components/Eliza
import this file. These are the required fields by the package (host app may define other, additional fields):
{
"elizaPage": {
"endpoints": {
"aiAgents": "ai-agents endpoint url"
},
"agentsDashboardPage": "dashboard url"
}
}
💡 Note: You must use relative import for this file.
import settings from '../../../settings.json';
import settings from '@base/settings.json';
Example usage
Example usage inside the host app:
import { ElizaIntegrationLayer, api } from '@fleek-platform/agents-ui';
const {
createSubscription,
getPlans,
getSubscriptions,
} = api;
export const AgentsUIIntegration: React.FC = () => {
const { triggerLoginModal, accessToken, isLoggingIn, isLoggedIn, projectId } =
useAuthStore();
const login = () =>
typeof triggerLoginModal === 'function' && triggerLoginModal(true);
return (
<ElizaIntegrationLayer
accessToken={accessToken}
activeProjectId={projectId}
isLoggedIn={isLoggedIn}
isLoggingIn={isLoggingIn}
login={login}
getSubscriptions={getSubscriptions}
getPlans={getPlans}
createSubscription={createSubscription}
/>
);
};
const AgentsUI: React.FC = () => <AgentsUIIntegration />;
export default AgentsUI;
Transition period
The original implementation is located in src/components/Eliza. The main goal is encapsulation, allowing it to be synced with a simple copy/paste of the src/components/Eliza
directory. There are only a few external files; those are src/settings.json
and the files inside src/utils
directory. If they are changed they need to be updated too.
├── src
│ ├── components
│ │ └── Eliza
│ │ ├── api
│ │ ├── components
│ │ ├── hooks
│ │ └── utils
│ ├── settings.json
│ └── utils
│ ├── cn.ts
│ └── common.ts
Known issues
- The package currently does not export fonts used by Tailwind theme. The host application needs to have them installed.
AtypDisplay, IBM Plex Sans, IBM Plex Mono
- Import path alias for the
src/settings.json
breaks. Components must use relative imports for this file only. Other files can use absolute imports using path aliases defined in the tsconfig.json
.
import settings from '@base/settings.json';
- Local testing with a local file-based dependency will fail and produce false negative. You need to publish a private test package to the Github registry and include it as a dependency in the host project.
Incorrect:
"@fleek-platform/agents-ui": "file:../agents-ui",
npm i --install-links
Correct:
"version": "0.0.0-test-1",
"private": true,
//npm.pkg.github.com/:_authToken=my-github-token
@fleek-platform:registry=https://npm.pkg.github.com
npm publish
"@fleek-platform/agents-ui": "@fleek-platform/agents-ui@0.0.0-test-1",
npm i
Contributing
This section guides you through the process of contributing to our open-source project. From creating a feature branch to submitting a pull request, get started by:
- Fork the project here
- Create your feature branch using our branching strategy, e.g.
git checkout -b feat/my-new-feature
- Run the tests:
pnpm test
- Commit your changes by following our commit conventions, e.g.
git commit -m 'chore: 🤖 my contribution description'
- Push to the branch, e.g.
git push origin feat/my-new-feature
- Create new Pull Request following the corresponding template guidelines
Branching strategy
The develop branch serves as the main integration branch for features, enhancements, and fixes. It is always in a deployable state and represents the latest development version of the application.
Feature branches are created from the develop branch and are used to develop new features or enhancements. They should be named according to the type of work being done and the scope of the feature and in accordance with conventional commits here.
Conventional commits
We prefer to commit our work following Conventional Commits conventions. Conventional Commits are a simple way to write commit messages that both people and computers can understand. It help us keep track fo changes in a consistent manner, making it easier to see what was added, changed, or fixed in each commit or update.
The commit messages are formatted as [type]/[scope]
The type is a short descriptor indicating the nature of the work (e.g., feat, fix, docs, style, refactor, test, chore). This follows the conventional commit types.
The scope is a more detailed description of the feature or fix. This could be the component or part of the codebase affected by the change.
Here's an example of different conventional commits messages that you should follow:
test: 💍 Adding missing tests
feat: 🎸 A new feature
fix: 🐛 A bug fix
chore: 🤖 Build process or auxiliary tool changes
docs: 📝 Documentation only changes
refactor: 💡 A code change that neither fixes a bug or adds a feature
style: 💄 Markup, white-space, formatting, missing semi-colons...