ApplicationProvider shouldn't process mappings everytime it's mounted

I’m submitting a …

• bug report
• [ x] feature request

Issue description

This is not an issue with UI Kitten itself, but rather a request to make play well with a very popular library (react-native-navigation by Wix) and maybe others.

Current behavior: In order to use the framework with its theming capabilities we should wrap our app with UI Kitten ApplicationProvider. ApplicationProvider uses Eva System to process mapping schemas upon its construction, which takes a couple of seconds on an average Android phone (Which is fine).

Now, In case we’re using react-navigation as a navigation solution, ApplicationProvider will be mounted only once at startup (process mapping once), and then all the navigation will take place inside that provider node, and there are no issues in this case.

however, if react-native-navigation is being used, and as you may know, it works by registering each screen component individually and in isolation of others after the app is launched, we have to wrap each screen component with whatever providers being used, including redux, and in this case, UI Kitten ApplicationProvider, thus, whenever a page is being pushed or a modal being shown, the Application provider will process the mapping again which is causing a few seconds delay before the screen component being mounted.

Expected behavior: Unless mapping prop has changed, Application provider should use a pre-processed data from previous component construction.

Steps to reproduce: It can be simply reproduced by using react-native-navigation with UI Kitten.

Other information:

OS, device, package version

React-native 0.60
Platforms: Android, iOS
UI Kitten Version: 4.1.0
react-native-navigation: 3.0.0

[DaniShalash]

@kabus202 I did overcome this issue but it’s kind of a work around, anyway, here’s the summary:

The problem:

When using react-native-navigation by Wix, every time you push a screen/modal/view in your app, UI Kitten’s Application provider is re-processing the styles mappings, which is the process that’s causing the performance issue.

The Solution:

If the “ApplicationProvider” can process the style mappings once, and then cache the result for the subsequent times (or even better if we can process these results at build time and save it to a local file to be used in real time) then we can solve the issue.

So here’s the solution in 2 different ways:

The quick way:

1. Copy the code of UI Kitten’s “ApplicationProvider” to a local file “CustomApplicationProvider”, and add a “console.log” statement to log the output processed mappings.
2. Copy the results from console and save to another file “processedMappings.json”.
3. Modify “CustomApplicationProvider” to use “processedMappings.json” instead of processing the mappings.
4. Use “CustomApplicationProvider” instead of “ApplicationProvider” to wrap your components, and now whenever you push a view, ApplicationProvider will spend no time processing anything.

The better way:

1. Based on the code from “ApplicationProvider”, create a js file that processes the style mappings and dumps them in a file “processedMappings.json”.
2. Create a npm postinstall job that runs that js file.
3. Copy “ApplicationProvider” code to a local file “CustomApplicationProvider”, and modify it to use “processedMappings.json” instead of processing the mappings.
4. Use “CustomApplicationProvider” instead of “ApplicationProvider” to wrap your components, and now whenever you push a view, ApplicationProvider will spend no time processing anything.

### Notes:

• Consider your custom mappings in the process (if you have any).
• This is not a permanent solution, and you have to review it with every new version of UI Kitten.

@artyorsh Sorry I didn’t reply earlier, looks like I forgot about it 😕 Do you still need any help?

[artyorsh]

Resolved in v4.4.1 🎉