-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Integrate Edit Comment Form JavaScript with editor.js #9067
Conversation
Codecov Report
@@ Coverage Diff @@
## main #9067 +/- ##
=======================================
Coverage ? 82.15%
=======================================
Files ? 100
Lines ? 5936
Branches ? 0
=======================================
Hits ? 4877
Misses ? 1059
Partials ? 0 |
app/views/notes/_comment.html.erb
Outdated
@@ -53,7 +53,7 @@ | |||
<i data-toggle="tooltip" title="This comment was posted by email." class="fa fa-envelope"></i> | |||
<% end %> | |||
<% if current_user && comment.uid == current_user.uid %> | |||
<a aria-label="Edit comment" class="btn btn-outline-secondary btn-sm" id="edit-comment-btn" href="javascript:void(0)" onClick="$('#c<%= comment.cid %>edit').toggle();$('#c<%= comment.cid %>show').toggle();setInit(<%= comment.cid %>);"> | |||
<a aria-label="Edit comment" class="btn btn-outline-secondary btn-sm edit-comment-btn" href="javascript:void(0)" onClick="$('#c<%= comment.cid %>edit').toggle();$('#c<%= comment.cid %>show').toggle();"> |
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.
Small, unrelated change: I changed this to a class instead of an ID.
app/views/comments/_edit.html.erb
Outdated
$E.setState( | ||
'text-input-edit-<%= comment.id%>', | ||
'comment-preview-edit-<%= comment.id %>' | ||
); |
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.
Because editor.js
has a new setState
method, I can call it here instead of the old inline JavaScript.
app/views/comments/_edit.html.erb
Outdated
<span id="c<%= comment.id%>prompt" class="prompt choose-one-prompt-text"> | ||
<span style="padding-right:4px;float:left;" class="hidden-xs"> | ||
<%= raw translation('comments._edit.drag_and_drop') %> | ||
<div id="c<%= comment.id%>div" class="form-group dropzone"> |
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.
Add the class .dropzone
here because this is what editor.js
uses to toggle preview.
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 seems a little odd sounding - isn't dropzone
supposed to mean the area we can drag a file/image into? Coudl this be an artifact from when preview and drag-drop were implemented at the same time, and might we think of a more legible classname or of separating preview and drag-drop?
It kind of makes sense that we remove .dragdrop
when we turn on preview, maybe... so you can't dragdrop onto the preview... but I don't know, shouldn't it just hide the dragdrop and not remove the class? This suggests to me that we should separate the functions and namings to make it more legible and less interdependent, whether or not I'm really understanding what's happening in the current model. What do you think?
Thanks, @noi5e !!!
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.
@jywarren I am totally in agreement that .dropzone
is not really the best class to refer to in this instance. I think the reason this was done in the past has to do with this:
What we're toggling on is B
in the above image. I think in the past, .dropzone
was toggled for preview because it was just a way of referring to "The visible, largest part of the comment form". I acknowledge it's weird, but I was just following the precedent of older code.
For example, it's happening here in this legacy code in editor.js
:
plots2/app/assets/javascripts/editor.js
Lines 141 to 146 in b300979
previewBtn = $(this.textarea.context).find('.preview-btn'); | |
dropzone = $(this.textarea.context).find('.dropzone'); | |
$E.preview[0].innerHTML = marked($E.textarea.val()); | |
$E.preview.toggle(); | |
dropzone.toggle(); |
I think the best thing to do moving forward is to add another CSS ID/class 😢 that has the same coverage as .dropzone
in this instance, and toggle preview on that. Adding it to my planning issue so I don't forget to do 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.
Oh, thanks for the explanation! This makes total sense and is the kind of thing that is hard to plan for in the moment, but is really helpful down the road later. A second class sounds like just the right solution!
app/views/comments/_edit.html.erb
Outdated
if (data.result['filename'].substr(-3,3) == "JPG") is_image = true | ||
if (data.result['filename'].substr(-4,4) == "JPEG") is_image = true | ||
if (data.result['filename'].substr(-3,3) == "PNG") is_image = true | ||
if (data.result['filename'].substr(-3,3) == "GIF") is_image = true |
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 kind of just deleted this code, but can definitely save some of it by either:
- placing it back in the partial, but commenting it out
- saving choice lines and moving it to
editorToolbar.js
(which used to bedragdrop.js
)
Like, here's a similar thing happening in editorToolbar.js
:
plots2/app/assets/javascripts/editorToolbar.js
Lines 103 to 107 in d2e249d
var extension = data.result['filename'].split('.')[data.result['filename'].split('.').length - 1]; var file_url = data.result.url.split('?')[0]; var file_type; | |
if (['gif', 'GIF', 'jpeg', 'JPEG', 'jpg', 'JPG', 'png', 'PNG'].includes(extension)) | |
file_type = 'image' | |
else if (['csv', 'CSV'].includes(extension)) | |
file_type = 'csv' |
Which JS is preferable in this instance?
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.
if (['gif', 'GIF', 'jpeg', 'JPEG', 'jpg', 'JPG', 'png', 'PNG'].includes(extension))
this seems like a MUCH more compact way to do this. And, editorToolbar.js
has the CSV detection too! Nice! Let's just rely on that more refined code! 👍
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 to know! Finished resolving merge conflicts about an hour ago. I restored the code and left it commented out.
app/views/comments/_edit.html.erb
Outdated
if (is_image) { | ||
image_url = data.result.url.split('?')[0]; | ||
orig_image_url = image_url.replace('medium','original'); | ||
$E.wrap('[![',']('+image_url+')]('+orig_image_url+')', {'newline': true, 'fallback': data.result['filename']}); |
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.
For example Jeffrey you were saying in our meeting today that these lines that are resizing the image display to be smaller might be useful to keep.
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.
Looking at editorToolbar.js
i think this already exists there so we're all good!
plots2/app/assets/javascripts/editorToolbar.js
Lines 108 to 112 in d2e249d
switch (file_type) { | |
case 'image': | |
orig_image_url = file_url + '?s=o' // size = original | |
$E.wrap('[![', '](' + file_url + ')](' + orig_image_url + ')', {'newline': true, 'fallback': data.result['filename']}) // on its own line; see /app/assets/js/editor.js | |
break; |
Looks like a system test failure -- comment system tests -- actually really reassuring that these are getting triggered!!!
|
Code Climate has analyzed commit ed09de9 and detected 0 issues on this pull request. View more on Code Climate. |
Yep! My first PR got merged into |
@jywarren Tests passing again, ready to merge! |
* move E.initialize call to higher level views publiclab#9004 * change selectors for preview & textarea elements publiclab#9004 * change #edit-comment-btn to .edit-comment-btn publiclab#9004 * change selectors to match new edit form publiclab#9004 * update selectors for edit form publiclab#9004
* move E.initialize call to higher level views publiclab#9004 * change selectors for preview & textarea elements publiclab#9004 * change #edit-comment-btn to .edit-comment-btn publiclab#9004 * change selectors to match new edit form publiclab#9004 * update selectors for edit form publiclab#9004
* move E.initialize call to higher level views publiclab#9004 * change selectors for preview & textarea elements publiclab#9004 * change #edit-comment-btn to .edit-comment-btn publiclab#9004 * change selectors to match new edit form publiclab#9004 * update selectors for edit form publiclab#9004
* move E.initialize call to higher level views publiclab#9004 * change selectors for preview & textarea elements publiclab#9004 * change #edit-comment-btn to .edit-comment-btn publiclab#9004 * change selectors to match new edit form publiclab#9004 * update selectors for edit form publiclab#9004
Part of an object-oriented refactoring of
editor.js
. See #9004 for more details.Please merge #9062 first!
SUMMARY:
In the past, there were two separate kinds of comment form partials:
/app/views/comments/_form.html.erb
/app/views/comments/_edit.html.erb
To boot, these two different comment form types relied on two separate sources for JavaScript editor functions like image upload, and rich-text editing:
editor.js
.<script>
tag within the partial hereThis made code maintainability more difficult because if a change was made in
editor.js
, it had to account for the<script>
tag.This PR integrates the two JS sources. Now
_edit.html.erb
relies oneditor.js
! Hooray!CHANGES:
_edit.html.erb
so thateditor.js
can access them:#c123preview
is now#comment-preview-edit-123
#c123text
is now#text-input-edit-123
<script>
tag in_edit.html.erb
so now it relies oneditor.js
instead.Slightly unrelated changes:
setInit
function definition and calls in_edit.html.erb
.setInit
was kind of like a way that we used to setState in EDIT comment forms before. The problem is that we called it whenever the user opened up an edit comment form, or clicked on Preview, which I don't think is a good place to setState. See this comment for an explanation..dropzone
class to#c123div
, mainly soeditor.js
can toggle preview (Yes, we toggle on.dropzone
when the user clicks on "Preview")$E.initialize()
call from_form.html.erb
(REPLY and MAIN comment form partial) into higher level partials. This is so thateditor.js
isn't initialized 5 times on a page with 5 comments (this was happening before! 😱)(This issue is part of the larger Comment Editor Overhaul Project with Outreachy. Refer to Planning Issue #9069 for more context)