Skip to content
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 from

Conversation

@gziolo
Copy link
Member

@gziolo 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 mentioned this pull request Nov 30, 2017
2 of 14 tasks complete
@gziolo gziolo changed the title Collaborative Editing using WebRTC ( Only 2 peers support ) Collaborative Editing using WebRTC (only 2 peers supported) Nov 30, 2017
@gziolo gziolo force-pushed the try/coediting branch 5 times, most recently to db71cc9 Nov 30, 2017
@codecov
Copy link

@codecov 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
Author Member

Remove this file. Leftover from rebase.

);
}

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

This comment has been minimized.

@gziolo

gziolo Dec 4, 2017
Author 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
Author 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
Author 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
Author 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
Copy link
Member Author

@gziolo 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 to 0531a14 Dec 12, 2017
@gziolo gziolo force-pushed the try/coediting branch 3 times, most recently 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
Copy link
Member Author

@gziolo 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
Copy link
Member

@aduth 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
Copy link
Member Author

@gziolo gziolo commented Jul 31, 2018

Yes, let’s close it 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants