Firepad

History

Firepad was originally developed by Firebase Team at Google™ to showcase a Serverless and easily configurable Collaborative experience in the year of 2013.

At first it started out with only CodeMirror editor with Rich Text support using OT to maintain consistency and concurrency. Over the years, open source contributors across the globe have added support for Ace and more recently Monaco editor, and improved overall product.

Why this Rewrite was necessary

Over the time, with more editor support the codebase got quite convoluted. And every new commit would increase cognitive complexity exponentially, making it harder for the next person to debug any issue. Also keep in mind, the library was designed when JavaScript language itself was quite in early phase.

In recent years, we have seen web editor and IDE domain being dominated by Monaco editor from Microsoft™ and Theia from Eclipse Foundation respectively. Both of these products are written in TypeScript, a modern type-safe language with superset features of JavaScript, with proper engineering and architecture in place.

So it was about time, that same would happen to Firepad, and we just pulled the plug. We have rewritten all the modules and few extras using TypeScript while enhancing earlier implemented Adapter Pattern to integrate with external modules, such as Database (preferably Firebase) and editors (as of now only Monaco is supported, but PRs are welcomed). In this process, we have also made few minor improvments to scale at performance (e.g., Treeshaking) and ease of usage while keeping internal modules safe.

Usage

Public API

Firepad takes two dependencies, one Database Adapter and one Editor Adapter, with a custom configuration object like the following:

import Firepad, { IDatabaseAdapter, IEditorAdapter, IFirepadConstructorOptions } from "@hackerrank/firepad";

const databaseAdapter: IDatabaseAdapter = ...; // Database Adapter instance

const editorAdapter: IEditorAdapter = ...; // Editor Adapter instance

const options: IFirepadConstructorOptions = {
   /** Unique Identifier for current User */
  userId: ..., // string or number
  /** Unique Hexadecimal color code for current User */
  userColor: ..., // string
  /** Name/Short Name of the current User (optional) */
  userName: ..., // string
  /** Default content of Firepad (optional) */
  defaultText: ..., // string
};

const firepad = new Firepad(databaseAdapter, editorAdapter, options);

Monaco as editor

If you use Monaco as an editor, we have an shorthand function fromMonaco to provide adapters and the binding out of the box with optional configuration object:

import { fromMonaco } from "@hackerrank/firepad";

const databaseRef: string | firebase.database.Reference = ...; // Path to Firebase Database or a Reference Object

const editor: monaco.editor.IEditor = ...; // Monaco Editor Instance

const firepad = fromMonaco(databaseRef, editor);

Writing Custom Adapters

To use Firepad with any other Editor, one simply need to write an implementation of Editor Adapter interface for that editor. This can be done like this:

import { IEditorAdapter } from "@hackerrank/firepad";

class MyEditorAdapter implements IEditorAdapter {
  ...
}

Similar thing can be done for Database as well by implementing IDatabaseAdapter interface. Keep in mind, you might also need to implement event handlers and event triggers depending upon nature of the adapters.

Development

We have used yarn as our package manager through out the project.

We use webpack-dev-server for local development environment and webpack for bundling. After installing all the dependencies including all the devDependencies and updating Database (Firebase) configuration, just do yarn start to kickoff development server. By default, the dev server opens in localhost:9000 but this can be configured by passing additional --port argument to the start command.

We use jest as both test runner and test suite to write unit tests. Doing yarn test should run all the testcases and publish coverage report.

Directories

1. examples - All the working examples are kept and used for manual testing during development.
2. src - Source directory for all the modules.
3. test - Specs directory for all the modules.

Changelog

See CHANGELOG for more details.

Contributing

See CONTRIBUTING GUIDELINES for more details.

License

See LICENSE for more details.