-
Notifications
You must be signed in to change notification settings - Fork 68
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
Improve undo/redo for Title component #1197
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## master #1197 +/- ##
==========================================
+ Coverage 54.63% 54.66% +0.02%
==========================================
Files 101 102 +1
Lines 2888 2938 +50
Branches 535 548 +13
==========================================
+ Hits 1578 1606 +28
- Misses 967 975 +8
- Partials 343 357 +14
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Let's wait for others to review this.
@chia-yh thanks for taking up this issue. Now that we have the fix in view, we can consider if the additional code is worth the payback. Seems like it requires a lot of code changes, including a lot of new code. Is it worth the benefit? What do you all think? If the answer is not a confident 'yes', we can close this PR without merging, but still give @chia-yh credit for the work done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall a nice PR that uses the new undoredo model! I think it is okay to merge this after resolving my comments
private undo(): void { | ||
const entry = this.history.undo(); | ||
if (entry === null) { | ||
return; | ||
} | ||
this.titleField.setValue(entry.text); | ||
this.titleInput.nativeElement.setSelectionRange(entry.selectStart, entry.selectEnd); | ||
} | ||
|
||
private redo(): void { | ||
const entry = this.history.redo(); | ||
if (entry === null) { | ||
return; | ||
} | ||
this.titleInput.nativeElement.value = entry.text; | ||
this.titleInput.nativeElement.setSelectionRange(entry.selectStart, entry.selectEnd); | ||
} | ||
|
||
private isUndo(event: KeyboardEvent) { | ||
// prevents undo from firing when ctrl shift z is pressed | ||
if (navigator.platform.indexOf('Mac') === 0) { | ||
return event.metaKey && event.code === 'KeyZ' && !event.shiftKey; | ||
} | ||
return event.ctrlKey && event.code === 'KeyZ' && !event.shiftKey; | ||
} | ||
|
||
private isRedo(event: KeyboardEvent) { | ||
if (navigator.platform.indexOf('Mac') === 0) { | ||
return event.metaKey && event.shiftKey && event.code === 'KeyZ'; | ||
} | ||
return (event.ctrlKey && event.shiftKey && event.code === 'KeyZ') || (event.ctrlKey && event.code === 'KeyY'); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this code is repeated from comment-editor.component.ts
. Perhaps these functions can be in undoredo.model.ts
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion, I think isUndo
and isRedo
can definitely be moved into undoredo.model.ts
, perhaps as a static method. However, I'm not sure if the same should be done for the undo
and redo
methods, as I personally feel that the handling of values from UndoRedo::undo
/UndoRedo::redo
should be done in the components using the UndoRedo
model, in the interests of keeping UndoRedo
more general. Could I perhaps ask for your thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving the undo and redo methods as it is is okay too
@chunweii Is the extra code worth the benefit (as I mentioned in #1197 (comment)) ? |
Just something I noticed while writing the additional tests in The affected tests I've found are:
Changing the Following the same format in
As this PR may be closed without being merged as the additional code may not be worth the payback, and this issue seems to be a separate concern from the issue this PR is addressing, should I create a separate issue regarding this, and fix it in a separate PR? |
Thank you for discovering this bug in our tests! You should create a separate issue and fix it in a separate PR, even if this PR is accepted |
I think the extra code looks good to merge, but the benefit is small because there are no issues with using the default browser undo/redo for the title component. What do other developers think? @CATcher-org/2223s2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the undo-redo feature will be used often for Title component in PE. It is simply easier to backspace and only applicable to Bug Reporting Phase. I also can't tell there is a change in behaviour.
Seems like it requires a lot of code changes, including a lot of new code. Is it worth the benefit? What do you all think?
I think we can merge the part of refactoring UndoRedo model. The comment-editor has too many functions, it will be good to refactor out the parts related to UndoRedo to its respective class.
public static isUndo(event: KeyboardEvent) { | ||
// prevents undo from firing when ctrl shift z is pressed | ||
if (navigator.platform.indexOf('Mac') === 0) { | ||
return event.metaKey && event.code === 'KeyZ' && !event.shiftKey; | ||
} | ||
return event.ctrlKey && event.code === 'KeyZ' && !event.shiftKey; | ||
} | ||
|
||
public static isRedo(event: KeyboardEvent) { | ||
if (navigator.platform.indexOf('Mac') === 0) { | ||
return event.metaKey && event.shiftKey && event.code === 'KeyZ'; | ||
} | ||
return (event.ctrlKey && event.shiftKey && event.code === 'KeyZ') || (event.ctrlKey && event.code === 'KeyY'); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This refactoring is good to have
I agree that the behavioral change isn't significant enough to warrant the extra code, especially since most users are unlikely to notice it. Should I go ahead and open a new PR that refactors the UndoRedo model as mentioned? So that this PR can be closed without merging? |
I've opened a new PR (#1205) as mentioned in a previous comment, so this PR can be closed without merging. |
Summary:
Fixes #1176
Changes Made:
title-editor.component
, which uses theUndoRedo
model to handle the undo / redo logic for the Title component in the same manner ascomment-editor.component
handles undo / redo logic in the description, but without support for image uploads andctrl+i
,ctrl+b
new-issue.component
,title.component
to useTitleEditorComponent
title-editor.component.spec.ts
for testingTitleEditorComponent
Proposed Commit Message: