forked from share/sharedb
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP Presence continuation #3
Open
curran
wants to merge
225
commits into
Teamwork:sync-presence
Choose a base branch
from
curran:presence-continuation-2
base: sync-presence
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reconnecting Websocket Example and Updated Readme
This is a slightly speculative fix for a test that fails intermittently on `sharedb-mongo`. I believe these intermittent failures are due to a race condition in a concurrency test. The test works by attempting to fire two commits off at the same time, and hoping that one of them is committed just before the other, so that a `SubmitRequest.retry` is triggered whilst the `maxSubmitRetries` is set to `0`, resulting in an error that is expected. However, I believe it's possible for these commits to (in some cases) happen sequentially rather than concurrently, and fail to error. This change attempts to force them into this retry condition by: - Catching both ops in the `commit` middleware, _just_ before they're about to be committed (and hit a `retry` if applicable) - Waiting until both ops have reached this state - Triggering the first op's `commit` - Then in the callback of that op, triggering the second op's `commit` - The second op should now find that the first op has beaten it to committing, and trigger a `retry`
See [this issue][1]. [1]: share#226 (comment)
Add note about projectsSnapshots property
Update mocha and fix 2 tests
Fix flaky maxSubmitRetries test
Allow op to be a non-object
Fix Doc.prototype.destroy
Remove sharedb-mingo-memory circular dependency
…ures Warn about using deprecated features
Closed
fix: repair broken link
in chrome 51, will throw error Uncaught TypeError: Illegal invocation
Deal with Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=179628
fix: Uncaught TypeError: Illegal invocation in chrome 51
Update rest of examples to @teamwork/websocket-json-stream
Fix broken status indication in textarea example
The database adapters allow an `options` object to be passed through to them for enabling the return of metadata with a snapshot or ops. Consumers could query the database directly, or even use the database adapters, but this may give inconsistent results when comparing ops with those fetched through `getOps`. For example, the Mongo adapter makes sure that a valid set of ops with unique versions are returned, which may not be the case when querying the database directly. Fetching ops and snapshots through `Backend` methods also ensures that we call the appropriate "sanitize" methods, and trigger the corresponding middleware. However, we don't expose this on `Backend.getOps` or `Backend.fetch`. This change adds an optional `options` argument to these methods, which can then be used to ask for metadata. Note that an options argument has been added to `Backend.subscribe`, but using it will return an error. This is to keep the signature consistent with `fetch` and `getOps`. However, the implementation is beyond the scope of this change, because we'd need to add some way to configure `SubmitRequest.commit` to optionally pass metadata to the appropriate clients, who provided that given option on `subscribe`.
Allow options to be passed for `fetch` and `getOps`
This change addresses three things: 1. Move us from `jshint` to `eslint` (which is the more commonly used linter) 2. Fix our linting glob patterns, which currently only address files at the top of their respective directories (and ignore all files in subdirectories) 3. Enforce stricter linting rules, based roughly on the [Google][1] rules [1]: https://github.com/google/eslint-config-google
Large indentation fixes were skipped in the previous commit in order to keep the diff a bit less noisy. This change purely removes the eslint ignore comments, and fixes the indentation in those files.
This change actively extends the Google ESLint config. We move the config into a `.js` file so that we can add comments about particular rules that we've overridden. This change also fixes some trailing comma and indentation linting errors.
This change uses our `.gitignore` file to define which files ESLint should ignore, so that all of our committed JavaScript has a consistent style.
This change makes some linting review markups: - pre-comupte long, concatenated strings - only allow one statement per line
Linter fixes
…curran/sharedb with latest share/sharedb upstream
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Creating this PR just to check how this PR https://github.com/share/sharedb/pull/288/files has diverged from the original share#207 .
Note: the latest work on presence from me is in this PR here share#288