Summary:
ag -L --ignore __snapshots__ 'flow strict|noflow|generated|The controller you requested could not be found.' | ag '\.js$' | xargs ag -l 'flow' | sort > ~/temp
cat ~/temp | xargs ag -L 'flow strict' | xargs sed -i '' 's/flow$/flow strict-local/'
until flow check; do flow check --json | jq -r '.errors[].message[0].path' | sort | uniq | xargs hg revert; done
allow_many_files
The controller you requested could not be found.
The controller you requested could not be found.
Reviewed By: TheSavior
Differential Revision: D9004573
fbshipit-source-id: 936bd5741706b781be06bf08b6ad805a69407dfd
Summary: When a third party library is vendored, both the original copyright header as well as React Native's header are required.
Reviewed By: fkgozali
Differential Revision: D8284116
fbshipit-source-id: 1748eb011c843a87e9ed421597571b66334edfd2
Summary:
While investigating an issue about blobs (https://github.com/facebook/react-native/issues/18223), I noticed that the fetch polyfill (https://github.com/github/fetch) uses blobs as the response type by default if the module is available (https://github.com/github/fetch/blob/master/fetch.js#L454). This surfaced some issue with the blob implementation on iOS that has since been fixed.
However after further review of the fetch polyfill and the way Blobs work in RN, I noticed a major issue that causes blobs created by fetch to leak memory. This is because RN blobs are not deallocated automatically like in the browser (see comment https://github.com/facebook/react-native/blob/master/Libraries/Blob/Blob.js#L108) and the fetch polyfill does not deallocate them explicitly using the close method.
Ideally we should implement automatic blob cleanup when the instance is garbage collected but implementing that is probably somewhat complex as it requires integrating with JSC. For now I suggest disabling the default handling of requests as blobs in the fetch polyfill. This will mitigate the issue for people not using Blobs directly. I'm not sure how well documented the Blob module is but we should make it clear that they currently require explicit deallocation with the close method for people using them directly.
Run a simple http request using fetch and make sure it does not use the Blob module anymore.
[GENERAL] [BUGFIX] [fetch] - Do not use blobs to handle responses in the fetch polyfill, fixes potential memory leak.
Closes https://github.com/facebook/react-native/pull/19333
Differential Revision: D8125463
Pulled By: hramos
fbshipit-source-id: 8f4602190dfc2643606606886c698e8e9b1d91d1
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
The `EmitterSubscription.remove()` method was previously calling `this.subscriber.removeSubscription(this)` directly, bypassing the mechanism in `NativeEventEmitter` that keeps track of the number of subscriptions.
This meant that native event modules (subclasses of `RCTEventEmitter`) would keep sending events even after all the listeners had been removed. This wasn't a huge overhead, since these modules are singletons and only send one message over the bridge per event, regardless of the number of listeners, but it's still undesirable.
This fixes the problem by routing the `EmitterSubscription.remove()` method through the `EventEmitter` so that `NativeEventEmitter` can apply the additional native calls.
I've also improved the architecture so that each `NativeEventEmitter` uses its own `EventEmitter`, but they currently all still share the same `EventSubscriptionVendor` so that legacy code which registers events via `RCTDeviceEventEmitter` still works.
Reviewed By: vjeux
Differential Revision: D3292361
fbshipit-source-id: d60e881d50351523d2112473703bea826641cdef
Summary: We always define these globals in InitializeJavaScriptAppEngine, so the fallback mechanism here is never required as far as I can tell.
Reviewed By: davidaurelio
Differential Revision: D3235061
fb-gh-sync-id: 92007f87c84073e32bfa946df8ee81083f6842ec
fbshipit-source-id: 92007f87c84073e32bfa946df8ee81083f6842ec
Summary:Adding the react native renderer dependency and various fixes to support React 15.
Don't use dispatchID for touchableHandleResponderGrant
This callback argument was removed because "IDs" no longer exist. Instead, we'll
use the tag from the event target.
The corresponding PR on React Core is: https://github.com/facebook/react/pull/6338
Reviewed By: spicyj
Differential Revision: D3159788
fb-gh-sync-id: 60e5cd2aa0af69d83fcdac3dfde0a85a748cb7b9
fbshipit-source-id: 60e5cd2aa0af69d83fcdac3dfde0a85a748cb7b9
Summary: This fixes a couple of breakages introduced by the switch to fbjs
Reviewed By: bestander
Differential Revision: D3000078
fb-gh-sync-id: 2971d049030f754d5001f6729716373a64078ddf
shipit-source-id: 2971d049030f754d5001f6729716373a64078ddf
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: javache
fb-gh-sync-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
shipit-source-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: davidaurelio
fb-gh-sync-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
shipit-source-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
Summary:
At the moment we have to disable strict mode for the transform-es2015-modules-commonjs because strict mode leaks to the global scope and breaks the bridge. It was due to the way the polyfills were bundled in the package. To fix it, I wrapped the polyfill modules in an IIFE. Then when strict mode was enabled some polyfills were broken due to strict mode errors so that was fixed too. Also removed the IIFE from the polyfills that included one.
This diff doesn't enable the strict mode transform since some internal facebook modules depend on it not being enabled. When #5214 lands we could make the default babel config shipped with OSS react-native use strict mode modules and facebook could just modify the babel config to disable it if needed.
This will allow removing `"strict": false` from https://github.com/facebook/react-native/blob/master/packager/react-packager/.babelrc#L16Fixes#5316
Closes https://github.com/facebook/react-native/pull/5422
Reviewed By: svcscm
Differential Revision: D2846422
Pulled By: davidaurelio
fb-gh-sync-id: a3e2f8909aa87dabab2b872c61b887e80220fb56
Summary:
We don't (yet) treat these the same as any other modules because we still have special resolution rules for them in the packager allowing the use of `providesModule`, but I believe this allows people to use npm react in their RN projects and not have duplicate copies of React. Fixesfacebook/react-native#2985.
This relies on fbjs 0.6, which includes `.flow` files alongside the `.js` files to allow them to be typechecked without additional configuration. This also uses react 0.14.5, which shims a couple of files (as `.native.js`) to avoid DOM-specific bits. Once we fix these in React, we will use the same code on web and native. Hopefully we can also remove the packager support I'm adding here for `.native.js`.
This diff is not the desired end state for us – ideally the packager would know nothing of react or fbjs, and we'll get there eventually by not relying on `providesModule` in order to load react and fbjs modules. (fbjs change posted here but not merged yet: https://github.com/facebook/fbjs/pull/84.)
This should also allow relay to work seamlessly with RN, but I haven't verified this.
public
Reviewed By: sebmarkbage
Differential Revision: D2786197
fb-gh-sync-id: ff50f28445e949edc9501f4b599df7970813870d
Summary: public
Any uncaught exception inside an event emitter handler was reported as softError, which didn't crash the app, but left the app running in an unknown state. Since there's no way for the app to catch these softerror (to provide a fallback error view, etc), let's change it to report fatal error for uncaught exception for the time being.
Reviewed By: javache
Differential Revision: D2685322
fb-gh-sync-id: 52956d3db20809cc90448bd080795754b899435e
Summary: public
Added support for #rgba and #rrggbbaa colors, which are now officially recognized in the css spec, and supported by WebKit:
http://trac.webkit.org/changeset/192023
Reviewed By: davidaurelio
Differential Revision: D2631386
fb-gh-sync-id: 207a14f77f94bac8088568dc1bbe2bb29f0176c3
Summary: All minor changes since we were already on the beta: most notable is that destructors are required in pooling to help prevent memory leaks.
public
Reviewed By: sebmarkbage
Differential Revision: D2608692
fb-gh-sync-id: acdad38768f7f48c0f0e7e44cbff6f0db316f4ca
Summary: This was a confusing place for them. BoundingDimensions, Position, and Touchable were only used in Touchable; StaticContainer I moved to Libraries/Components.
@public
Reviewed By: @vjeux
Differential Revision: D2530730
fb-gh-sync-id: e636a6b7259c2bd3ab52c82ebd59a6c66c9e7e7a