Summary:
When `keyboardShouldPersistTaps` is `"never"` it would break when doing the following steps:
- Tap input 1, keyboard goes up
- Tap input 2, keyboard stays down (The bug I expected without the isTextInput check was that it would dismiss instead :o )
- Tap outside, keyboard stays down. It should dismiss here since it should never persist taps (unless tapping another input)
What seems to happen is that RN `currentlyFocusedTextInput` goes out of sync with the focused text input and is null even if there is still a text input focused. I haven't had time to investigate the cause of that (probably some race condition because of trying to focus and blur at the same time) but we should not try to dismiss the keyboard when tapping another TextInput in the first place.
I reproduced the bug mentioned by setting `keyboardShouldPersistTaps` to `"never"` in RNTesterPage.js and then using the steps described above. I made sure that the bug did not happen after this change.
[GENERAL][BUGFIX][ScrollResponder] - Fix keyboard handling with keyboardShouldPersistTaps: never
Closes https://github.com/facebook/react-native/pull/19255
Differential Revision: D8002818
Pulled By: mdvacca
fbshipit-source-id: 6ecb8d2c30eb9338529471a958b5dc04037c7ec6
Summary: Fix the typo in `RTLExample.js` that is now detected by Flow.
Reviewed By: TheSavior
Differential Revision: D7987526
fbshipit-source-id: d30f536b2f41e2127909675ea065a3355e5576ad
Summary:
Refactors `KeyboardAvoidingView` by using class syntax and fixing all Flow errors.
Note that there's still a bunch of sketchy stuff going on in this component with mutated instance variables (that are used in `render`!) and unsafe lifecycle methods. But at least now it's a little bit less painful on the eyes.
Reviewed By: TheSavior
Differential Revision: D7987443
fbshipit-source-id: f5c27a9dd383c430d9a5a9dc0b6e10e2c4fe8dd9
Summary:
Yoga represents concepts like `margin`, `padding` and `position` as `edges` (aka std::array<YGValue, YGEdgeCount>).
This diff improves conversion of this data structure to string (primarily for debugging purposes).
Reviewed By: fkgozali
Differential Revision: D7958241
fbshipit-source-id: 6931c7b5d2395c28821c8daef62f609b13f112c6
Summary: Oh, my! No more `#define`s related to props conversions and debug-printing.
Reviewed By: fkgozali
Differential Revision: D7958250
fbshipit-source-id: 86950070c55f134aa3a575b9fd68fc90d865cf44
Summary:
Same as previous one.
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `core` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958243
fbshipit-source-id: 500ee420d9aa562ee3c5810ef625e06541eda8fb
Summary:
Same as previous one.
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `view` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958242
fbshipit-source-id: 10199d1fbb43329de93604aa383c884f5cc64dc5
Summary:
Same as previous one.
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `graphics` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958252
fbshipit-source-id: 0f33a2e6aad60befacee31486acdb9b6114d3e07
Summary:
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `attributedstring` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958245
fbshipit-source-id: 275a58bd3955a6ceb4881bffff86bf1d4501b3d2
Summary:
We have to have automatic treatment for `optional` types. So, if we can process type `T` we can also automatically process `optional<T>.`
Support for optional allows us to not introduce new types (with embedded special "undefined" value) or pollute existing pure types (with special "undefined" value). (A lot of examples of those types can be found in AttributedString module.)
Reviewed By: fkgozali
Differential Revision: D7958249
fbshipit-source-id: 21af526a17dd0329e1262020cab8ecb902316654
Summary:
This diff opens a diffstack where we migrate the generation of all prop conversions (convertRawProp) and pretty-printing (debugStringConvertibleItem) functions to C++ templates (instead of using `#define`s).
So, this diff implements base versions of those functions as templated functions.
For now we still need #define-based version, but eventually, we will get rid of it.
Reviewed By: fkgozali
Differential Revision: D7958247
fbshipit-source-id: 24346297c1bd17e8054758f0eb84698eebfa21e2
Summary: This is continue of the work started in D7797561.
Reviewed By: fkgozali
Differential Revision: D7901244
fbshipit-source-id: 2f7a5cd9fa8c0079787e26e19c7c6c4255e54b42
Summary:
This a natiral continue of previous/ongoing work towards modernizing props pipeline.
Less defines, less code, more obvious code.
Reviewed By: fkgozali
Differential Revision: D7901246
fbshipit-source-id: 3387b6d13e21e6ec48a38c9e3708762dfe536105
Summary:
This diff contains several tight to each other changes (which can/should not be split into several diffs):
* The props parsing/conversion process was de-virtualized: we don't use virtual `apply` method to parse props anymore. Instead, we use old-fashioned constructors.
* All fields of Props classes which represent props values were marked as `const` which make impossible to modify them after the objects were created (even if we have non-const value-of/pointer-to the whole Props object). Those fields are also `public` now.
* All custom handwritten getters were removed (because we don't need them anymore).
So, now we don't need all those custom getters which makes code much more compact, performant and codegen-friendly.
Reviewed By: fkgozali
Differential Revision: D7901245
fbshipit-source-id: 9f4b1fd2da64bf963b63215ed3bd74b9d3c58dd5
Summary:
`eslint-plugin-react-native` was a dependencies. I think it should be a dev dependencies like `eslint-plugin-eslint-comments`, `eslint-plugin-flowtype`, `eslint-plugin-jest`, `eslint-plugin-prettier` and `eslint-plugin-react`.
No need
Not needed
[INTERNAL] [ENHANCEMENT] [./package.json] - Move `eslint-plugin-react-native` to devDependencies.
Closes https://github.com/facebook/react-native/pull/18851
Differential Revision: D7991437
Pulled By: hramos
fbshipit-source-id: 5481290423848b9c34df24629086239600d42274
Summary:
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
To fix issue that crash on XCode 9.3
Archive the project in XCode 9.3
This does not change any documentation
To fix issue that crash on XCode 9.3
[IOS] [BREAKING] [RCTImageCache.m] - Crash during archiving in XCode 9.3
Closes https://github.com/facebook/react-native/pull/18682
Differential Revision: D7992071
Pulled By: hramos
fbshipit-source-id: 1089e469712b1eb2fcdd3ad59766c187e932f46c
Summary:
Fresco now maintain proguard rules by itself (https://github.com/facebook/fresco/pull/2075), so it won't be necessary for react native copy its rules.
Run RNTTester Android app in release mode, app build successful and won't crash in ImageModule.
none
[ANDROID] [BUGFIX] [PROGUARD] - remove fresco proguard rules
Closes https://github.com/facebook/react-native/pull/19040
Differential Revision: D7992146
Pulled By: hramos
fbshipit-source-id: 9ee3dd4c6756472395ec9e36a967b469f0760999
Summary: This isn't used internally at Facebook and we have no public documentation for this component. If people are interested in using it they can easily reproduce this function outside of core.
Reviewed By: yungsters
Differential Revision: D7985955
fbshipit-source-id: 859878a858cbcb42fec7f9bd04e5d7574801e445
Summary:
Exposing this enum is essentially useless and at worst is a runtime cost that isn't necessary by just using the string.
The value of this enum, as far as I understand it, is to enforce that only valid options are used. We can enforce this at build time with Flow.
I was able to migrate our codebase with a few Find and Replace for things like
```
resizeMode={Image.resizeMode.contain}
```
Reviewed By: yungsters
Differential Revision: D7983982
fbshipit-source-id: ddd7024023f8d2f01aad1fff6c8103983a1bec1a
Janic Duplessis
Kevin Gozali
Sebastian Markbage
Tim Yung
Valentin Shergin
Vincent Langlet
Aaron Abramov
fattahmuhyiddeen
gengjiawen
David Vacca
Eli White
Federico Trimboli
