Skip to content

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

Merged
merged 3 commits into from
Sep 15, 2014

Conversation

olance
Copy link
Contributor

@olance olance commented Aug 30, 2014

Define self and window global objects in the combined JS code so that:

  • components in Coffee files can really use window instead of using global to become accessible, thus removing the need for the var self, window, global = global || window || self; trick in components.js to have the code work both on server & clients

  • components/files packaged as CommonJS modules by browserify (using browserify-rails for instance) can successfully use global if they want to

    For this second point, this fix is necessary because of the self-calling function browserify uses to wrap code that accesses the global variable:

    (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 when compiling on the server, as window 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 from components.js in the dummy app, change global.Todo = Todo to window.Todo = Todo in app/assets/javascripts/components/Todo.js.jsx.coffee and be satisfied that tests are still successful?

Open to suggestions to complete the PR :)

…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.
@zpao
Copy link
Member

zpao commented Sep 7, 2014

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;
Copy link
Member

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).

@olance
Copy link
Contributor Author

olance commented Sep 8, 2014

Thanks for all the comments @zpao (and for your help on IRC ^^), I'll correct and push again shortly.

@olance
Copy link
Contributor Author

olance commented Sep 15, 2014

There you go @zpao :)

zpao added a commit that referenced this pull request Sep 15, 2014
Remove need for global workaround and make Browserify happy
@zpao zpao merged commit 81d423e into reactjs:master Sep 15, 2014
@zpao
Copy link
Member

zpao commented Sep 15, 2014

Thanks!

@jwietelmann
Copy link

Can I register a dissenting opinion after-the-fact? There's a lot of code out there using:

if(typeof(window) !== 'undefined')

To make sure that code that can't work server-side will only run client-side.

@olance
Copy link
Contributor Author

olance commented Jan 3, 2015

@zpao, has @jwietelmann's objection been taken into account?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants