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

Update: Continuous progress bar through retries #883

Merged
merged 2 commits into from
Jan 9, 2019

Conversation

ConradJChan
Copy link
Contributor

continuous progress bar

@boxcla
Copy link

boxcla commented Dec 27, 2018

Verified that @ConradJChan has signed the CLA. Thanks for the pull request!

@@ -814,6 +814,11 @@ class Preview extends EventEmitter {
* @return {void}
*/
setupUI() {
// Do nothing if container is already setup and in the middle of retrying
if (this.container && this.retryCount > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

would this.open be helpful here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure, it seems like this.open is set when load is first called and is no guarantee of the preview UI having been setup already

@@ -814,6 +814,11 @@ class Preview extends EventEmitter {
* @return {void}
*/
setupUI() {
// Do nothing if container is already setup and in the middle of retrying
if (this.container && this.retryCount > 0) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This seems like a somewhat risky place for this change, since the this.ui.setup method is intended to destroy/replace the existing UI. Does this cover edge cases where a particular file is being retried and the user navigates to another file?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looking at the code for navigating prev/next files, maybe it would be better to use retryTimeout instead of relying on retryCount since I don't see that getting reset in the navigation flow.

The other approach I was thinking was to pass in a retry boolean to be more explicit when calling load via handleFetchError but I would need to propagate that value through a few functions and result in a bigger change, let me take another look

@@ -814,6 +814,11 @@ class Preview extends EventEmitter {
* @return {void}
*/
setupUI() {
// Do nothing if container is already setup and in the middle of retrying
if (this.container && this.retryCount > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It doesn't look like this.container gets cleared out in the destroy or navigate, so this may cause issues

Copy link
Contributor Author

Choose a reason for hiding this comment

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

created the method PreviewUI.isSetup() instead

this.setupUI();
// Do nothing if container is already setup and in the middle of retrying
if (!(this.ui.isSetup() && this.retryCount > 0)) {
this.setupUI();
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to add this to the reload case? We call it a few times throughout preview.js

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure, IMO the reload intention is to wipe everything clean and start over from scratch in which case, it seems to make sense to always re setup the UI

@ConradJChan ConradJChan merged commit 6782e47 into box:master Jan 9, 2019
@ConradJChan ConradJChan deleted the continuous-progress branch January 9, 2019 00:01
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.

6 participants