1

I've seen things like this in many projects. Server generates html page with <script> tag, and JS code in it, which defines some "constants", using templates.

For example.

<script>
  window.CONSTANTS = {};
  window.CONSTANTS.USER_ID = "<?= getUserId() ?>";
  window.CONSTANTS.BASE_PATH = "<?= getBasePath() ?>";
</script>

The other way I can think of, would be letting client to make an ajax call, to get all the necessary data.

user3445165
  • 45
  • 1
  • 6
  • It is personal opinion, but a better solution is one global object that holds everything instead of flooding the global namespace with all those variables. – epascarello Jul 27 '15 at 17:42
  • _JSON_ serialised objects can be read as _Object literals_ in _JavaScript_, meaning you can define a single variable in a similar way to what you have here but with less pollution, or use a _JSONP_ style, where you invoke some method with the object – Paul S. Jul 27 '15 at 17:43
  • Sure, constants can be stored in some object to avoid flooding global namespace. The question is, choosing the best way to transmit that constants to the client. – user3445165 Jul 27 '15 at 17:48
  • For the record these are not constants, because they can be overwritten at any time, and would potentially overwrite any other code that uses those names. – dudewad Jul 27 '15 at 17:52
  • Updated question to make it clear, the question is not about assigning variables to global namespace. Sorry I didn't make it clear from the very beginning. – user3445165 Jul 27 '15 at 18:04
  • You want to know, then, if having "generated" rather than "statically written" or hard-coded constants is a bad thing? I think a lot of technologies would benefit from constants that are kept in sync. – dudewad Jul 27 '15 at 20:15

2 Answers2

2

Assigning variables to the global namespace (in the case of the browser, "window.[somevariable]") is considered dangerous/evil/whatever.

You should always, as a matter of what they call "good practice", namespace your stuff. Lets say your application is called Jumpr (to give it a trendy hipster name), you might consider namespacing variables and modules that belong to your app under the global variable "Jumpr".

In the case of constants, I personally like assigning constants to an app.CONSTANTS namespace:

Jumpr.CONSTANTS

As far as dynamically outputting constants from the server, which is not a bad thing in my opinion (keeps your server constants that are shared with your application constants in sync), you could opt to import them via a constants script file, which then imports into your namespace like so:

Constants.js (this file could be auto-generated at request-time):

var Jumpr = Jumpr || {};

Jumpr.CONSTANTS = {
    SOMECONST: "Some Constant Value 0"
    SOMECONST1: "Some Constant Value 1"
}

...etc. But this is just one way of doing it. If you're unfamiliar with this pattern, what it's doing is checking for an already defined Jumpr module. If it's not defined, it makes a new object. Otherwise, it uses the existing one and "extends" it using the defined constants.

Also note these aren't true constants. To achieve the illusion of constants in JS you would need to create a get/set closure that would then act as a read-only retriever, but I'm not going to go into that here.

Edit Since the context of the question has changed, I'm going to update my answer:

In my view, no, its not bad to have dynamically generated constants. Those constants, I would assume, are being generated from your back-end constants. You might want these environments to be in sync (you could capture everything from server routes, to form names, to whatever else in there). I personally think that this could be a good thing.

I would like to caveat that with the idea that you'll be taking a performance hit for doing that. I would rather recommend that you reference a constants file/module, which is then updated every time your constants on the server side change. It'll reduce computing power required to generate your pages and is worth the effort since it's generally easy to set this up, and constants rarely change (key word: they're constant) :)

Note, that's exactly what I already recommended above.

dudewad
  • 13,215
  • 6
  • 37
  • 46
-2

It is a bad practice. Global variables and functions can be overwritten by other scripts. Here there is a good example.

Community
  • 1
  • 1
Vismari
  • 745
  • 3
  • 12