I would partially agree that if you know JavaScript enough, using global
isn't a problem per se. Just like using eval shouldn't cause trouble, if
you know what you're doing.
But both are still discouraged for certain reasons. Somewhat simplified
example of namespace mess is the recent Array.prototype.smoosh mess. It's
not a big deal, but since someone "polluted" a built-in Array prototype by
monkey-patching it, now the method name will be "flat" instead of flatten.
Again, not a big deal, just slightly inconsistent with other methods on
that prototype.
Much more chaos was the era before "modern" JavaScript, frameworks and
approaches to client side scripting. I've personally scratched my head on
more than one occasion because of name collisions like that , and I didn't
really did that much JavaScript at the time. No big deal and eventually
I've figured it out. I'm just saying that if it was namespaced, I would
avoid that little bump.
So I'm not saying "never do it, it's bad, you're an idiot if you use
globals and the devil will get you". I'm just saying that _generally_
speaking it's not recommended if there are clear and simple ways that do
not use globals.
Your example shows a good use case and a reasonably unique name for the
`global` property. But if the original poster is even asking such a
question, he might be just a bit inexperienced. And he's going to go bug
fixing some senior devs code. And he is going to name his global`next` and
nobody is going to see it coming when he overwrites some other function's
optional callback and their API starts crashing _sometimes_.
Obviously he should know better and ideally he'd have tests catch this. But
not always and in most cases you really don't need a global so you can do
without having to hunt down for such a bug.
So while I agree with you that it's not always an antipattern, I'd say that
the OK should avoid this if they can. Most likely they have a perfectly
good solution without using global until they learn better and know when
and how to use globals "safely".
It's what I think, at least, don't take my words for a rule.
Post by kai zhuthis discouragement of global/window variables is honestly nonsense that
makes web-project integration/qa work needlessly more complicated and
error-prone than needs be. for example, hereâs a simple frontend
interview-question that can tell you if the applicant can quickly get
integration-level tasks done (using global variables), or tries to
over-engineer something overly complicated and hard-to-integrate instead.
frontend interview-question: how would you implement some simple and
reusable, frontend-code so that pressing ctrl-a / cmd-a inside a <pre>
element will only select-all text inside that element (and not the entire
document)?
correct, simple and reusable frontend-solution using global variable
```html
<script>
// init domOnEventSelectAllWithinPre
(function () {
/*
* this function will limit select-all within <pre tabIndex="0"> elements
* you can copy-paste this reusable code into pretty much any webpage and it will work
*
https://stackoverflow.com/questions/985272/selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
*/
"use strict";
// prevent this code from running more than once, if duplicated in scripts/rollups
if (window.domOnEventSelectAllWithinPre) {
return;
}
window.domOnEventSelectAllWithinPre = function (event) {
var range, selection;
if (event &&
event.code === "KeyA" &&
(event.ctrlKey || event.metaKey) &&
event.target.closest("pre")) {
range = document.createRange();
range.selectNodeContents(event.target.closest("pre"));
selection = window.getSelection();
selection.removeAllRanges();
selection.addRange(range);
event.preventDefault();
}
};
// init event-handling
document.addEventListener("keydown",
window.domOnEventSelectAllWithinPre);
text inside it</label><br>
<pre style="border:1px solid black" tabIndex="0">
hello
world!
</pre>
```
kai zhu
You could use the `global` object (
https://nodejs.org/api/globals.html#globals_global) the same way you use
`window` In the browser. But like in the browser, it's not recommended, in
fact for most use cases it is actually discouraged.
But if you tell us why you need it, perhaps we can find a better pattern for you?
--
Job board: http://jobs.nodejs.org/
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/d/msgid/nodejs/dd471b9c-89ae-4dcb-8909-36035c15a31a%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Job board: http://jobs.nodejs.org/
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to a topic in the
Google Groups "nodejs" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/nodejs/i_ALAnVa5xA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/nodejs/45DD548A-067B-4DB9-B0C0-C2945F472DE0%40gmail.com
<https://groups.google.com/d/msgid/nodejs/45DD548A-067B-4DB9-B0C0-C2945F472DE0%40gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
Zlatko
--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CADu3pbyoGCS8zffmaUmLujWaG5ejqPKbTOanxxRWdO0iYzsBAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.