Current situation
When the editor switches the read-only mode, it will perform the following two sub-actions:
- Clear all blocks
- Render the blocks you just cleared again
This is very unfriendly to the experience of collaborative editing scenes
Impact on the data layer
Whether the data layer of the collaborative editing scenario listens for data changes through onchange or DOM Mutation API, when the editor performs the first sub-action of switching read-only mode, the data layer will immediately send a message to clear all blocks to the back-end service, which will also cause the back-end service to immediately clear all blocks data; When the editor completes the second sub-action of switching read-only mode, it will cause the data layer to immediately send the message of all blocks before adding to the back-end service, which will cause the back-end service to add the blocks data just cleared back to the database.
What problems will this cause?
- Lost history details
In the collaboration scenario, we need to know which user added what content, for example, user x added hello and user y added world. We can easily distinguish this information in the collaborative data layer.
However, after the editor has performed at least one read-only mode switch, the above information will be lost.
- Unnecessary network data transmission
When the editor switches to the read-only mode, it is unnecessary to waste performance and resources by clearing all blocks data and adding back all blocks data to the back-end service.
Solution
- Open a new mandatory API for all plug-ins, requiring plug-ins to implement read-only mode by themselves
- The editor reconstructs the current logic of switching to read-only mode. Only when the plug-in does not implement the API of switching read-only mode by itself, it only performs the default action of switching read-only mode for specific blocks: try to remove the
contenteditable attribute in the default container
Current situation
When the editor switches the read-only mode, it will perform the following two sub-actions:
This is very unfriendly to the experience of collaborative editing scenes
Impact on the data layer
Whether the data layer of the collaborative editing scenario listens for data changes through
onchangeorDOM Mutation API, when the editor performs the first sub-action of switching read-only mode, the data layer will immediately send a message to clear all blocks to the back-end service, which will also cause the back-end service to immediately clear all blocks data; When the editor completes the second sub-action of switching read-only mode, it will cause the data layer to immediately send the message of all blocks before adding to the back-end service, which will cause the back-end service to add the blocks data just cleared back to the database.What problems will this cause?
In the collaboration scenario, we need to know which user added what content, for example, user x added
helloand user y addedworld. We can easily distinguish this information in the collaborative data layer.However, after the editor has performed at least one read-only mode switch, the above information will be lost.
When the editor switches to the read-only mode, it is unnecessary to waste performance and resources by clearing all blocks data and adding back all blocks data to the back-end service.
Solution
contenteditableattribute in the default container