Skip to content

Conversation

@benjiwheeler
Copy link
Contributor

@benjiwheeler benjiwheeler commented May 10, 2019

Resolves

Big step towards resolving #4762
Resolves #3365

Proposed Changes

  • move sb-file-uploader to a top-level HOC that wraps gui
  • in situation where user has selected to upload project, but file content is not ready/available, dispatch project-state action RETURN_TO_SHOWING

Reason for Changes

  1. we made design decision to use custom confirm modal, to have greater confidence in and control of the user experience when the user is at risk of overwriting their work. But this is not doable yet because clicking on the modal is interpreted as a click outside the open file menu, which closes the file menu. This is a problem because...
  2. previously, the sb-file-uploader would be unmounted any time the file menu closed; its existence/mounting should not depend on a menu.
  3. in testing, when i would clear the contents of the file to upload before it could be loaded into the vm, sb-file-uploader-hoc would correctly avoid loading the empty content; but it would be stuck in the LOADING_VM_FILE_UPLOAD state. Submitting RETURN_TO_SHOWING in this case makes sure we will stay in the right state in that case. (We shouldn't actually be missing the contents of the file to upload in practice, but just in case!)

Test Coverage

Added a test and moved over tests to new HOC, but ideally we would test even more.

@benjiwheeler benjiwheeler self-assigned this May 10, 2019
@benjiwheeler benjiwheeler added this to the May 2019 milestone May 10, 2019
@benjiwheeler benjiwheeler force-pushed the refactor-file-uploader branch 2 times, most recently from 1b34449 to 4820132 Compare May 10, 2019 20:01
@benjiwheeler benjiwheeler changed the title Custom SB* file upload confirm modal; refactor file uploader into top-level HOC refactor SB* file uploader into top-level HOC May 14, 2019
@benjiwheeler benjiwheeler force-pushed the refactor-file-uploader branch from 2ce692c to 28a120a Compare May 14, 2019 19:51
@benjiwheeler benjiwheeler requested a review from paulkaplan May 14, 2019 19:52
};
case LoadingState.LOADING_VM_NEW_DEFAULT:
return {
type: START_ERROR
Copy link
Contributor Author

Choose a reason for hiding this comment

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

If loading fails (success === false), recover by going back to just showing project as-is. But if we were loading the default project, a failure in loading probably indicates a serious error.

});

test('if canSave is alreatdy true and we show a project with an id, project will NOT be saved', () => {
test('if canSave is already true and we show a project with an id, project will NOT be saved', () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed a typo

@@ -0,0 +1,241 @@
import bindAll from 'lodash.bindall';
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 tried to keep as much as possible in this file the same as before. There are very few differences, aside from what was necessary to refactor it into a top-level HOC wrapping GUI.

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 tried to keep as much as possible in this file the same as before. There are very few differences, aside from what was necessary to refactor it into a top-level HOC wrapping GUI.

Now there are more differences -- as part of making the component dynamic, I reordered functions and added comments.

@benjiwheeler
Copy link
Contributor Author

Ready for review; just blocking until after this week's deploy.

@benjiwheeler
Copy link
Contributor Author

@paulkaplan and I talked about this. Some takeaways:

Concerns:

  • Z is currently working to start loading project before gui fully renders. Adding a top level HOC, with an additionally rendered input component, can slow this down.
  • need to assess/measure/understand how much this increases the overall performance burden on gui.

Possible alternative approaches:

  • in containers/menu.jsx, mouseup events cause the menu to be closed. This is the original problem leading to this PR's refactor. What if instead, we just checked if the mouse target was a modal, and didn't close the menu then?

Next step:

  • pick this back up when we have more time to discuss. Possibly with @rschamp .

Labeling as blocked, per need for discussion.

@benjiwheeler benjiwheeler modified the milestones: May 2019, Backlog May 21, 2019
onStartSelectingFileUpload={this.handleStartSelectingFileUpload}
{...componentProps}
/>
{fileInput}
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's try to create this element dynamically in the handler, rather than mounting it here, to avoid issues with components unmounting.

@benjiwheeler
Copy link
Contributor Author

benjiwheeler commented Jun 6, 2019

Discussed with @rschamp and @paulkaplan. Current plan:

  1. The menu click issue that prompted this should be fixed in and of itself
  2. I should pull out my project state tests and state fix, and introduce those separately (done in reset title on transitioning to isShowingWithoutId #5291 )
  3. The custom modal for project upload can then be introduced
  4. Redo this PR as only a refactor, which doesn't change behavior at all
    • change placement of the file picker to be a createelement that’s not even on the dom, per Ray's comment: "Let's try to create this element dynamically in the handler, rather than mounting it here, to avoid issues with components unmounting."

@benjiwheeler benjiwheeler modified the milestones: Backlog, January 2020 Jan 16, 2020
draft of refactor to make custom confirm modal work for upload; need to further edit sb-file-uploader

Add support for custom confirm modal to sb-file-uploader

Show custom confirm modal when confirming project upload

got custom upload refactor of file upload working, and tested failure case

cleaned up debug code, make project file upload work

simplified logic around canceling file upload

removed old sb-file-uploader.jsx; fixed linter errors

reverted two components to use old strings, not shared

(can do that refactor another time)

removed unnecessary confirm container

removed stray comment

moved, updated sb file uploader tests, related project state tests

removed custom modal, to reduce scope of changes

sb file uploader test uses intl
@benjiwheeler
Copy link
Contributor Author

benjiwheeler commented Jan 30, 2020

This PR is ready for review, but tests aren't passing; it's difficult to diagnose because the same tests pass locally.

Update: tests are fixed.

@benjiwheeler
Copy link
Contributor Author

OK @rschamp, take a look at the dynamic way sb-file-uploader-hoc is now creating the element.

rschamp
rschamp previously approved these changes Feb 4, 2020
Copy link
Contributor

@rschamp rschamp left a comment

Choose a reason for hiding this comment

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

Looks good to me. I found a couple of comments that seemed superfluous.

Also on comments, I personally find the "step #" style comments distracting because they imply a "correct" route for reading the code, so if you encounter a step number out of context you have to read it from beginning to end to understand what it's talking about. To convey the same type of information, I think I'd rather see a flow diagram showing the relationship between the functions at the top. Just my 2¢, not asking you to change it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Can't upload scratch project by double clicking the file

3 participants