-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Introduce lock mechanism for Editor#isReadOnly #11441
Conversation
This major breaking change breaks our integrations that set Now, integrations have to support both forms - the previous (as mentioned above), and the new one (that the PR adds). |
Yes... Perhaps we can still support the old behavior and when encountering this kind of assignments we can try to set/remove a custom lock instead. I'll research it tomorrow. |
During a recent discussion with @scofalik we decided that we can do a breaking change and then release major releases in our integrations (the BC in these integrations will be the fact that they will be working only with CKEditor 5 v34+), so they will not have to support two versions at the same time. Introducing a lock mechanism from custom assignments looks pretty bad, imagine this situation: editor.isReadOnly = false; // clears a custom assignment lock on the `isReadOnly` property.
editor.isReadOnly // still `true` as other features may still have their locks on the `isReadOnly` property. TBH, the fact that integrations also change the |
I have nothing to do with the API, as you know better what you want to achieve. I agree that the proposed method is much better than a single property. However, we cannot assume people update their builds. They don't have to, and it's our responsibility to think about it. So, integrations must detect (somehow) a version of the CKEditor 5 API and, based on that, use old or new API. In the worst scenario, if we cannot support both APIs, we need to release new versions of integrations with adjusted API. |
But we will, it's obvious. If we make breaking change in our code, we will fix it :). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like current method names, I propose:
setReadOnly( id )
andclearReadOnly( id )
, orenableReadOnly( id )
anddisableReadOnly( id )
.
I understand that setReadOnly( 'foo' )
looks like we are setting the property value to 'foo'
, hence the second proposal.
Other than that, maybe you could also check if manually firing set:...
event has any change working with bind()
and if there are other mechanisms that we should also consider.
* | ||
* @param {String} lockId The lock ID for setting the editor to the read-only state. | ||
*/ | ||
hasReadOnlyLock( lockId ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if this method is actually needed after giving it a second thought. In overwhelmingly most cases, you set read only basing on another value/event, for example, when the internet connection is turned off, or when you switch on/off a feature, etc.
It looks like this is useful mostly for "toggle buttons" but such buttons do not really exist in real integrations. Do we need hasReadOnlyLock()
in our own code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I remember there is no place where this method is used in the source code, but as for the tests there is currently no other way to write it without using the hasReadOnlyLock()
. I was thinking about just using the Editor.isReadOnly
in manual tests but then these buttons will look broken 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So without using hasReadOnlyLock
we would have to either use internals, Editor.isReadOnly
, I don't have other ideas.
Co-authored-by: Szymon Cofalik <s.cofalik@cksource.com>
Co-authored-by: Szymon Cofalik <s.cofalik@cksource.com>
…e:isReadOnly correctness.
LGTM except of the new method names.
I also think that |
…clearReadOnlyLock to editor.clearReadOnly.
@ckeditor/qa-team Can I ask you to test this PR? I changed also the Unfortunately, there are a lot of places where we use or observer |
…clearReadOnly to editor.clearReadOnlyMode.
…yMode()` to `disableReadOnlyMode()`.
I've tested this PR, and also CF branch related to this changes and everything seems fine. The lock mechanism is working correctly. I've also tested CF features where read-only mode can be set and that was also working correctly 👍 |
Migration guide missing 😬 |
Can we add this guide as a follow-up? The DLL changes already introduce the migration guide for the next iteration and I'd be happy to not merge these files if I do not have to :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reworded the migration guide a bit 😬
I thought that it will be fine and you rewrote it from scratch ;p |
It's not at all from scratch. In one place it looks like a lot of changes but I just changed the order. |
Suggested merge commit message (convention)
Feature (core): Introduced locking mechanism for
Editor#isReadOnly
. Read-only mode can now be separately enabled and disabled by multiple features which allows for proper control without conflicts between features. Closes #10496.Other (core):
Editor#isReadOnly
is now a read-only property.MAJOR BREAKING CHANGE: The
Editor#isReadOnly
property is now read-only. From now, this property is controlled byEditor#enableReadOnlyMode( lockId )
andEditor#disableReadOnlyMode( lockId )
, which allow controlling theEditor#isReadOnly
state by more than one feature without collisions.Additional information
For example – encountered issues, assumptions you had to make, other affected tickets, etc.