Javascript host environment documentation

[aackerman]

What I was lost on earliest attempting to get started with react-native was understanding the host environment. It's not Node, it's not a browser, it appears to be a raw VM context, with a whole bunch of polyfills. When I tried to require Bluebird, I ran into errors, likely due to assumptions made about APIs provided by the host environment.

Also, it would be important to know how third-party libs can run tests in the same type of environment to fix these issues.

Thanks.

[jaygarcia]

I agree that there could be some better documentation around this. For example, the "light" implementation of the CommonJS module system, should be documented, if it's not already.

(stuff is moving so quickly, it's hard for me to keep track of it all)

[daviskoh]

+1

[sahrens]

We always need more docs!

For testing in the full environment, check out the "Testing" section of the documentation - we have a harness for integration testing that should help you do what you want.

On Mar 27, 2015, at 7:38 AM, Davis Koh @daviskoh notifications@github.com wrote:

+1

—
Reply to this email directly or view it on GitHub.

[amasad]

@aackerman can you list the issues you ran into by trying to use Bluebird? Maybe we can fix those quickly.

[aackerman]

I can give more detailed info about the issue with bluebird later tonight, but in the mean time, having installed bluebird with npm install bluebird and var Promise = require('bluebird'); in index.ios.js will throw and error.

[vjeux]

Can you give the exact error?

Also note that there's a Promise global already existing in React Native

[aackerman]

It looks like a clear issue with bluebird from what I can tell.

The block in bluebird looks like this.

} else if (typeof MutationObserver !== "undefined") {
    schedule = function(fn) {
        var div = document.createElement("div");
        var observer = new MutationObserver(fn);
        observer.observe(div, {attributes: true});
        return function() { div.classList.toggle("foo"); };
    };
    schedule.isStatic = true;
} else if (typeof setTimeout !== "undefined") {

It's clearly throwing an error because the DOM is not available, but it's interesting that MutationObserver is available, otherwise it could not have made it into the block. The authors of bluebird probably didn't expect to be running in an environment that is neither node nor the browser.

@vjeux as you said a Promise implementation does exist already, and what I really wanted just simply fetch, so the bluebird issue is completely secondary to understanding the host environment.

I'll make a ticket on the bluebird repo to let them know about this particular issue, but at this point I don't think it needs to be a priority for anybody.

[vjeux]

Yeah, all those feature detection needs to be carefully considered when running in a different environment. The implementation of Promise that we have is using setImmediate that has been implemented to run before we hand back the process to obj-c

[vjeux]

By the way, fetch is there by default. It has a much nicer api than xhr :)

[petkaantonov]

MutationObserver is supposed to observe DOM elements, it doesn't make sense to expose one without the other. Also, there is not a single mention of MutationObserver in this entire repo so I am not sure how I would even fix it - what am I supposed to observe with it?

[vjeux]

This is where we mangle with the global environment. We should probably do delete GLOBAL.MutationObserver; (if we can).
https://github.com/facebook/react-native/blob/master/Libraries/JavaScriptAppEngine/Initialization/InitializeJavaScriptAppEngine.js#L117

One issue if we do this is that it's now going to use setTimeout(0), which is going to do a round trip to native for every single call. Since when you are using promises, you tend to chain a lot of then, it's going to be much slower than needed. It really needs to use setImmediate.

[petkaantonov]

I can add setImmediate check after the MutationObserver check, np :)

[vjeux]

Okay perfect. I'm trying to remove MutationObserver right now, I'll report back in 2 minutes

[vjeux]

Bingo, it's working, it now falls through the setTimeout check. I'm sending an internal diff, it'll be updated in the next version.

[petkaantonov]

setImmediate check published in 2.9.16

[vjeux]

That was fast ;)

[petkaantonov]

yea the upside of lone cowboy projects :p

[vjeux]

Since I got you, I'd like to get your opinion on
https://github.com/facebook/react-native/blob/master/Libraries/vendor/core/ES6Promise.js

This is the promise implementation that we're providing. Do you think it makes sense to use bluebird by default?

[petkaantonov]

Well I don't personally find the pure ES6 api enough for application development, I find stuff like .finally, predicated catches, long stack traces, unhandled rejection reporting etc essential. Also in 3.0 bluebird debuggability is going to be turbo boosted by warnings that non-seasoned promise users commonly make, e.g. https://twitter.com/PetkaAntonov/status/565899315613540352

[vjeux]

Yeah, at Facebook we use a slightly improved version of Promises with .finally and .done

https://github.com/facebook/react-native/blob/master/Libraries/vendor/core/Promise.js#L42

Don't have the rest though. I'll poll people internally and see what they think.

[aackerman]

The warnings about uncaught promise rejections are the number 1 reason to use bluebird over the specced ES6 promises. Trying to find silently swallowed errors is developer hell.

[aackerman]

If I was intent on finding out more about the JS host environment is here the best place to look?

[vjeux]

This file is:
https://github.com/facebook/react-native/blob/master/Libraries/JavaScriptAppEngine/Initialization/InitializeJavaScriptAppEngine.js

[aackerman]

Awesome thanks, I'll do some reading and see if I can distill some of the information.

[petkaantonov]

btw I checked the finally implementation - just a note that .finally in bluebird doesn't behave like .then(cb, cb); instead it behaves like this

[benjamingr]

@vjeux I think you really want to have long stack traces, unhandled rejection detection and better aggregation methods in your promises. You can always just use a special build of bluebird.

Facebook already has groups using bluebird internally (namely WhatsApp Web), I think having a robust promise implementation would be really nice for react native. (That said, things like a TableView would matter a lot more to me as a user :P)

[vjeux]

Is there a special build of bluebird that's compliant with the es6 spec? Aka not adding extensions such as finally?

[benjamingr]

@vjeux you can remove extensions if you really want to beyond the most partial build (or just not use them) but why? Stuff like .finally will eventually get included in ES, the only reason it was not already included is because they didn't have tie (I can dig up the thread if you'd like).

You can get bluebird down in a partial build to ~5kb but to be fair the extra stuff that makes bluebird bigger has huge usability gains.

[petkaantonov]

I'm not sure I see the point of such a build - there is literally thousands of es6-promise shims available already

[benjamingr]

@petkaantonov well, the general idea is to get the wins from bluebird like long stack traces and more debuggable and faster promises in react-native I think.

[petkaantonov]

Those are not compliant with es6- spec

[benjamingr]

So what? React is not world renowned for sticking to strict ES6 it's known for making pragmatic choices in order to make developer life easier. Adding long stack traces and enabling debuggable promises would be a huge deal.

[vjeux]

React native environment should look like the browser / node. By putting non standard primitives as global we would break all the existing code out there. This would be bad for the entire ecosystem.

In this case, people can just npm install bluebird to get all those non standard behavior if they want to

[brentvatne]

I believe that this is covered in this doc now: https://facebook.github.io/react-native/docs/javascript-environment.html#content