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

Postfixing should be simpler #4161

Closed
pjasiun opened this issue Aug 24, 2017 · 5 comments
Closed

Postfixing should be simpler #4161

pjasiun opened this issue Aug 24, 2017 · 5 comments

Comments

@pjasiun
Copy link

pjasiun commented Aug 24, 2017

It's pretty common case that some plugin listens on the change event and what to apply some changes.

It's pretty simple to make it works, but you need a lot of know-how to make it works well. You need to remember about couple thing.

  • You need to enqueueChanges, otherwise there might be no render call.
  • Check if the batch is not transparent, otherwise, some not obvious problems in collaboration will appear.
  • Remember that before enqueueChanges block some other changes may happen and that we need to check it again inside the block if the condition is still valid.
  • Take care not to apply a fix for every enqueueChanges if it's needed only once.

We need a helper which will do all of this for us, so all fixers will work well. It could get 2 functions as parameters: condition and action, and take care about everything.

@pjasiun
Copy link
Author

pjasiun commented Aug 24, 2017

@scofalik
Copy link
Contributor

Remember that before enqueueChanges block some other changes may happen and that we need to check it again inside the block if the condition is still valid.

Recently we had that dilemma with @Reinmar. We agreed that having "empty" doc.enqueueChanges call is fine, so it's fine to check only inside doc.enqueueChanges. However, I could imagine that might be some cases where we, for some reason, need to check before calling enqueueChanges, and inside the call.

Take care not to apply a fix for every enqueueChanges if it's needed only once.

I am not sure how you want to prevent this :S. I mean, isn't this the same as just checking whether a change still should be applied (so the same as point above)?

@pjasiun
Copy link
Author

pjasiun commented Aug 24, 2017

Remember that before enqueueChanges block some other changes may happen and that we need to check it again inside the block if the condition is still valid.
Recently we had that dilemma with @Reinmar. We agreed that having "empty" doc.enqueueChanges call is fine, so it's fine to check only inside doc.enqueueChanges. However, I could imagine that might be some cases where we, for some reason, need to check before calling enqueueChanges, and inside the call.

Take care not to apply a fix for every enqueueChanges if it's needed only once.
I am not sure how you want to prevent this :S. I mean, isn't this the same as just checking whether a change still should be applied (so the same as point above)?

It would be very bad for the efficiency. You will add callback function for event change, even if it's not needed.

@pjasiun
Copy link
Author

pjasiun commented Aug 24, 2017

Instead, we should:

  • check the condition,
  • if passed, add enqueueChanges block,
  • save the information that the block is added and do not add it again for the further change events,
  • when enter to the enqueueChanges block check the condition again,
  • execute action.

@pjasiun
Copy link
Author

pjasiun commented Dec 19, 2017

It's partially done, together with introducing differ, and will be fixed by https://github.com/ckeditor/ckeditor5-engine/issues/1207.

@pjasiun pjasiun closed this as completed Dec 19, 2017
@mlewand mlewand transferred this issue from ckeditor/ckeditor5-engine Oct 9, 2019
@mlewand mlewand added this to the iteration 14 milestone Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants