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

Add data communicator API for disabling data provider interactions #9070

Merged
merged 4 commits into from Sep 30, 2020

Conversation

mshabarov
Copy link
Contributor

No description provided.

@mshabarov mshabarov added this to Iteration Reviews in OLD Vaadin Flow ongoing work (Vaadin 10+) via automation Sep 28, 2020
Copy link
Contributor

@pleku pleku left a comment

Choose a reason for hiding this comment

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

I think the implementation is done in a way that it will leak to the users (when using e.g. data view API) and causes errors that can confuse them. It should be basically about the component to be able to "delay" the first fetch to a certain point, but not cause errors for users.

countCallback = null;
skipCountIncreaseUntilReset = false;
this.countCallback = null;
this.skipCountIncreaseUntilReset = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Unrelated unnecessary changes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted

@@ -496,7 +537,7 @@ public void setItemCountEstimateIncrease(int itemCountEstimateIncrease) {
}
this.itemCountEstimateIncrease = itemCountEstimateIncrease;
this.countCallback = null;
definedSize = false;
this.definedSize = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Unrelated unnecessary change (yes the this. for countCallback is unnecessary too)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted

} else if (index >= itemCount) {
throw new IndexOutOfBoundsException(String.format(
"Given index %d is outside of the accepted range '0 - %d'",
index, itemCount - 1));
}
}

if (fetchDisabled) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why should this be blocked ??? Since this API is not directly exposed to users, like it should not, it feels weird to me that for some components I can do

Component listing = createListing();
listing.setItems(query -> getStuff(query));
listing.getItem(0);

but not for all. So for Grid this would work and not for combobox (I guess) ??? That is confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Excluded

* @return the size of data provider with current filter
*/
@SuppressWarnings({ "unchecked", "rawtypes" })
protected int getDataProviderSize() {
if (fetchDisabled) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Again, it would be weird for a data view API user that the same things work for another component, but not for another.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Excluded

@mshabarov mshabarov force-pushed the data-communicator-fetch-disable branch from 6a021a0 to ec18d31 Compare September 29, 2020 13:28
@mshabarov
Copy link
Contributor Author

I think the implementation is done in a way that it will leak to the users (when using e.g. data view API) and causes errors that can confuse them. It should be basically about the component to be able to "delay" the first fetch to a certain point, but not cause errors for users.

I was thinking whether it's better to use the data communicator as a listener for 'switch to normal mode', but I think it is a over-complication and basically limited to 1 component so far, so I simply left it as it is (CTOR arg + getter and setter). Curious users could of course try them randomly, but I have no elegant protection for that.

Copy link
Contributor

@pleku pleku left a comment

Choose a reason for hiding this comment

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

It seems to me this PR has more unnecessary white space changes than the actual changes. I will not review it as such as it wastes my time

@pleku
Copy link
Contributor

pleku commented Sep 29, 2020

https://www.jetbrains.com/help/idea/reformat-file-dialog.html

Item Description
Only VCS changed text If this checkbox is selected, then reformatting will apply only to the files that have been changed locally, but not yet checked in to the repository.This checkbox is only available for the files under version control.

@vaadin-bot
Copy link
Collaborator

SonarQube analysis reported 2 issues

Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

  1. MAJOR DataCommunicator.java#L938: Refactor this method to reduce its Cognitive Complexity from 16 to the 15 allowed. rule
  2. INFO DataCommunicator.java#L354: Complete the task associated to this TODO comment. rule

@pleku pleku merged commit c4ffe6c into master Sep 30, 2020
OLD Vaadin Flow ongoing work (Vaadin 10+) automation moved this from Iteration Reviews to Done - pending release Sep 30, 2020
@pleku pleku deleted the data-communicator-fetch-disable branch September 30, 2020 07:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
OLD Vaadin Flow ongoing work (Vaadin ...
  
Done - pending release
Development

Successfully merging this pull request may close these issues.

None yet

3 participants