Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@hackerrank/firepad

Package Overview
Dependencies
Maintainers
3
Versions
80
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@hackerrank/firepad

Collaborative text editing powered by Firebase

  • 0.7.1-beta-1
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
496
increased by47.62%
Maintainers
3
Weekly downloads
 
Created
Source

Firepad

Deployment Maintainability Test Coverage Node Version Version Beta Version Weekly Downloads Built With Tested With Typed With Styled With License Open Issues Closed Issues Open Pulls Closed Pulls Contributors Activity

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.

Keywords

FAQs

Package last updated on 28 Nov 2022

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc