Summary: There is no point in dispatching to main thread if there is nothing to do there.
This place gets called basically any time a repeating js timer fires, which doesn't imply UI changes (although usually that's why people setup timers).
Combined with previous diffs that makes us not generate empty blocks (nil instead), this could be minor perf win in some rare cases.
This also changes semantic of `reactBridgeDidFinishTransaction` call a bit. Previously it was done no matter if UI has changed or not.
I think it should be safe, since seems like callees really care only about views being laid out.
Depends on D2571166. (not strictly speaking)
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2571188
fb-gh-sync-id: 02d52e4615475072c3c27226e67c431a667ec990
Summary: Same as in previous diffs. Gets us into a better place to know if we really have UI updates and it's marginally more efficient.
Depends on D2571143. (not really)
public
Reviewed By: nicklockwood
Differential Revision: D2571166
fb-gh-sync-id: e8f34521ec2e12156a49f1cd655e92df1db34fca
Summary: There is no point in returning empty block here. It's a tiny bit wasteful and prevents us from knowing if there are any UI updates.
Depends on D2571122 (not really).
public
Reviewed By: jspahrsummers
Differential Revision: D2571137
fb-gh-sync-id: 4a872f33f05eaf2d858009aa04ea89feaa23576c
Summary: Previously `_bridgeTransactionListeners` were informed about `reactBridgeDidFinishTransaction` inside of one of the UI blocks.
That seems pretty arbitrary, doesn't really mean a "transaction" is really over (assuming transaction means all UI updates) and even when that block does nothing we still need to call these listeners, since there could be other UI blocks generated somewhere else!
So I've moved this call to a place that seemed better (=after all UI blocks are done), since all listeners are interested in knowing when layout has happened.
public
Reviewed By: nicklockwood
Differential Revision: D2571122
fb-gh-sync-id: 62be03ebc4353d6f6318c9765079b87b07483be2
Summary: public
The dev mode override feature was built with the assumption that bunlded JS would be minified, and broke with unminified JS. This fixes that by using a more robust regex-based search.
Reviewed By: tadeuzagallo
Differential Revision: D2581240
fb-gh-sync-id: 4d4b45eb8573ceb956b7259550d80a9807f83d59
Summary: This adds the moduleNameMapper config which corresponds to the same config in flow.
public
Reviewed By: voideanvalue
Differential Revision: D2582879
fb-gh-sync-id: f116b86a7d4196c39faa366a521fe8401769b173
Summary: public
This is not only to put the files on a place where it makes more sense but also to allow to use ES6 features on them as `/packager` is not whitelisted on `babel`.
Reviewed By: mkonicek
Differential Revision: D2577267
fb-gh-sync-id: b69a17c0aad349a3eda987e33d1778d97a8e1549
Summary: This version should be more stable and has the `moduleNameMapper` feature that frantic was asking for - I will send a follow-up diff for that. I also fixed an issue with `module.parent` and a module inside of yeoman that thought it was owning the universe.
See https://github.com/facebook/jest/blob/master/CHANGELOG.md#061 for a changelog since 0.5.6.
public
allow-crlf-text
Reviewed By: javache
Differential Revision: D2579041
fb-gh-sync-id: cb918875557f219239f49fc0ad49ac61d0884173
Summary: public
This was introduced by vjeux on 0a5967d and removed on 0686b01. I guess it was removed accidentally as this this is a nice warning to have that should prevent n00bs from commiting a common mistake
Reviewed By: frantic
Differential Revision: D2563885
fb-gh-sync-id: 9fae145bbec587514f118d1d28d076b1d82f0630
Summary: public
We cannot remove `local-cli` because is referenced by the global cli explicitly. If we do so, people would have to upgrate this global thin cli which will cause some pain. So, lets move `private-cli` commands into `local-cli` instead.
Reviewed By: frantic
Differential Revision: D2571983
fb-gh-sync-id: 712c29430203660fb6f0d5f23813cb2a7156ee48
Summary: public
Rename the dev menu button and add comments to the private method
used.
Reviewed By: ndfred
Differential Revision: D2576599
fb-gh-sync-id: cd5cde7562dcbc243663ac68d2b9cac5c0a984ab
Summary: We have a use case in the development of our app, where we are rendering some HTML content in a web view. But this content comes from the back end, and varies in height. There are other components on the page, so it's not a full screen web view. We need to dynamically alter the web view height, to fit the HTML content without scrolling, and to push the non-web view content on the screen down.
The solution I came up with, was to use the _loadingFinish callback, to send the evaluation of the injectedJavaScript property back to the React Native side. In my example above, injecting 'document.getElement(elementId).offsetHeight' evaluates to the height of the element, with margins and borders applied, and once returned to the RN app, it can change the app state and cause the web view height to be adjusted.
Closes https://github.com/facebook/react-native/pull/2753
Reviewed By: svcscm
Differential Revision: D2578688
Pulled By: mkonicek
fb-gh-sync-id: fc9c0d0f84994a409e037016a555534549f8957a
Summary: We need to cherry pick this one as well.
cc ide
Closes https://github.com/facebook/react-native/pull/3640
Reviewed By: svcscm
Differential Revision: D2577961
Pulled By: mkonicek
fb-gh-sync-id: 3368fc02a931e0f259f3baa6706bd7d8586b0fbf
Martin Konicek
Mike Armstrong
Harry Wolff
Martin Kralik
Nick Lockwood
David Aurelio
shrimpy
Krzysztof Magiera
Andrei Coman
Christoph Pojer
Martin Konicek
Pawel Sienkowski
Martín Bigio
Alexey Lang
Clement Genzmer
Jeff Morrison
Brent Vatne
James Ide
Jakob Hilden
Joshua Sierles
Melih Mucuk
Tadeu Zagallo
Divyendu Singh
QingFeng
PJ Cabrera