-
Notifications
You must be signed in to change notification settings - Fork 126
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
Disallow duplicate thoughts #786
Disallow duplicate thoughts #786
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.
Thanks Fedor! It's working well for me. I'd like to loop in Bijay to ask if there's any way to avoid the direct DOM manipulation.
@shresthabijay I'd like your opinion since your familiar with this part of the code. Is there a better way to change the opacity of the Editable when a duplicate value is detected? I'm hesitant to use direct DOM manipulation. Is there a more idiomatic way to do this in React? Thanks! |
6d24338
to
4103e9d
Compare
I don't think there is any better solution to this. The problem is that we are restricted to not re-render |
@shresthabijay You're right, but that seems unavoidable. We can't re-render an Editable while the user is editing it, otherwise it would mess up their focus. If only a style or className is changed, does that still re-render an element? |
I think in our case we need to change appearance of element, which could be done by direct dom manipulation or via render function. If we use idiomatic "React" way, all changing in appearance happen after execution of render function, which one we can't use. Correct me please, if i'm wrong somewhere, |
Yes, Bijay helped clarify that we should be able to use the render function without interfering with editing, but due to the current architecture it forces the DOM element to get re-rendered for some reason. That will need to get addressed in a separate issue. For now, then, we can use direct DOM manipulation. The whole file deserves some refactoring in the future anyway. |
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.
There is a strange edge case that we need to address:
- a
- ba
- bac|
Hit Backspace
with the caret at the end of bac
and then hit Enter
. This will create a duplicate ba
in the same context. The cause is that Enter
incorrectly triggers splitThought
because focusOffset is 2
and value.length
is 3
since it has not been modified.
Try it yourself and give some thought to a proposed solution. How should we handle splitThought
when the Editable is in a temporary duplicate state? Are there any other actions that depend on the caret position that may be affected as well?
I think that we need to handle this situation in
I suggest to use What do you think? |
First of all, thank you for the clear explanation and proposal. That's exactly what I'm looking for. I agree that this should happen in
Yes, that's correct.
It is incorrect to assume that the edit must come at the end of the thought. e.g. This would not the case of deleting the
We shouldn't have to explicitly check for duplicates. It should only be a matter of the browser selection position.
I think there is an easier solution. According to
This is important, too. You may have to search for the use of |
As i understand, hitting 'Enter' on duplicate Thought should reset its value to the last not duplicate and trigger |
Yes, although it should be noted that the "reset" is DOM-only; the state value was never actually changed.
I still don't think it's the duplicate that matters here. That is a contingency. The general situation is that when the How about we each implement our preferred solution, and then compare the results? |
I think it would be fun, let's try it :) |
Okay, my solution is in ee1f252 ;) |
Looks like your won :) |
Yours is quite clean! But yes, I think the generality and lack of additional DOM manipulation is preferred. |
Just realized that merge-on-delete (inverse of split) can be used to create a duplicate: Steps to Reproduce
With the caret at the beginning (offset: 0) of Current Behavior
Expected BehaviorMaybe prevent the action completely and show an appropriate alert? What do you think? |
Yes, i think we can handle this case in |
Yes, let's do that. |
a6a0adb
to
e659e64
Compare
There is a small regression: Steps to Reproduce
Try to delete the empty thought. Current Behavior
Expected BehaviorEmpty thought should be deleted. |
e659e64
to
012dd73
Compare
Fixed, thanks! |
|
Superscript regression: Steps to Reproduce
Edit Current BehaviorSuperscript position is not updated. Expected BehaviorSuperscript should be positioned correctly at the end of the thought text. |
d9feddb
to
26a361c
Compare
…uplicateOnSplit check
…en thought is duplicate
… wrong render of new thought after editing and blur
14219ea
to
a2461cc
Compare
a2461cc
to
4ee8c6a
Compare
if (clearTimeout) { | ||
// if clearAlertTimeoutId !== null, it means that previous alert hasn't been cleared yet. In this case cancel previous timeout and start new. | ||
clearAlertTimeoutId && window.clearTimeout(clearAlertTimeoutId) | ||
clearAlertTimeoutId = window.setTimeout(() => { | ||
dispatch({ | ||
type: 'alert', | ||
alertType, | ||
showCloseLink, | ||
value: null, | ||
}) | ||
clearAlertTimeoutId = null | ||
}, clearTimeout) | ||
} |
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.
Great!
Fixes #764