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

FolderExplorer: "new folder" issues #743

Closed
nbelyh opened this issue Nov 26, 2020 · 4 comments
Closed

FolderExplorer: "new folder" issues #743

nbelyh opened this issue Nov 26, 2020 · 4 comments
Labels
status:fixed-next-drop Issue will be fixed in upcoming release. type:bug
Milestone

Comments

@nbelyh
Copy link
Contributor

nbelyh commented Nov 26, 2020

Category

[ ] Enhancement

[x] Bug

[ ] Question

Version

Please specify what version of the library you are using: [2.1.0]

Description

  1. New folder name is unnecessarily encoded. If you enter 'A B' as a folder name, you get 'A%20B'. Space is a valid character for a folder name, according to the documentation:
    https://support.microsoft.com/en-us/office/invalid-file-names-and-file-types-in-onedrive-and-sharepoint-64883a5d-228e-48f5-b3d2-eb39e07630fa

  2. there is no check for invalid symbols. If you create a new folder in SharePoint UI you have an error message like this:
    image

  3. There is no way to cancel creation of the folder once you started it (no cancel button and escape does not work)

  4. There is no error shown in case folder is not created (just a log entry in console). If error happens, the control gets "stuck" in the "saving" mode here, "loading" is never reset:

Expected

  1. You get 'A B'.
  2. There is validation error like in the SharePoint implementation.
  3. Cancel key should cancel editing, or there should be a cancel button, or both.
  4. In case of error, the field should stop "saving", and should show something like "something went wrong" to indicate that folder creation fails.

Possible solutions

  1. There is "blunt" encoding here (should be smarter than this; it's not all "invalid URI characters" that are prohibited). More precisely, encodeURIComponent(name) seems to be a bad idea. If (2) is fixed then this encoding can be probably be just removed (in case something is wrong, the API call will throw an exception):

    let folderAddResult: IFolderAddResult = await web.getFolderByServerRelativePath(encodeURIComponent(folderRelativeUrl)).folders.addUsingPath(encodeURIComponent(name));

  2. Here a validation (errorMessage) property is probably needed, that will check proper characters. Since spfx controls don't care about 2013, the latest invalid character set can be taken, see here. And translation of that to all supported languages:

    <TextField
    placeholder={strings.NewFolderNamePlaceholder}
    value={this.state.folderName}
    onChanged={this._onFolderNameChange}
    // styles={{ fieldGroup: { width: 300 } }}
    />

  3. Not quite sure how to deal with this one.. Maybe using a focus (lock) somehow? Now the thing is the focus can can close the whole dialog/sidebar where the control is located, instead of just cancelling folder creation.

  4. I think at least the state "loading" should be reset here on exception. Ideally, there should an error message (localized) like "failed to add folder" or something that is set as errorMessage for the <TextField>

@ghost
Copy link

ghost commented Nov 26, 2020

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

@ghost ghost added the Needs: Triage 🔍 label Nov 26, 2020
AJIXuMuK added a commit that referenced this issue Nov 28, 2020
Fixes for #743: no encoding, special characters, displaying error
@AJIXuMuK
Copy link
Collaborator

Hi @nbelyh,

I've fixed 1, 2, and 4. Please, check beta version.

For the 3 - I don't see a value of doing that as the folder is created almost instantly. Even in OOB UI when you press ESC - the dialog is closed, but the folder is still being created.

I would consider adding some events like folderCreating with ability to cancel, but not Cancel button or ESC handle.

@AJIXuMuK AJIXuMuK added status:fixed-next-drop Issue will be fixed in upcoming release. type:bug and removed Needs: Triage 🔍 labels Nov 28, 2020
@AJIXuMuK AJIXuMuK added this to the 2.2.0 milestone Nov 28, 2020
@nbelyh
Copy link
Contributor Author

nbelyh commented Nov 28, 2020

@AJIXuMuK This is awesome! 😄 The third item can be thought of later, it's not critical at all, can be left as is I guess! The space character was the only critical issue here for me.

@nbelyh
Copy link
Contributor Author

nbelyh commented Nov 29, 2020

Seems to work great 👍

@nbelyh nbelyh closed this as completed Nov 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:fixed-next-drop Issue will be fixed in upcoming release. type:bug
Projects
None yet
Development

No branches or pull requests

2 participants