Played around with context api, tried to get the wrapped component to rerender after global context
was updated - this is what I came up with.
Note: this commit makes the playground app use a newer js core as the js core which shipped with RN on Android
is missing javascript Proxy.
Closes #4517
Apparently TopBar elevation property is animated. Meaning that if 4dp elevation is set, when the
view appears its elevation is animated from 0dp to 4dp.
This resulted in rare race condition where the onAnimationEnd callback was called after
we set the desired elevation value, and an unexpected elevation value was set.
Add waitForRender options for setRoot animation and TopBar components
When set, the ui will become visible only after the root screen and TopBar components have been rendered.
Usage
Add the following to the root layout’s options, or to its child
```
animations: {
setRoot: {
waitForRender: true
}
}
```
TopBar components (Title, background, buttons) can be synced as well by adding `waitForRender: true`, for example:
```
component: {
name: 'navigation.playground.CustomTopBar',
alignment: 'center',
waitForRender: true,
}
```
## What this PR is about?
Finally all strict rules are enables for TypeScript compiler! 🎉 Basically previously `noImplicitAny` was turned off but now it plus all strict rules are turned ON! 💋
## Some highlights of the changes
- `Element` renamed internally to `SharedElement` to make more sense what is it
- `LayoutTreeParser`'s responsibility is now to do all `id` related stuff. Previously it was spread between `LayoutTreeCrawler` and `LayoutTreeParse` so it is more simple now
- clean up a lot of tests because they were testing duplicate stuff that was covered by other tests already
- removed all usages of `static get options` and replaces them with `static options`. This is how it is in the docs plus you cannot have `static get options(passProps)` because it is impossible to have getter with parameters.
Until now tabs were added to screen in reverse order, meaning the last tab was attached to hierarchy first and the first tab was attached last.
This caused the first tab, which usually should appear first, to be rendered last as the root view’s startReactApplication was called last.
This commit changes render order so that the first tab is rendered first. Some apps will probably see an improvement in time to interaction as a result.
- `registerCommandListener` documentation was wrong so that is fixed
- use `uniqueIdProvider` much as possible so we are not duplicating logic
- add `appRegistryService` which makes `componentRegistry` cleaner and also makes testing easier
- type return type of `NativeEventsReceiver.ts` correctly
- add types to `LayoutTreeParser`
- `ComponentRegistry.test.tsx` refactor so it tests only things that is should and not implementation of React Native functions
- fix type `center` prop to be required on `LayoutSideMenu`
- add missing layout props `topTabs` and `externalComponent`
- lots of minor cleaning
What is this?
This PR continues the work on making this project type safe with TypeScript. Goal is that the flag noImplicitAny will be set to true
What this PR does?
* all files inside adapter folder is valid for noImplicitAny!
* resolveAssetSource is now imported from the current place where it should. Previously it was imported from legacy location. More info here: https://facebook.github.io/react-native/docs/image#resolveassetsource
* formatted many files
* add missing interfaces
* fix onPressIn prop on TouchablePreview
What's next?
Next I am planning to make same treatment for commands folder and many it valid for noImplicitAny 🎉
Orientation.hasValue returns false for default orientation
This bug caused orientation set in defaultOptions to be disregarded.
Setting default orientation is still somewhat wrong now that its behaviour has changed when targeting SDK 28.
## Goal of this PR
The goal of this PR is to make `OptionsProcessor.ts` great again 🇺🇸 . To me it was total mess including tests.
## What was wrong or funky?
1. the tests tested if React Native's `processColor` color works as it should even though react native has [multiple tests for this](https://github.com/facebook/react-native/blob/master/Libraries/StyleSheet/__tests__/processColor-test.js). Aka we don't have to test React Native's functions :D
2. `LayoutTreeCrawler.test.ts` was testing `OptionsProcessor`s functionality so it was removed now
3. Lots of small things since this was done before putting `noImplicitAny` to true so it wasn't made TypeScript in mind
## Result
Now `OptionsProcessor.ts` should be
1. code way more clear
2. tests are testing only things that they should
3. tests are written in clear way
4. it is easy to see from the tests what the whole function does
5. type safe for TypeScript `noImplicitAny` (when we actually turn it on)
Fix closing sideMenu when pushing a screen (#4491)
When pushing a screen into a stack in the centre controller with `sideMenu.left/right.visible: false` - side menu was not closed as expected.
This happened because when either side menus is open, it’s considered the current child and when options are resolved. the centre controller’s options were ignored.
This commit fixes this issue on Android. When resolving options, the centre controllers options are resolved as well.
Related to #4267
* Use correct path for WorkingLocally
* Plugin init is now deprecated
* docsify-copy-code stylesheet is deprecated
* Use HTTPS, set Docsify version to 4.7.1 and copy-code to version 2
Couple of Docsify Github issues point that there are some rendering problems with 4.8.3 so let's anchor Docsify at 4.7.1 for now
Create BottomTabs once when options are applied
The BottomTabs library we use recreates its children each time a style property changes.
This can hinder performance quite a bit as the view creation logic is quite costly.
This commit introduces a simple fix to this issue - we delay view creation until all options are applied.
BottomTabs refactor
* Prevent view recreation in `onSizeChanged`
* Cleanup `createTabs` method
This property is used to set background color only for components,
unlike backgroundColor which sets color for every type of layout.
Motivation
When a view appears, its options are resolved according to its
currently displayed children. Basically this means that child options
are hoisted to the parent as children can declare options which effect
their parent.
This means that if a component has declared layout.backgroundColor or
if that property was declared in defaultOptions, each view will have a
background color, which might contribute to a significant overdraw.
This property can be used to control how the SideMenu is opened using swipe gesture
bezel - only swipes from the side of the screen open the side menu
entireScreen - Swipe from any area of the screen will open the SideMenu
This PR adds support for setting stack root with multiple children, which is to be expected as stack can be initialised with multiple children.
Closes #4441