Operational Transformation

Description

Collection of Operation Transformation Algorithms and their respective clients to integrate with any existing system.

Package	Version	Downloads	Third-party Dependency
ace
firebase-ace
firebase-monaco
firebase-plaintext
monaco
plaintext			-
plaintext-editor			-
state-machine			-
types	-	-	-
utils	-	-	-

Installation

This repository uses monorepo architecture for hosting packages. We are using Lerna to manage workspaces and publishing of individual packages, where as Pnpm is used as package manager to symlink and install External Dependencies.

To install using Pnpm (recommended):
```
pnpm install -r
```
To install using Lerna:
```
lerna bootstrap
```

Testing

We are using Jest extensively to form our Unit Test Suite as well as Integration Test Suites, along with test environment, stubs and test runner. Nyc (formerly known as Istanbul) is used for coverage reporting.

To run all the unit test suites in local dev environment, run the following after dependencies have been installed:
```
pnpm test
```
To run unit tests in CI environment, run:
```
pnpm test:ci
```
To run integration tests in CI environment, run:
```
pnpm test:firebase
pnpm test:monaco
```
To merge all the individual code coverage report and generate final test coverage report, run:
```
pnpm run coverage
```
To convert generated final coverage report into more human readable form (such as lcov), run:
```
pnpm run coverage:dev
```

Integration Tests

This package only provides a functional layer on top of your existing dependencies and does not ship any additional bundle. To make sure our implementation and integrations are up-to-date, we have a comprehensive set of Integration Test Suite living in tests directory.

Editor Integration

Most of the popular editors and IDEs have extensions to help with Code Coverage details. These tools often read lcov reports and not json format. So one must convert them into lcov using last command described above to make it work with the editor of their choice.

Metrics and Tracking

We are using codecov.io to track progress over Code Coverage and CodeQL for Code Quality Analysis.

Reporting a Bug

Head on to Discussion section to report a bug or to ask for any feature. Use this template to make it structural and helpful for the maintainer and the contributors. Feel to add your queries about using this library as well under Q & A section of it. Remember, do not create any Issues by yourself, maintainers of this repository will open one if deemed necessary.

Changelog

See CHANGELOG for more details.

Contributing

See Contributing Guidelines.

License

This project is licensed under the terms of the MIT license, see LICENSE for more details.

Update aceContent implementation in TooltipMarker.ts

Discussed in #97

^{Originally posted by lakbychance October 20, 2021}
https://github.com/Progyan1997/Operational-Transformation/blob/c743cc51648d544c1a783b66e0c81dc208e0e593/packages/ace/src/tooltip-marker.ts#L52

Hey @Progyan1997 , I thought about this code here and I feel that this piece of code works for now but depends on querySelector to retrieve the ace_content div. Instead of that I think we can shift this code inside the update method and use closest to append the tooltip marker like so :-

    if (!this._aceContent) {
      this._aceContent = markerLayer.element.closest('.ace_content');
      this._aceContent.append(this._tooltipWidget);
    }

where _aceContent is a new property on TooltipMarker class. We can also not introduce this new property and instead run the closest and append operation every time which will result in same behavior.

What do you think ? If you would wanna go with this, would you choose introducing _aceContent or performing closest and append every time ?

My intuition for this change - The reason is possible collision of same class names can break this with top to bottom existing approach. In bottom to top with closest the probability is very less unless user manipulates the editor DOM nodes itself.

0xtheprodev / operational-transformation Goto Github PK