Collaborative Editing using WebRTC (only 2 peers supported)#3741
Collaborative Editing using WebRTC (only 2 peers supported)#3741
Conversation
a1f201f to
db71cc9
Compare
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
| @@ -0,0 +1,42 @@ | |||
| /** | |||
There was a problem hiding this comment.
Remove this file. Leftover from rebase.
coediting/hooks/index.js
Outdated
| ); | ||
| } | ||
|
|
||
| return <OriginalComponent { ...originalProps } />; |
There was a problem hiding this comment.
It would read better when we flip the condition and return this early.
coediting/hooks/index.js
Outdated
| } | ||
|
|
||
| // Generate a class name for the block's editable form | ||
| const generatedClassName = hasBlockSupport( blockType, 'className', true ) ? |
There was a problem hiding this comment.
@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.
coediting/hooks/index.js
Outdated
| const { attributes, name, isValid, uid } = block; | ||
| const blockType = getBlockType( name ); | ||
|
|
||
| // Determine whether the block has props to apply to the wrapper. |
There was a problem hiding this comment.
@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
wrapperPropsbased on block'sattributes
There was a problem hiding this comment.
Isn't
wrapperPropssomething that should be part of theblockobject? 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.
|
Rebased with master and squashed commits to make future rebases less painful. |
2cf21e0 to
0531a14
Compare
1583452 to
17cc7c2
Compare
|
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. |
|
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. |
|
Yes, let’s close it 👍 |
Implements: #1930.
Opened in place of #1877 to move development inside the upstream repository.
The PR is experimental. Lacks some changes but a starting point.
Please note this is incomplete and is currently being updated.
Detailed Description:
We create a Cediting instance inside middleware.
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.
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.
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
@sincein PHP file ( Collaborative Editing using WebRTC ( Only 2 peers support ) #1877 (comment)).withCoeditingHOC to wrap the visual-block component (Collaborative Editing using WebRTC ( Only 2 peers support ) #1877 (comment)).Blockers
Improvements