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

Collaborative Editing using WebRTC (only 2 peers supported) #3741

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@gziolo
Member

gziolo commented Nov 30, 2017

Implements: #1930.

Opened in place of #1877 to move development inside the upstream repository.

collab editing

The PR is experimental. Lacks some changes but a starting point.
Please note this is incomplete and is currently being updated.

Detailed Description:

  1. We create a Cediting instance inside middleware.

  2. Middleware is used to listen to all the actions being dispatched so that we can send those to P2P data channel. Few states are filtered in middleware that we don't send.

  3. For peer colors, we use a different action which is always dispatched when you select a block shown on the basis of peerID which is unique to each peer.

  4. Locking also happens on the basis of borders. If border for collaboration is visible on one peer side it is locked.

The module used is: https://github.com/abhishekgahlot/gutenberg-rtc
How GRTC works: https://github.com/abhishekgahlot/gutenberg-rtc/blob/master/DESIGN.md

TODO tasks

  • Serialization of data so it can be transferred to other peers (#1877 (comment)).
  • Add proper filtering for the Redux actions that are sent to peers.
  • Fix the edge case for 2 peers if one takes a longer time to connect can result in both peers in the unstable state.
  • Ability to queue data so that when another peer/user comes they can see the changes already done by another peer/user.
  • Optimization for XHR Polling.
  • Better UI/UX for users when they are connected (#1877 (comment)).
  • Locking of blocks is done by CSS so navigating by keyboard events is still possible.
  • Fix the case when a collaborator leaves, block remains locked.
  • We don't check user permissions for REST API calls.
  • Add missing @since in PHP file ( #1877 (comment)).
  • Extract withCoediting HOC to wrap the visual-block component (#1877 (comment)).
  • Move Coediting toogle to the ellipsis menu (#1877 (comment)).
  • Add support for multi-block select. Make sure frozen blocks are skipped.
  • Add editor's lock when 2 peers collaborate or collaboration disabled.
  • Create a draft before collaboration gets started to avoid duplicate posts/pages
  • Navigating between block with arrows doesn't freeze the active block.

Blockers

Improvements

@gziolo gziolo referenced this pull request Nov 30, 2017

Closed

Collaborative Editing using WebRTC ( Only 2 peers support ) #1877

2 of 14 tasks complete

@gziolo gziolo changed the title from Collaborative Editing using WebRTC ( Only 2 peers support ) to Collaborative Editing using WebRTC (only 2 peers supported) Nov 30, 2017

@gziolo gziolo force-pushed the try/coediting branch 5 times, most recently from a1f201f to db71cc9 Nov 30, 2017

@codecov

This comment has been minimized.

codecov bot commented Dec 1, 2017

Codecov Report

Merging #3741 into master will decrease coverage by 4.61%.
The diff coverage is 46.08%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master   #3741      +/-   ##
=========================================
- Coverage   42.41%   37.8%   -4.62%     
=========================================
  Files         307     284      -23     
  Lines        7295    6849     -446     
  Branches     1348    1252      -96     
=========================================
- Hits         3094    2589     -505     
- Misses       3521    3586      +65     
+ Partials      680     674       -6
Impacted Files Coverage Δ
editor/reducer.js 90.37% <ø> (ø)
editor/actions.js 47.16% <ø> (ø)
editor/store.js 83.33% <ø> (ø)
editor/selectors.js 93.46% <ø> (ø)
blocks/editable/index.js 10.1% <0%> (-0.65%) ⬇️
editor/edit-post/sidebar/post-settings/index.js 0% <0%> (ø) ⬆️
editor/edit-post/sidebar/coediting-panel/index.js 0% <0%> (ø)
editor/edit-post/sidebar/collaboration/index.js 0% <0%> (ø)
element/index.js 100% <100%> (ø) ⬆️
components/higher-order/with-filters/index.js 100% <100%> (ø) ⬆️
... and 216 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f9486f1...35df0a5. Read the comment docs.

@@ -0,0 +1,42 @@
/**

This comment has been minimized.

@gziolo

gziolo Dec 1, 2017

Member

Remove this file. Leftover from rebase.

);
}
return <OriginalComponent { ...originalProps } />;

This comment has been minimized.

@gziolo

gziolo Dec 4, 2017

Member

It would read better when we flip the condition and return this early.

}
// Generate a class name for the block's editable form
const generatedClassName = hasBlockSupport( blockType, 'className', true ) ?

This comment has been minimized.

@gziolo

gziolo Dec 4, 2017

Member

@aduth @youknowriad can we move it to EditBlock? I think it's internal thing which shouldn't be part of this and the original component.

This comment has been minimized.

@gziolo

gziolo Dec 18, 2017

Member

Moved in #4009.

const { attributes, name, isValid, uid } = block;
const blockType = getBlockType( name );
// Determine whether the block has props to apply to the wrapper.

This comment has been minimized.

@gziolo

gziolo Dec 4, 2017

Member

@aduth @youknowriad I copied it from the original component. Isn't wrapperProps something that should be part of the block object? If I follow properly the flow is as follows:

  • in a completely different place use registered block type to create block
  • her fetch block and its attributes
  • get block type again to generate wrapperProps based on block's attributes

This comment has been minimized.

@aduth

aduth Dec 5, 2017

Member

Isn't wrapperProps something that should be part of the block object? If I follow properly the flow is as follows:

I'd rather see this move to a block supports. Originally I'd intended for the block list to be unaware of alignment features, but I think it's such a base functionality that it's fine. Might be even better implemented as a hook.

@abhishekgahlot abhishekgahlot requested a review from mcsf Dec 4, 2017

@gziolo gziolo force-pushed the try/coediting branch from db71cc9 to 51121bd Dec 8, 2017

@gziolo

This comment has been minimized.

Member

gziolo commented Dec 8, 2017

Rebased with master and squashed commits to make future rebases less painful.

@gziolo gziolo force-pushed the try/coediting branch 2 times, most recently from 2cf21e0 to 0531a14 Dec 12, 2017

@gziolo gziolo force-pushed the try/coediting branch 3 times, most recently from 1583452 to 17cc7c2 Dec 18, 2017

@gziolo gziolo force-pushed the try/coediting branch from 17cc7c2 to 35df0a5 Jan 18, 2018

@gziolo gziolo requested review from mtias and youknowriad Jan 18, 2018

@gziolo

This comment has been minimized.

Member

gziolo commented Mar 7, 2018

I will rebase it next week. It's still work in progress put aside because it's not planned as a core feature for 5.0.

@aduth

This comment has been minimized.

Member

aduth commented Jul 31, 2018

Should we close this until it's given proper focus to be renewed? I can't imagine a rebase at this point will be easy / possible.

@gziolo

This comment has been minimized.

Member

gziolo commented Jul 31, 2018

Yes, let’s close it 👍

@gziolo gziolo closed this Jul 31, 2018

@gziolo gziolo deleted the try/coediting branch Aug 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment