OpenFn / OpenFn/lightning

Better implement collaborator presence & prevent flickering

Open
#4,057 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Elixir
Stars
296
Forks
86
Avg merge
1d 13h
Merged PRs (30d)
50

Description

User story

When a user is on the collaborative editor with other users, we want to

  1. know exactly what state the other users are in whether active|away|idle
  2. when users leave their tab to another tab, there's a change JS execution in the tab gets throttled which makes these users flicker. we need to resolve that.
Details
  • [a] Initial solution for this has been implemented via #3951 which caches all remote users to prevent the flickering. It also makes use of the lastSeen variable to determine the activity state of a user.
  • [b] There's another PR https://github.com/OpenFn/lightning/pull/4053 which uses a different method, two states, 1. lastSeen to keep updating ydoc and 2. lastState to determine the actual state of a user. It also solves flickering by only caching away users. This is because we can assert that, throttling is likely to only happen for away users.
Implementation notes

Since [a] has already been merged into main. there doesn't seem to be much conflict from [b] to main tho. but we need to make few changes to make sure [b] can land in main safe and beautifully.

  1. do we still need the caching at the useAwareness level? this is because [b] puts the caching at the useRemoteUsers level. useRemoteUsers is just like useAwareness but shows a single user for their several connections sorted by the active connection then lastSeen.

  2. rebase [b] onto main

  3. resolve the difference in tests between [b] and [a]

Release notes
User acceptance criteria

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the useAwareness and useRemoteUsers entry points, then compare PR #4053 with main and the tests changed by PR #3951. Done means the selected presence-state and caching approach is rebased cleanly, avoids away-user flickering, and has reconciled tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
elixir
Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.