Summary:
Fixes npm deployment script as in https://circleci.com/gh/facebook/react-native/6745.
Example situation:
- admin is ready to release 0.26.0
- admin adds tag v0.26.0 and pushes to origin
- Circle CI build fails because of code error
- admin cherry-picks a fix and tags v0.26.0 again and pushes to origin
- Circle does not update local tag v0.26.0 because it already has it cached, compiles the code but fails to deploy to npm because v0.26.0 is not on branch HEAD from Circle point of view
The previous version of the script was checking the tags on current commit as well but it used the local branch tags.
This change fetches tags from `origin` fresh and allows us to redeploy the same version multiple times.
Closes https://github.com/facebook/react-native/pull/7619
Differential Revision: D3334469
fbshipit-source-id: b423fc19516dc4f5f7f2605224e62b8a378c8a7d
Summary:
The packager was failing with below error after a fresh clone
npm ERR! peerinvalid The package react@15.1.0 does not satisfy its siblings' peerDependencies requirements!
Changed the dependancy for **^react@15.1.0-alpha.1** to **^react@15.1.0** and it was fixed.
Closes https://github.com/facebook/react-native/pull/7692
Differential Revision: D3334425
fbshipit-source-id: ee86fc2e3c6f19b2430658d91d0a88c50bcf11de
Summary:
Improved version of #7317.
`setRefreshing` and `setProgressViewOffset` needs to be called after the view has been layed out. Instead of using `post` to do that we update the `refreshing` and `progressViewOffset` values in the first call to `onLayout`.
I also noticed that `progressViewOffset` default value wasn't exactly the same as when not calling `setProgressViewOffset` at all. Tweaked the values to match android defaults.
**Test plan (required)**
Make sure the integration test passes,
In UIExplorer: test RefreshControl with `refreshing = true` initially, test `progressViewOffset`.
Closes https://github.com/facebook/react-native/pull/7683
Differential Revision: D3334426
fbshipit-source-id: ddd63a5e9a6afe2b8b7fe6a25e875a40f4e888c6
Summary:
Travis CI runs Node 4 (LTS), so make CircleCI run Node `<latest>` which is Node 6.
Closes https://github.com/facebook/react-native/pull/7542
Differential Revision: D3334397
fbshipit-source-id: 15a758011626fca4efdc4c1b36891a4d73c52e94
Summary:
Sorry for trivial one, but I feel no need to share '.iml' in a project, so it should be ignored.
Closes https://github.com/facebook/react-native/pull/7689
Differential Revision: D3334367
fbshipit-source-id: 2a68aa93084a51d0b3d24427c71bc7c12e41ed78
Summary:
In RN we cache image data after loading/downloading an image, however the data we store is the compressed image data, and we decode this asynchronously each time it is displayed.
This can lead to a slight flicker when reloading image components because the decoded image is discarded and then re-decoded.
This diff adds a small (5MB) cache for decoded images so that images that are currently on screen shouldn't flicker any more if the component is reloaded.
Reviewed By: bnham
Differential Revision: D3305161
fbshipit-source-id: 9969012f576784dd6f37d9386cbced2df00c3e07
Summary:
[Experimental API breaking changes]
The notion of `parent` or `children` in navigaton is misleading. We have no intention to maintain or
build the nested or hierarchical navigation states. To be clear, rename `navigationState.children` to
`navigationState.route`.
Reviewed By: ericvicenti
Differential Revision: D3332115
fbshipit-source-id: c72ed08acaf030fb9c60abf22fb15cc0f44b3485
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.
I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.
**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.
I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155
Reviewed By: bestander
Differential Revision: D3301008
Pulled By: davidaurelio
fbshipit-source-id: 504180d158a1e50bc03e28fb0d1e53d0731ce32f
Summary:
[public / experimental API breaking change]
The data type of `scene.navigationState` is `NavigationRoute`. Rename `scene.navigationState` to
`scene.route` to avoid confusion such as treating `scene.navigationState` as the actual global navigation
state (type: NavigationState).
Reviewed By: ericvicenti
Differential Revision: D3331076
fbshipit-source-id: 3ed989cc8492d398cbeb1b12186459deb261d1fb
Summary:
The default itemPositioning is `automatic` (referred to `auto` in this pull request) - you can check its behaviour in the docs attached.
Sometimes that value has to be modified to have more predictable appearance as described in #4136.
Closes https://github.com/facebook/react-native/pull/7217
Differential Revision: D3220958
Pulled By: mkonicek
fbshipit-source-id: d4bf648b16e71825cd31c06d6b6396479767d19f
Summary:
This is the first step to clarify and simplify the type definations about navigation state.
For now, `NavigationParentState` is actually used as the real navigation state and `NavigationState` is used
as a route in navigation, which has been confusion among the APIs.
To be clear, our APIs has no intention and interest in dealing with nested or hierarchical navigation states,
and we should avoid have the name like `ParentState` or `children`.
To fully migrate the types, theer will be a lot of code changes and this is just the first step to rename.
= What's Next?
1. rename `navigationState.children` to `navigationState.routes` (breaking change!)
2. remove `navigationState.key` from its type defination.
Reviewed By: ericvicenti
Differential Revision: D3321403
fbshipit-source-id: 3e39b60f736c1135bc85d8bf2b89027d665e28d4
Summary:
It seems like the examples weren't working since the merge of `IntentAndroid` and `LinkingIOS` since they were still using `TouchableNativeFeedback` only available on Android.
The problem was also reported here : https://github.com/facebook/react-native/issues/7615
Closes https://github.com/facebook/react-native/pull/7655
Differential Revision: D3329233
fbshipit-source-id: 8c9cabaab0a616dab406c4e444c9fa6da5f54b6d
Summary:
See "D3291793 Symbolicate JS stacktrace using RN Packager" for the background
of why this matters. TLDR - saving tons of memory by moving symbolication from
JSC into server and cleaning up old hacks.
Before this change: a redbox causes +73MB JSC size
{F60869250}
{F60869249}
After this change: a redbox causes +1MB JSC size
{F61005061}
{F61005062}
Next step – replace JS implementation by native to show better progress and
clean up even more old APIs (ExceptionsManager.updateExceptionMessage).
Reviewed By: davidaurelio
Differential Revision: D3319151
fbshipit-source-id: 48ff4df27642ea4e1bc2414f48a8dd4d32adee50
Summary:
The way we currently symbolicate JS stack traces in RN during development time
(e.g. inside the RedBox) is the following: we download the source map from RN,
parse it and use `source-map` find original file/line numbers. All happens
inside running JSC VM in a simulator.
The problem with this approach is that the source map size is pretty big and it
is very expensive to load/parse.
Before we load sourcemaps:
{F60869250}
After we load sourcemaps:
{F60869249}
In the past it wasn't a big problem, however the sourcemap file is only getting
larger and soon we will be loading it for yellow boxes too: https://github.com/facebook/react-native/pull/7459
Moving stack trace symbolication to server side will let us:
- save a bunch of memory on device
- improve performance (no need to JSON serialize/deserialize and transfer sourcemap via HTTP and bridge)
- remove ugly workaround with `RCTExceptionsManager.updateExceptionMessage`
- we will be able to symbolicate from native by simply sending HTTP request, which means symbolication
can be more robust (no need to depend on crashed JS to do symbolication) and we can pause JSC to
avoid getting too many redboxes that hide original error.
- reduce the bundle by ~65KB (the size of source-map parsing library we ship, see SourceMap module)
Reviewed By: davidaurelio
Differential Revision: D3291793
fbshipit-source-id: 29dce5f40100259264f57254e6715ace8ea70174
Summary:
I'm really excited to finally have been able to share with the world the app that I've been building with React Native for the last six months! Emberall is the best way to save and share family videos, and record special moments with your kids as they're growing up. (vjeux ping me if you want a premium account for free :P ) More details are on our company [blog](http://emberall.com/blog).
I've been heads down for a while just getting this out the door, but I'll try to have a blog post out soon with lessons learned in getting the app finished and published in the App Store.
Closes https://github.com/facebook/react-native/pull/7657
Differential Revision: D3328341
Pulled By: vjeux
fbshipit-source-id: ef0c6a8e68fa1cab6caf6daa1a0d7d177d752e7f
Summary:
Developing with react-native on Linux, I found myself facing this message:
The problem is actually quite simple: I hadn't used `react-native start` before starting `react-native run-android`, which caused this error, both on an emulator and a real Android device. As the message is currently unhelpful, but can be shown because of a simple mistake, I updated it.
~~Additionally, I clarified the fact that `react-native start` is still necessary on Linux, updating a title on the Linux and Windows Support documentation page.~~
Closes https://github.com/facebook/react-native/pull/7396
Differential Revision: D3305078
fbshipit-source-id: 2d87e02ff2ad15d8239fbcc0ada4a4e67b982e94
Summary:
This pull request is a prerequisite to enabling the react-native-windows platform extension.
In the Resolver component, we need to add 'windows' to the list of platforms that are allowed in the DependencyGraph. We also need to add 'react-native-windows' (the name of the Windows platform extension NPM module) to the `providesModuleNodeModules` option. This allows the node_module folder check in the DependencyGraphHelper from node-haste to be bypassed for *.windows.js files in the Windows NPM package.
For good measure, I also included a change to blacklist.js to ensure .windows.js files are ignored when the packager is parameterized on a platform.
Closes https://github.com/facebook/react-native/pull/7639
Differential Revision: D3327771
Pulled By: mkonicek
fbshipit-source-id: d1080b045ff6aa0cbf05d8070ceb0eb4cdb6dceb
Summary:
This is initial (first step) in the merging process. For now, we are just going to move our code as is into `local-cli` folder (first commit). There were other tweaks made in separate commits to make it easier to go through the code as the diff is expected to be rather large. The purpose of this is to make it easier to start working in small batches and improving the CLI incrementally on a daily basis.
Current codebase will still leave in `rnpm` organisation on Github where we keep working on new features, bugs and ship releases to `npm` until we finish our integration and provide a nice interface for users to migrate (in case it changes at all)
Flow, Jest and npm will ignore this folder for now until we integrate it properly.
Tests are to be rewritten from mocha to jest in `rnpm/link`. We will hook them all up as soon as we start using them in local-cli.
For now, there's no point in having them running and possibly breaking the builds.
We will announce next steps with Kureev later this week
Closes https://github.com/facebook/react-native/pull/7550
Differential Revision: D3327772
Pulled By: mkonicek
fbshipit-source-id: 90faa4bd78476d93ed21b1253e0d95c755d28a30
Summary: - Removed some styling from `SwipeableRow` that wasn't doing much and made slide out view full height
Reviewed By: fkgozali
Differential Revision: D3322849
fbshipit-source-id: 811eee9032c142c61d303ae7e966d8ef7903adaf
Summary:
Before:
- Android had the slideout row flash upon render due to it being rendered first
- iOS had the left side of each row load first, then rerender to show entire row when `scrollViewWidth` is available
Reason:
- Android was loading the slideout view first without an opacity check
- iOS was loading the swipeable view with width 0 first then stretching to `scrollViewWidth` when it was available via `onLayout`
Fix:
Render swipeable view with `flex: 1` then render slideout view
Reviewed By: fkgozali
Differential Revision: D3321466
fbshipit-source-id: 92a3b5e22034e06d05986ddb8c348796bafbbf34
Summary:
- Replace some fixes that were accidentally lost in local rebase that prevent jumpiness when incremental is disabled.
- Require each row to have a key specified by the caller to prevent jumping because of accidental duplicates or unneeded/problematic row re-rendering because of legit re-ordering.
Reviewed By: steveluscher
Differential Revision: D3322006
fbshipit-source-id: 0019aab07cb1fe2b148a14b5818de53aa373eb50
Summary:
Fixing JSX tag in DirectManipulation section of the docs
Closes https://github.com/facebook/react-native/pull/7622
Differential Revision: D3321130
fbshipit-source-id: e315529dc94c88597e4855a63ba6931301d4dba7
Summary:
Incremental rendering is a tradeoff between throughput and responsiveness because it yields. When we have plenty of
buffer (say 50% of the target), we render incrementally to keep the app responsive. If we are dangerously low on buffer
(say below 25%) we always disable incremental to try to catch up as fast as possible. In between, we only disable
incremental while actively scrolling since it's unlikely the user will try to press a button while scrolling.
This also optimizes some things then incremental is switching back and forth.
I played around with making the render window itself adaptive, but it seems pretty futile to predict - once the user
decides to scroll quickly in some direction, it's pretty much too late and increasing the render window size won't help
because we're already limited by the render throughput at that point.
Reviewed By: ericvicenti
Differential Revision: D3250916
fbshipit-source-id: 930d418522a3bf3e20083e60f6eb6f891497a2b8
Summary: Default image icon size for Quick Actions could cause slideout view to bleed over the slideable view. All styling has been removed and must now be passed in, thus allowing every caller to control size for best fit.
Reviewed By: furdei
Differential Revision: D3315696
fbshipit-source-id: 8f8b3d2cf7a005d42a18d434d9e0080c64597be0
Summary:
- Fork NavigationAnimatedView to NavigationTransitioner
- NavigationAnimatedView will soon be deprecated and we'd ask people to use NavigationTransitioner instead.
Difference between NavigationTransitioner and NavigationAnimatedView
- prop `applyAnimation` is removed.
- new prop `configureTransition`, `onTransitionStart`, and `onTransitionEnd` are added.
tl;dr;
In NavigationAnimatedView, we `position` (an Animated.Value object) as a proxy of the
transtion which happens whenever the index of navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that changes the navigation state
without changing the index.
Also, we believe that the name `Transitioner` is a better name for this core component
that focuses on transitioning. Note that the actual animation work is done via
`<Animated.View />` returnd from the `renderScene` prop.
Reviewed By: ericvicenti
Differential Revision: D3302688
fbshipit-source-id: 720c3a4d3ccf97eb05b038baa44c9e780aad120b
Summary:
... used as both a shape and plain object.
this splits them out so both parts can be used as needed.
NavigationPropTypes.SceneRenderer is a PropTypes shape
NavigationPropTypes.SceneRendererProps is the plain object that makes up the shape.
Closes https://github.com/facebook/react-native/pull/7518
Differential Revision: D3317322
Pulled By: ericvicenti
fbshipit-source-id: e8a31e05130e6647b63f68dbef31bc874550948c
Nick Lockwood
David Aurelio
Konstantin Raev
Shiran Ginige
Janic Duplessis
James Ide
Pieter De Baets
MIYOKAWA, Nobuyoshi
Nathan Azaria
Hedger Wang
Philip Heinser
Joel Marcey
Andrej Badin
Nicolas Charpentier
Chris Hopman
Corné Dorrestijn
Mike Grabowski
Christoph Pojer
Jimmy Mayoukou
Alex Kotliarskyi
Kyle Corbitt
Hugo Agbonon
dmueller39
Alexander Blom
Eric Rozell
Fred Liu
Spencer Ahrens
Leonardo Tegon
Joe Noon
Marc Horowitz
