-
Notifications
You must be signed in to change notification settings - Fork 754
Remove need for global workaround and make Browserify happy #84
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
Conversation
…that: * components making use of `window` can actually do it without the trick found in the `components.js` file of the dummy test app * components/files packaged as CommonJS modules by browserify (using browserify-rails for instance) can successfully use `global` For this second point, this fix is necessary because of the self-calling function browserify uses to wrap code that uses the `global` variable: ```ruby (function (global){ global.MyComponent = React.createClass({ ... }); }).call(this,typeof self !== "undefined" ? self : typeof window !== "undefined" ? window : {}) ``` If `window` was used instead of `global`, it would still need the fix or the workaround found in the tests' dummy app as mentioned.
I'd be convinced with that manual testing you mentioned. |
@@ -22,7 +22,7 @@ def self.render(component, args={}) | |||
|
|||
def self.setup_combined_js | |||
<<-CODE | |||
var global = global || this; | |||
var global = global || this, self = self || this, window = window || 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.
Nit, let's do each of these on their own lines with their own var
. That's more in line with our other styles (and matches both mine and FB's preferred style).
Thanks for all the comments @zpao (and for your help on IRC ^^), I'll correct and push again shortly. |
There you go @zpao :) |
Remove need for global workaround and make Browserify happy
Thanks! |
Can I register a dissenting opinion after-the-fact? There's a lot of code out there using:
To make sure that code that can't work server-side will only run client-side. |
@zpao, has @jwietelmann's objection been taken into account? |
Define
self
andwindow
global objects in the combined JS code so that:components in Coffee files can really use
window
instead of usingglobal
to become accessible, thus removing the need for thevar self, window, global = global || window || self;
trick incomponents.js
to have the code work both on server & clientscomponents/files packaged as CommonJS modules by browserify (using browserify-rails for instance) can successfully use
global
if they want toFor this second point, this fix is necessary because of the self-calling function browserify uses to wrap code that accesses the
global
variable:If
window
was used instead ofglobal
, it would still need the fix when compiling on the server, aswindow
would not be defined otherwise.I have not included tests, as I am not sure how to test this...
Maybe what could serve for testing would just be to remove the
var self, window, global = global || window || self;
line fromcomponents.js
in the dummy app, changeglobal.Todo = Todo
towindow.Todo = Todo
inapp/assets/javascripts/components/Todo.js.jsx.coffee
and be satisfied that tests are still successful?Open to suggestions to complete the PR :)