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.

Sign up for GitHub

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

Jump to bottom

Dismiss suggestions on space keystroke #16601

Merged
merged 3 commits into from
Jun 3, 2021
Merged

Dismiss suggestions on space keystroke #16601

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
831307a
Dismiss suggestions UI on space keystroke
guarani May 31, 2021
2380676
Fixed suggestion dismissal for Gutenberg
guarani Jun 1, 2021
8f511be
Add comment to suggestion space dismiss code
guarani Jun 3, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions WordPress/Classes/ViewRelated/Gutenberg/GutenbergSuggestionsViewController.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -114,6 +114,23 @@ extension GutenbergSuggestionsViewController: UITextFieldDelegate {
return true
}
let searchWord = nsString.replacingCharacters(in: range, with: string)

// This feels a bit hacky, so I'll explain what's being done here:
// 1. If the user types "@ ", the so-called "dismiss sequence",
// the user probably typed the space to dismiss the suggestions UI.
// 2. So when this happens, we call the success handler and
// pass in an empty string.
// We pass in an empty string because on the RN side here, the success
// handler inserts the @, followed by the username, followed by a space.
// Since we're essentially passing in an empty username, the result is
// that a "@ " is inserted into the post, which is the desired result.
// The same applies for cross-posts, with "+ " instead of "@ ".
let dismissSequence = suggestionType.trigger + " "
guard searchWord != dismissSequence else {
onCompletion?(.success(""))
guarani marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

@mchowning mchowning Jun 7, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

👋 @guarani ! If I'm understanding this correctly, passing this as a "success" means that we'll send off analytics indicating that the user successfully selected a suggestion, right? If that's what will happen, that doesn't feel right to me. Seems that we should be treating this as a failure case where the user did not select a suggestion (at least for the purposes of the analytics).

I imagine that the reason you're using the success case is because we get the insertion of the "space" for free when we do that, but maybe there are other reasons I'm not thinking of), whereas if we send a "failure" back to JS, then nothing gets inserted (so the space gets dropped). It feels like we have two options here:

  1. Send back a "success" to javascript (so the space gets inserted), but send a "failure" to the analytics (that's what @SiobhyB has proposed doing on Android); or
  2. Add a way to send text-to-be-inserted (in this case a single space) back to javascript with a "failure".

Option 2 feels cleaner to me, but it may be over-engineering for the single case where we just want to send a space back since we already get that for free with an "empty" success, so I'm sympathetic to just going with Option 1's simpler approach. If we do that though, I think we may need some comments explaining why we're doing this. Curious to hear what you (and @SiobhyB ) think though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for catching this, @mchowning! I completely overlooked the Tracks aspect. I'm going to revert this PR for the time-being while a fix is made.

I think option 1 might work on iOS as well, but will take a look at option 2 as well.

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 created a revert PR here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for looping me into the discussion here @mchowning. :)

If there's a possibility of more cases where certain keystrokes serve to both exit the UI and update the editor (like the one proposed in wordpress-mobile/gutenberg-mobile#2943) then I'd definitely prefer to do this in the cleanest, most scalable way possible.

Are there key differences to how the JavaScript side would handle a "success" vs a "failure" message? I'd made the assumption that entering a space was a success as far as the JavaScript/editor was concerned and am not yet clear what sending a failure would look like.

Copy link
Contributor

@mchowning mchowning Jun 7, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

Are there key differences to how the JavaScript side would handle a "success" vs a "failure" message?

Good question. The only difference that I can imagine at this point is the fact that we want to add a space at the end of a successfully inserted mention, whereas we might not want to do that when a mention was not inserted. For example, if we wanted to have a space exit the mention at any point in the mentions UI (which as Paul points out, we probably do not want to do), then we wouldn't want to add an "extra" space on after the "mention text" which already ends in a space.

This is a bit of a made up example though since we don't actually want this behavior, and this is my concern with Option 2: we don't really know what other use case there might be that would need failure-with-text, so it's hard to know how to best design it.

Not that I'm opposed to Option 2--I bias pretty strongly to finding the cleanest approach most often--but in this case I'm not sure whether it's worth much extra effort: your implementation of Option 1 on Android is quite simple and works perfectly. Doing option 1 on iOS probably won't be as simple though, so I'll be curious to see what Paul thinks after he digs in a bit.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I see, thank you for that extra context!

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 left a comment, wordpress-mobile/gutenberg-mobile#2943. Once that's resolved I think we'll have a better picture of how to handle this.

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 left a comment, wordpress-mobile/gutenberg-mobile#2943. Once that's resolved I think we'll have a better picture of how to handle this.

Now that wordpress-mobile/gutenberg-mobile#2943 (comment) is closed, we don't have another use case for designing a way to pass text back to the React Native world in the suggestions insertion "failure" case. I think Option 1, where we send a success event to React Native and a "failure" to analytics, is a reasonable solution here.

I'll go ahead with this on the iOS side and ping you @SiobhyB once this is ready just to sync up on merging these changes.

Copy link
Contributor

Choose a reason for hiding this comment

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

Perfect, thank you @guarani!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

FIY the iOS PR is up: #16770

return true
}

if searchWord.hasPrefix(suggestionType.trigger) {
suggestionsView.showSuggestions(forWord: searchWord)
} else {
Expand Down