-
Notifications
You must be signed in to change notification settings - Fork 3
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
Refactorings #124
base: feature/eslint
Are you sure you want to change the base?
Refactorings #124
Conversation
const XHR = new XMLHttpRequest() | ||
XHR.open("POST", "") | ||
XHR.setRequestHeader("Content-Type", "application/json") | ||
const xhr = new XMLHttpRequest() |
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.
so i get why you changed this, and that's totally fine, but for some reason most places make XHR capitalized because its an acronym /shrug
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 actually know or have an opinion on which it's supposed to be, but was following @bluepichu's comments on #123
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.
The general convention I've seen (outside the JS API) is that acronyms are single words, and thus get camel-cased as such. So you would have xhr
and createNewXhr
, for example. We could go a different way if you feel strongly.
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.
Looks mostly good, just have a few concerns
window.getSelection().empty ? window.getSelection().empty() : undefined | ||
window.getSelection().removeAllRanges ? window.getSelection().removeAllRanges() : undefined | ||
window.getSelection().addRange(range) | ||
const $copyBuffer = $("#copy-buffer") |
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 like the use of $ to prefix the variable name. What is the rationale? Is it just to indicate that it's a jquery object?
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.
yeah pretty much, and helps avoid colliding names with existing vars
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.
ehhhh, I would rather not have it (perhaps because so many languages use that syntax to denote that something is a variable at all). @bluepichu tiebreaker?
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'd also avoid it unless you feel very strongly.
@@ -1,59 +1,39 @@ | |||
"use strict" | |||
|
|||
const denodeify = require("denodeify") |
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.
Does this work? In the past i haven't been able to use denodeify because it was screwing up the prototypical ownership.
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 idk perhaps not 😅
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.
mmmm you should test it lol
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.
Or would util.promisify
work?
} | ||
})(handle) | ||
} | ||
ApiHandler.routes = Object.freeze({ |
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.
@bluepichu can I get another pair of eyes 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.
I think it's fine, but I'm getting myself confused lol
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 get why we need to freeze but it otherwise looks reasonable
const globals = {} | ||
globals.coll = undefined | ||
globals.path = undefined | ||
|
||
function denodeify(fn, args, alt, th) { |
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.
same question as before
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.
at the very least I can pull them into utils
and probably rename it to avoid confusion
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.
yeah that'd be fine
Regarding combining the font requests: the CSS file is only cached for 1 day, while the font is cached for a year. Combining them in theory reduces cache hits, but the lifetime is so short it probably doesn't matter. |
Interesting, how do you get those numbers? |
From here:
|
I don't think this is how pull requests work
ApiHandler
to classapp.use
api/renderer after static resources