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

Refactored duplicated throttle and eventsBuffer code #2060

Merged
merged 11 commits into from
Sep 1, 2018
Merged

Refactored duplicated throttle and eventsBuffer code #2060

merged 11 commits into from
Sep 1, 2018

Conversation

jacekbogdanski
Copy link
Member

What is the purpose of this pull request?

Task

What changes did you make?

Refactored duplicated throttle and eventsBuffer code.

Closes #2045

@mlewand
Copy link
Contributor

mlewand commented Jul 6, 2018

Changed target branch to major. Rebased onto latest master branch.

@mlewand mlewand changed the base branch from t/1751 to master July 6, 2018 15:14
@mlewand mlewand changed the base branch from master to major July 6, 2018 15:16
Copy link
Contributor

@mlewand mlewand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code works however I have some real doubts regarding code readability. For instance look at input method for someone reading that at first it's hard to tell exactly what is the reason for this order.

Instead I think it would be much more readable if we create a type for return values of tools.throttle and tools.eventsBuffer, especially given that we'll have a better docs for that and the types will be extensible themselves.

I created a test implementation for that in t/2045b branch. See how only the ThrottleBuffer is concerned about keeping arguments. EventsBuffer does not need to know anything about that.

However doing it that way will require us to put it in the major release, as it is an API addition. Also the types need to be exposed, and to go along with our standards the proposed type names should be lowercased which will result with... a name collision in case of EventsBuffer. I'm thinking about extracting it into a separate namespace within tools, so it could be like:

  • CKEDITOR.tools.buffers.throttle - ThrottleBuffer type
  • CKEDITOR.tools.buffers.event - EventsBuffer type


function triggerOutput() {
lastOutput = ( new Date() ).getTime();
scheduled = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This var should be consistent and use 0 here.

@jacekbogdanski jacekbogdanski self-assigned this Jul 17, 2018
@jacekbogdanski
Copy link
Member Author

I agree that it could be simplified and better designed. Your changes look good and I didn't have a better option here than just use your branch. I added additional docs fixes and justified tests for new buffers.

@jacekbogdanski jacekbogdanski removed their assignment Jul 17, 2018
@mlewand mlewand self-assigned this Aug 13, 2018
Copy link
Contributor

@mlewand mlewand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have checked the code and initially I have overlooked one thing - often times context of buffer.input would be changed (and it's a very common case).

Again I have pushed the proposed code to t/2045b branch. The fix is creating a new input function (as a prop) that is bound to buffer context passed though the scope.

Works fine now, but please have a look at it and merge it. I'm concerned only about the docs. You need to do some serious clicking before you get to meaningful code listing 🤔

@jacekbogdanski
Copy link
Member Author

Looks ok, I refactored docs a little - I think it's easier to track docs when they are as close as possible to a declared function. However, with all these changes refactored buffers seems slightly complicated, mostly thus creating input function inside constructor which isn't common practice.

…ing can be found for easier discoverability.
@mlewand
Copy link
Contributor

mlewand commented Sep 1, 2018

I agree that it got more complicated. I don't like it, but we have spent already enough time trying to simplify this code.

Copy link
Contributor

@mlewand mlewand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I just added some extra references in the docs so that it is simpler to see the proper code listing.

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

Successfully merging this pull request may close these issues.

2 participants