Slow performance compared to “pure” react-native

Describe the bug
I Wrote 2 lists, one using native-base components, second one using react-native components, and I am experiencing 2 to 3 times slower render on native-base side, my example consists of fairly simple list, so I wanted to ask if anyone else is experiencing similar performance issues, or for advice on what am I doing wrong or how to speed things up.
To Reproduce
In my example are 2 buttons, which will navigate you to respective list, with time it took to fully transition in ms.
Expected behaviour
Similar render times to react-native components.
CodeSandBox/Snack link
codesandbox template
Render times in ms

| DEV | DEV | DEV | DEV | PROD | PROD | PROD | PROD
-- | -- | -- | -- | -- | -- | -- | -- | --
Native Base | Android | Android | IOS | IOS | Android | Android | IOS | IOS
  | Emulator | Samsung S21 | Emulator | Iphone 13 Pro | Emulator | Samsung S21 | Emulator | Iphone 13 Pro
1 | 1103 | 319 | 266 | 188 | 605 | 255 | 208 | 150
2 | 947 | 303 | 173 | 199 | 522 | 232 | 101 | 149
3 | 966 | 339 | 163 | 191 | 615 | 236 | 94 | 150
4 | 1069 | 306 | 157 | 191 | 496 | 211 | 101 | 150
5 | 919 | 307 | 154 | 192 | 543 | 209 | 90 | 150
Avg. | 1000,8 | 314,8 | 182,6 | 192,2 | 556,2 | 228,6 | 118,8 | 149,8
  |   |   |   |   |   |   |   |
  | DEV | DEV | DEV | DEV | PROD | PROD | PROD | PROD
React Native | Android | Android | IOS | IOS | Android | Android | IOS | IOS
  | Emulator | Samsung S21 | Emulator | Iphone 13 Pro | Emulator | Samsung S21 | Emulator | Iphone 13 Pro
1 | 424 | 104 | 93 | 89 | 111 | 32 | 27 | 47
2 | 395 | 105 | 62 | 91 | 96 | 39 | 24 | 46
3 | 437 | 106 | 64 | 90 | 101 | 38 | 24 | 45
4 | 472 | 135 | 63 | 91 | 89 | 39 | 22 | 44
5 | 528 | 103 | 63 | 90 | 87 | 40 | 27 | 44
Avg. | 451,2 | 110,6 | 69 | 90,2 | 96,8 | 37,6 | 24,8 | 45,2

@vasafix Does it happen with any 3.x version?
I am experiencing an issue with 3.0.6 in Android: the more Native Base components are rendered the slower further rendering performance (i.e. when switching between visible app components). Each time I create and render a component including Native Base components I see more visible delays before my component starts to interact (run useEffect callback on mount). Seems like something is blocking event loop.

@vasafix have you tried our latest release because we have done a lot to fix these kinds of performance issues.
So @vasafix and @ezze, I would highly recommend both of you share your feedback on the performance of our latest version (i.e., 3.3.2).

@MD-REHMAN My issue is resolved after upgrading to 3.2.2. Unfortunately, I can't upgrade to 3.3.x at the moment because it introduces new bugs like this.

@MD-REHMAN Can’t compare, because after updating to 3.2.2. I am now getting error:
useTheme must be used within NativeBaseConfigProvider
New snack link (native-base-3.3.2)
This example is exactly same as the original one I posted, with difference of native-base version and its new dependencies @types/react and @types/react-native

@MD-REHMAN Can’t compare, because after updating to 3.2.2. I am now getting error:
useTheme must be used within NativeBaseConfigProvider
New snack link (native-base-3.3.2) This example is exactly same as the original one I posted, with difference of native-base version and its new dependencies @types/react and @types/react-native

Seems that 3.2.4 fixed this error, I will make new render time table

Hi @vasafix
did you try with a new render time table?
I upgraded nativebase to latest version ( 3.3.7 ) but low-performance problem is still there
thanks in advance

My company and I also have performance issues
A simple test can be done like this:
const TestComponent = () => {
   const [data, setData] = useState(0);
   useEffect(() => {
       const interval = setInterval(() => setData(d => d+1), 100);
       return () => clearInterval(interval);
   }, [])

   return (
       <>
           <Text>{data}</Text>
           <Button onPress={() => console.log(data)}>Click me!</Button>
       </>
   )
}

It simply rerenders every 100ms. When importing Button and Text from NativeBase, there's a latence on the button (like a few seconds), but when importing from ReactNative, or other libs like MagnusUI, there's no (or a few ms) latence.
This is a stress test, but you will have the same issue with 1s rerender frequence.
It's an issue which should be high priority, because it prevents to use NativeBase as a component library.
I think a good first step would be to check which component has to be optimized, to understand if it's the whole library (because of the contexts?, or the way props are computed?) or only a few components

Unfortunately I also have to step in and confirm that as of today nativebase just isn't viable in production for android devices.
I am currently undergoing the process of rewriting my whole app (which is live and distributed to millions of users...) using simple react native component; what a bummer.
If there is any plan on improving performance for android I would love to hear about it.

I posted a similar issue on This.
I believe the more React Native components you use the slower your app will be.
Native Base is great. But this is a big issue. Most people will get rid of Native Base from their code because of it. And it is too sad that they have to rewrite their project in pure react-native if their code heavily depends on it. So read this before you dive deeply into native base. Hope they can fix this issue soon.

https://snack.expo.dev/H3aB8nOYG
The lag is still there and it is still significant.
I have discovered this issue right before pre-production testing and I have no idea how I am going to replace these many components.

After doing some profiling the issue seems to lie with with this function which is called in every component
https://github.com/GeekyAnts/NativeBase/blob/74274d3b6bbaa49cf3731afb58027c4f8d5c22bb/src/hooks/useThemeProps/usePropsResolution.tsx#L193
Ideally this could be refactored to reduce the new object allocation.

Hey folks, performance is on the top of our priority list right now, we wanted to stabilize a few things before jumping on this ship hence the delay, but be assured NativeBase will have the performance issues sorted in the upcoming weeks.

Benchmark: https://tamagui.dev/docs/intro/benchmarks

Those benchmarks are actually quite shocking. I can confirm performance problems when navigating to new screens, where users experience a significant delay while the new screen is being rendered.

The tamagui benchmark results are quite old, If I remember correctly these results were out when NativeBase v3 was initially released. But since then it has already improved significantly but yeah much more work is needed and we are already on it ✊ .

I can confirm we also have huge lag issue on Android using native-base.
Especially on list, we have to really be careful on changing a state/re-rendering list, we try not to in Android.
We had to disable some feature on our app because of that.

I can confirm we also have huge lag issue on Android using native-base.
Especially on list, we have to really be careful on changing a state/re-rendering list, we try not to in Android. We had to disable some feature on our app because of that.

Make sure to use pure/memoized component like you mentioned, but not only:
when inside a list, I make sure the renderItem does not render native base component, I go back to pure react native Views and it does fix the list performance issue.
Of course this is just some temporary "hack" while waiting for native base to fix those performance issues...

@pierroo Yes, thanks a lot for the recommendation, but in our case we cannot really afford that, one of the main component of our app EventCard is written using native-base in order for us to have it working on both the app and the web, that's actually one of the main reason why we choose native-base

Rewriting this component in pure react native would probably help a lot with the performance issue (thanks a lot for the suggestion), but it would also be like dropping native-base and its benefit/why we choose it :(

Hello
We had the same performance issues as described in the previous comments. The issue was mostly visible on Android, but also on iOS.
We did a workaround requiring some work, but allowing us to keep a majority of native base props, by using the useStyledSystemPropsResolver hook, which is not impacted by any performance issue. By doing that we saw an improvement of more than 50% for the first render time of our most impacted screens.
Here is an example implementation for the Box component:
const Box = forwardRef<View, React.PropsWithChildren<BoxProps>>(
  ({ children, _text, safeAreaBottom, safeAreaTop, ...props }: React.PropsWithChildren<BoxProps>, ref) => {
    const [style, otherProps] = useStyledSystemPropsResolver(props);
    const { top, bottom } = useSafeAreaInsets();
    const safeAreaStyle = useMemo<StyleProp<ViewStyle>>(() => {
      const baseStyle: StyleProp<ViewStyle> = {};
      if (safeAreaBottom) {
        baseStyle.paddingBottom = bottom;
      }

      if (safeAreaTop) {
        baseStyle.paddingTop = top;
      }

      return baseStyle;
    }, [safeAreaBottom, safeAreaTop, top, bottom]);

    return (
      <View {...otherProps} style={[style, safeAreaStyle]} ref={ref}>
        {wrapStringChild(children, _text)}
      </View>
    );
  }
);

Where View is imported from react-native.
For the rest of the component, the goal was to also mimic how native-base would interact with the theme, for example for the Pressable or the Button component.
Hope this will help.

@foyarash very impressive 🔥. Have you managed to fix the Button performance issue? Can we know your implementation?

@foyarash very impressive 🔥. Have you managed to fix the Button performance issue? Can we know your implementation?

I made a gist with the few files i used https://gist.github.com/foyarash/fa260a37fae9b085b89af13f61f46713
This worked well in our case since we don't have to handle dark mode for our app, so keep in mind that it really depends of the features you're using with native base.

+1. I feel the lag on iOS while using NB for a couple of weeks. Really need to re-think if i need to abandon it. I am a paid customer.

While the issue described here is regarding Mobile, I am experiencing a similar issue using native base with NextJS. The biggest issue is observed on inputs that use text like Input and TextArea. Writing fast on the input does not provide instant feedback but takes a while between typing fast and seeing what was typed reflected in those inputs. Also, there are some slow animations. So I guess the issues are in the core and not the platform-specific implementation.
Does the team have a deadline? I am asking because started to implement something that needs to go to prod in 2 months but if the issue remains I will need to replace Nativebase.

Hey folks, we are currently working on it and have already fixed components like Checkbox, we have found that the major performance issue is on Android. Currently, we are trying to resolve component theme props at boot time and inline props at runtime. I guess this will reduce the overhead on the JS Engine during runtime and give a perf boost to the App.

Also for the perf issues on other Platforms apart from Android, It would be really helpful if you guys can share some code snippets and GIFs of the same.

Hey folks, we are currently working on it and have already fixed components like Checkbox, we have found that the major performance issue is on Android. Currently, we are trying to resolve component theme props at boot time and inline props at runtime. I guess this will reduce the overhead on the JS Engine during runtime and give a perf boost to the App.

Thank you for your reply and information.
Having fixed Checkbox is great for sure, but considering the hundreds of other components that needs to be fixed as well, is there any way to follow up the progress or have some kind of roadmap to better align our expectations?
Somehow, there must be some issue in the core of native base and its way of writing components, that once found out and fixed should be easily replicated overall, no?
Not gonna spoil this thread, but another easy way to see how slow the overall components are, switching from day to night mode in the app takes around 2-3 seconds, where it happens almost instantly with any other provider.
Maybe this will be improved  with your current work on boosting runtime?

I also try to change lodash implemenation inside NativeBase with JavaScript native implementation. I got this result

Hi @rayan1810 , just curious... Is there any plan or update for this issue?

Hey @arryanggaputra, definitely there is a plan. We are currently working on fixing this issue. The solution requires some major rewrite internally, won't break user API but we have to change a lot of things inside every component. This will take some time so we will be releasing some alpha/rc versions in the next week, you can test it out and help us fix the remaining bugs.

@rayan1810 It would be great if you can divide the whole plan into small issues for the open source community to contribute to 😃

Hi @rayan1810 thank you for your help! I am also wondering if you guys are working on improving performance specifically for the Action Sheet and Buttons for Androids ? Thank you very much for your help !

Hey folks, here is the Progress Update. We are working on the performance improvements and have also achieved significantly better performance metrics but it has resulted in a heavy increase in boot time load. We are currently trying to fix this by moving the same calculations to build time but due to some coupling between theme and react it's causing few issues but don't worry we have few solutions that we are trying to implement and then a rc release can be shared to test it out.

Thanks a lot @rayan1810 for the update. Is this perf improvement on just Android only or also on iOS too?  In my case, our iOS app performs significantly slower than Android (about 3x slower). Since we are on the critical path for releasing prod version, any updates on the progress would be really helpful for our planning.
Thanks to you and your team for working on this.

Hey @kengjungwa , the performance improvements is for all the platforms but significantly focused on Android. For iOS we haven't found any such specific issues in our testings can you please share what you are facing?

If it may help, I just came across this new lib which was released in May:
react-native-performance gives easy perf measurements for React Native apps.
https://github.com/Shopify/react-native-performance

Hey @rayan1810, is there any rc available about this issue? Thanks in advance for all the amazing work 🙌

Hola folks!! I’ve some good news for you guys 🎉
As you know, we were working on fixing the performance issues with NativeBase. Here is an update.
We have an alpha version out that provides you with better runtime caching. You can also generate a pre-resolved theme style at build time using the newly released babel plugin @native-base/babel-plugin.
Steps for getting it up and running:
yarn add<EMAIL_ADDRESS>
yarn add -D @native-base/babel-plugin

Now add the native-base babel plugin in your -
babel.config.js:
module.exports = function (api) {
  api.cache(true);
  return {
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
  };
};

or .babelrc:
{
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
}

Try running your Apps now and let us know your feedback.

Note: This is still in alpha stage so might have some issues with particular components.

@rayan1810 Thank you and your team so much for your efforts !
I unfortunately ran into some issues when upgrading to 3.5.0-alpha.7 and adding the babel-plugin:

When adding the babel-plugin to my babel.config.js,

module.exports = function(api) {
  api.cache(false);
  return {
    presets: ['babel-preset-expo'],
    plugins: [
      '@native-base/babel-plugin',
      'react-native-reanimated/plugin',
      ['inline-dotenv', { path: '.env' }],
      ['module-resolver', { alias: {'@': './' } }],
    ],
  };
};

both on IOS and Android I got the following error:

node_modules/expo/AppEntry.js: [BABEL]: Unexpected token '.' (While processing<EMAIL_ADDRESS>/Users/audreyjw/Documents/Clients/Synerion/Synerion.ESS.React-Native/node_modules/@native-base/babel-plugin/index.js:84
bundle.resolvedStyledMap?.generatedBuildTimeMap;
^
SyntaxError: Unexpected token '.'
at wrapSafe (internal/modules/cjs/loader.js:915:16)
at Module._compile (internal/modules/cjs/loader.js:963:27)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at loadCjsDefault (/Users/audreyjw/Documents/Clients/Synerion/Synerion.ESS.React-Native/node_modules/@babel/core/lib/config/files/module-types.js:100:18)
at loadCjsOrMjsDefault (/Users/audreyjw/Documents/Clients/Synerion/Synerion.ESS.React-Native/node_modules/@babel/core/lib/config/files/module-types.js:72:16)

If I comment out the "@native-base/babel-plugin" in babel.config.js and run the app,
a. on IOS it loads but I get the error:

fontFamily "Roboto" is not a system font and has not been loaded through Font.loadAsync.

when my config is exactly like documented here.
b. on Android, the app doesn't load at all and I get the following error message

TypeError: undefined is not an object (evaluating 'Object.keys(object == null ? void 0 : object[providerId])')
This error is located at:
in NativeBaseProvider (created by App)
[...]

PS: My app uses Expo & Typescript. Here are some of the information from my package.json
{
  [...]
  "dependencies": {
       "expo": "~45.0.6",
        "react": "17.0.2",
       "react-native": "~0.68.2",
       "native-base": "3.5.0-alpha.7",
       "babel-plugin-inline-dotenv": "^1.6.0",
       [...]
   },
   "devDependencies": {
      [...]
       "@babel/core": "^7.12.9",
       "@native-base/babel-plugin": "^1.0.4",
       "babel-plugin-module-resolver": "^4.1.0",
  }
}

I also tried deleting my node_modules and yarn.lock and redo a yarn install and still same errors :(
Thank you so much again in advance! Hope this is not something too difficult to solve....

Thanks @Audrey-Ann for reporting this I'll be looking into this and try to release a fix as soon as possible 📦 🏃

@rayan1810 Thank you very much ! Don't hesitate to ask me for more details if that can help too :") !

@rayan1810  thank you very much for the update. This is my error
iOS Bundling failed 1113ms
index.js: [BABEL]: Cannot find module '/Users/mbp/Project/UIProject/example/node_modules/native-base/src/bundle'
Require stack:

@eytanProxi could you quantify that?

@Audrey-Ann @arryanggaputra thanks for your patience, we have fixed the babel plugin for ios and android issues in @native-base/babel-plugin version 1.0.9. But it led us to find that, the babel config is treated differently by different bundlers that is why we had to introduce a new caching folder .native-base that stores the data that the babel plugin requires to function as intended. This in turn adds one more step to the babel plugin setup. Now you have to clear this cache folder every time you run a dev build else your resolved style map will keep on increasing in size. Not sure if it makes much sense without the whole context of how we are resolving the theme at build time. But all you have to do more is to add rm -rf .native-base in your dev script.
Something like this:
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "other-scripts":"yarn something",
    "dev": "rm -rf .native-base && yarn start",
  }

If you still face the issues please try deleting your node_modules and reinstalling the deps. Let me know even after that if the issue still persists.

I also found performance problems that are somewhat intensified by using nested navigation (https://reactnavigation.org/). I'm also using RN 0.69. I started building large project with it but will have to rewrite it all with my team :( since performance is not good enough for client.
Anyway. I installed the alpha version and (with rm -rf node_modules/) started my app on android. Performance is better but still first render of page with search and 25 mock results (2 small images, and some text in each of them) takes around 1,5 -2 seconds (From pressable click to navigation to page. Without NativeBase it's 0.3-0.5 s). With bigger pages results are even worse.
The one source of bigger renders is also NativeBaseProvider with custom theme.
I checked ractnavigation (v. 6) + native base with RN 0.66.4, 0.64.1, 0.69. Results are similar.
Anyway i can report two errors in alpha:

Slider:

Invariant Violation: [1587,"RCTView",51,{"onStartShouldSetResponder":true,"onMoveShouldSetResponder":true,"onStartShouldSetResponderCapture":true,"onMoveShouldSetResponderCapture":true,"onResponderGrant":true,"onResponderRej
ect":true,"onResponderRelease":true,"onResponderStart":true,"onResponderMove":true,"onResponderEnd":true,"onResponderTerminate":true,"onResponderTerminationRequest":true,"borderRadius":9999,"zIndex":999,"alignItems":"center","justif
yContent":"center","backgroundColor":-1,"position":"absolute","width":24,"height":24,"left":"0%","transform":[{"translateX":"<<NaN>>"},{"scale":1}]}] is not usable as a native method argument

Something is wrong with sizes. I mean app no longer takes full screen. I have margins from bottom (bigger) and top (smaller). Unfortunately I can't debug it in my work time so i have to leave it here.

I hope it helps! GL with improving this great project!

Hola folks!! I’ve some good news for you guys 🎉 As you know, we were working on fixing the performance issues with NativeBase. Here is an update. We have an alpha version out that provides you with better runtime caching increasing your app performance by 5-6 times on subsequent renders. You can also generate a pre-resolved theme style at build time using the newly released babel plugin @native-base/babel-plugin which increases your app's performance by 2-3 times in first render and 5-6 times in subsequent renders.
Steps for getting it up and running:
yarn add<EMAIL_ADDRESS>
yarn add -D @native-base/babel-plugin

Now add the native-base babel plugin in your -
babel.config.js:
module.exports = function (api) {
  api.cache(true);
  return {
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
  };
};

or .babelrc:
{
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
}

Edit: Last step is to add rm -rf .native-base in your dev script.
Something like this:
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "other-scripts":"yarn something",
    "dev": "rm -rf .native-base && yarn start",
  }

Try running your Apps now and let us know your feedback.

Note: This is still in alpha stage so might have some issues with particular components.

I have used this plugin and still, and the performance is still not good). It's too slow when switching between screens. I really liked this library and build a 70% app with this. But due to this problem, I have to rewrite the the app.

Hola folks!! I’ve some good news for you guys 🎉 As you know, we were working on fixing the performance issues with NativeBase. Here is an update. We have an alpha version out that provides you with better runtime caching increasing your app performance by 5-6 times on subsequent renders. You can also generate a pre-resolved theme style at build time using the newly released babel plugin @native-base/babel-plugin which increases your app's performance by 2-3 times in first render and 5-6 times in subsequent renders.
Steps for getting it up and running:
yarn add<EMAIL_ADDRESS>
yarn add -D @native-base/babel-plugin

Now add the native-base babel plugin in your -
babel.config.js:
module.exports = function (api) {
  api.cache(true);
  return {
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
  };
};

or .babelrc:
{
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
}

Edit: Last step is to add rm -rf .native-base in your dev script.
Something like this:
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "other-scripts":"yarn something",
    "dev": "rm -rf .native-base && yarn start",
  }

Try running your Apps now and let us know your feedback.

Note: This is still in alpha stage so might have some issues with particular components.

I used this plugin and the performance is not good enough. Hope you could fix it soon

[...] first render of page with search and 25 mock results (2 small images, and some text in each of them) takes around 1,5 -2 seconds (From pressable click to navigation to page. Without NativeBase it's 0.3-0.5 s). With bigger pages results are even worse.

This is pretty discouraging. Was about to move a project over to NativeBase, but don't see how I can justify that with these kind of numbers 😬

I also found performance problems that are somewhat intensified by using nested navigation (https://reactnavigation.org/). I'm also using RN 0.69. I started building large project with it but will have to rewrite it all with my team :( since performance is not good enough for client.
Anyway. I installed the alpha version and (with rm -rf node_modules/) started my app on android. Performance is better but still first render of page with search and 25 mock results (2 small images, and some text in each of them) takes around 1,5 -2 seconds (From pressable click to navigation to page. Without NativeBase it's 0.3-0.5 s). With bigger pages results are even worse.
The one source of bigger renders is also NativeBaseProvider with custom theme. I checked ractnavigation (v. 6) + native base with RN 0.66.4, 0.64.1, 0.69. Results are similar.
Anyway i can report two errors in alpha:

Slider:

Invariant Violation: [1587,"RCTView",51,{"onStartShouldSetResponder":true,"onMoveShouldSetResponder":true,"onStartShouldSetResponderCapture":true,"onMoveShouldSetResponderCapture":true,"onResponderGrant":true,"onResponderRej
ect":true,"onResponderRelease":true,"onResponderStart":true,"onResponderMove":true,"onResponderEnd":true,"onResponderTerminate":true,"onResponderTerminationRequest":true,"borderRadius":9999,"zIndex":999,"alignItems":"center","justif
yContent":"center","backgroundColor":-1,"position":"absolute","width":24,"height":24,"left":"0%","transform":[{"translateX":"<<NaN>>"},{"scale":1}]}] is not usable as a native method argument

Something is wrong with sizes. I mean app no longer takes full screen. I have margins from bottom (bigger) and top (smaller). Unfortunately I can't debug it in my work time so i have to leave it here.

I hope it helps! GL with improving this great project!

Hey @maciejduda1, Thanks for reporting the issues we are looking into this. Also, it would be really helpful if you can share the mock screens code in a codesandbox or expo snack.

Hola folks!! I’ve some good news for you guys 🎉 As you know, we were working on fixing the performance issues with NativeBase. Here is an update. We have an alpha version out that provides you with better runtime caching increasing your app performance by 5-6 times on subsequent renders. You can also generate a pre-resolved theme style at build time using the newly released babel plugin @native-base/babel-plugin which increases your app's performance by 2-3 times in first render and 5-6 times in subsequent renders.
Steps for getting it up and running:
yarn add<EMAIL_ADDRESS>
yarn add -D @native-base/babel-plugin

Now add the native-base babel plugin in your -
babel.config.js:
module.exports = function (api) {
  api.cache(true);
  return {
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
  };
};

or .babelrc:
{
    presets: [...YOUR_APP_PRESETS],
    plugins: ["@native-base/babel-plugin",...YOUR_OTHER_PLUGINS],
}

Edit: Last step is to add rm -rf .native-base in your dev script.
Something like this:
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "other-scripts":"yarn something",
    "dev": "rm -rf .native-base && yarn start",
  }

Try running your Apps now and let us know your feedback.

Note: This is still in alpha stage so might have some issues with particular components.

I used this plugin and the performance is not good enough. Hope you could fix it soon

Hey @mohammedraoof , can you please quantify the results? Also share some code sample of your codebase so that I can understand if the babel plugin is missing something or not.

@Audrey-Ann @arryanggaputra thanks for your patience, we have fixed the babel plugin for ios and android issues in @native-base/babel-plugin version 1.0.9. But it led us to find that, the babel config is treated differently by different bundlers that is why we had to introduce a new caching folder .native-base that stores the data that the babel plugin requires to function as intended. This in turn adds one more step to the babel plugin setup. Now you have to clear this cache folder every time you run a dev build else your resolved style map will keep on increasing in size. Not sure if it makes much sense without the whole context of how we are resolving the theme at build time. But all you have to do more is to add rm -rf .native-base in your dev script.
Something like this:
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "other-scripts":"yarn something",
    "dev": "rm -rf .native-base && yarn start",
  }

If you still face the issues please try deleting your node_modules and reinstalling the deps. Let me know even after that if the issue still persists.

Hi @rayan1810 :) I unfortunately ran into the same issues like mentioned before after upgrading to 1.0.9 :(

I'm getting these 2 errors after updating to 3.5.0-alpha.7:
 ERROR  Invariant Violation: [217,"RCTText",1,{"color":4278467120,"fontWeight":"400","fontSize":null,"lineHeight":"<<NaN>>","fontFamily":null,"marginTop":64,"fontStyle":"normal","accessible":true,"allowFontScaling":true,"ellipsizeMode":"tail","isHighlighted":false,"selectionColor":null}] is not usable as a native method argument

This error is located at:
    in RCTText (at Text.js:174)
    in Text (at makeStyledComponent.tsx:20)

and
 ERROR  Error: Exception in HostFunction: Malformed calls from JS: field sizes are different.

[[56,56],[5,5],[[219,"RCTRawText",1,{"text":"Be first to see new listings,\nwherever you are"}]],1899]

This error is located at:
    in RCTText (at Text.js:174)
    in Text (at makeStyledComponent.tsx:20)

Hey @sregg, It would be great if you can share the snack link or code snippet to reproduce the issue.

@ankit-tailor here's where the 2nd Text is rendered:
<Text variant="header" mt={16} tx={item.text} lineHeight="md" />

Text is our custom Text component that wraps NB's Text and add i18n capabilities with the tx prop:
export function Text(props: TextProps) {
  // grab the props
  const { preset, tx, txOptions, text, children, ...rest } = props;

  // figure out which content to use
  const i18nText = tx && translate(tx, txOptions);
  const content = i18nText || text || children;

  return (
    <NBText variant={preset} {...rest}>
      {content}
    </NBText>
  );

Variant "header" is defined in extendTheme() like so:
header: {
  fontSize: 20,
  fontWeight: 'bold',
},

I hope that helps.

Hey @sregg, Thanks for reporting the issue. I was able to reproduce the issue. Seems like typography tokens are not getting resolved. We'll fix it.

@Audrey-Ann @arryanggaputra
TypeError: /Users/oct4pie/nativebase/test/App.js: Cannot read properties of undefined (reading 'name')
I fixed the issue by finding this function in<EMAIL_ADDRESS>(line 192-196 for me):
attrs.map(function (attr) {
  if (["colorScheme", "variant", "size"].includes(attr.name.name)) {
    componentAttrs[attr.name.name] = attr.value.value;
  }
});

and nested the inner if-statement function in another if-statement:
attrs.map(function (attr) {
  if (attr.name) {
    if (["colorScheme", "variant", "size"].includes(attr.name.name)) {
      componentAttrs[attr.name.name] = attr.value.value;
    }
  }
});

That solved the error, but I still find my app to be slow compared to plain react-native.
Even the simple animations lag and get stuck even though I am rendering very few times.
Anyway, thank you @rayan1810 and all the contributors trying to fix this problem.

Any new news ?

If you want a performance boost for your most expensive screens/components without completely stripping native-base from your project then the answer from @foyarash is the way to go. I don't have quantifiable results but I can say it made our app a shit load faster

regarding performance issues with nested navigation, adding component freezing makes a significant improvement in performance. : https://github.com/software-mansion/react-freeze

We followed @foyarash's comment and replaced our Button and Pressable with custom ones and our app's performance improved a lot.
In a Reassure test, we saw a render time decrease of 47% and in a low end Android device (e.g. Pixel 3), the improvement is quite visible:
Before
https://user-images.githubusercontent.com/1479283/192355347-ddcb636f-9736-4ba9-9ba4-67b8d56aa198.mov
After
https://user-images.githubusercontent.com/1479283/192355560-320582fa-c287-44c5-a977-c30b09c956c2.mov

Hi @rayan1810, any update on this?

Any updates?

Native base is too much slow,
during network call native base use all all the resource of JS thread. and you could not do anything once the network call end then your actions works

Any updates on that, forwarding refs are killing native base performance?

Still the biggest blocker to using native-base throughout an entire application. On lists of any sufficient length, it is a night and day difference.

I have no hope to solve this GENERAL issue. I prefer to remove NB.

I have lost hope too.
Almost a year later; still no progress made on this critical issue that essentially makes it unusable in production.
I only wish we had some visibility on the progress here, so it doesn't feel like it was abandoned.

I've already removed NB from the whole codebase and rewritten the whole project...
A month of work wasted and I'm glad it doesn't took longer than a month...

Same here, we're going to move to chackra

Same here, we're going to move to chackra

Chackra is AWESOME, but they don't support react native yet, do they?

If your project is going to support react 18+ and you also need web components go for tamagui. Super quick and easy to understand.
The documentation was a bit outdated a month ago but you can integrate it easily to your project from boilerplate you can create with cmd.
Unfortunatelly I can't use it because my project is based on few libraries that not support react 18 yet...
So I've ended up creating one custom universal UI component. Its basically one FlexBox component (div or view) that I am using to build every other component I can imagine...
It use tailwind for web and stylesheet for RN.
My web went from 22 pagespeed points to 93 and also mobile apps are significantly more responsive and quicker...

Whatever library you move to, make sure you don't use components with forwardRef many times on the same screen. Otherwise you will face the same performance problem as with NativeBase. I moved to dripsy, but only use their theme provider, I make all my own components.

I'd like to note that native-base import cost is very expensive !  619k in my case (in each file I used native base)
So I believe if this was optimized, the application should get smoother, because native base is imported in every react native screen or component!
Any suggestion on how to optimize it?

Hey folks, We know it's been a long time since any update on this issue and we are sorry for the delay in the communication. We were working on this issue for a long time and were able to bring significant improvements, but we soon realized that it was not enough. And that it comes with a lot of baggage from v3.4. Since it is not a permanent solution we decided to pause it indefinitely now (i.e. v3.5).
We are working on a new solution that may turn into v4. That keeps performance as a first-class citizen and is ready to compromise on some fronts to do so. We are also aiming at a Preview release for the community to use by 15th December 2022 🤞.

We are working on a new solution that may turn into v4. That keeps performance as a first-class citizen and is ready to compromise on some fronts to do so. We are also aiming at a Preview release for the community to use by 15th December 2022 🤞.

This is great news and my team is really looking forward to trying out the new release. Any update on how the preview release of v4 is coming? Are you still on schedule for tomorrow (Dec 15th)? We're just trying to get a pulse on what to hope for.

We are working on a new solution that may turn into v4. That keeps performance as a first-class citizen and is ready to compromise on some fronts to do so. We are also aiming at a Preview release for the community to use by 15th December 2022 🤞.

This is great news and my team is really looking forward to trying out the new release. Any update on how the preview release of v4 is coming? Are you still on schedule for tomorrow (Dec 15th)? We're just trying to get a pulse on what to hope for.

Any news ? waiting for trying this out

< We are also aiming at a Preview release for the community to use by 15th December 2022 🤞.
Its 20th December 2022 Now, and we all waiting for the performance fix, we have projects ready to be published, Please keep us updated.

Hey folks, We know it's been a long time since any update on this issue and we are sorry for the delay in the communication. We were working on this issue for a long time and were able to bring significant improvements, but we soon realized that it was not enough. And that it comes with a lot of baggage from v3.4. Since it is not a permanent solution we decided to pause it indefinitely now (i.e. v3.5).
We are working on a new solution that may turn into v4. That keeps performance as a first-class citizen and is ready to compromise on some fronts to do so. We are also aiming at a Preview release for the community to use by 15th December 2022 🤞.

Its 20th December 2022 Now, and we all waiting for the performance fix, we have projects ready to be published, Please keep us updated.

@codeCleanDev I'm sure they would be more than happy for any contributions you would be able to make. :) It's a free and open source community effort, after all. We are all very grateful that they have so far chosen to freely share their hard work with the world.

@codeCleanDev I'm sure they would be more than happy for any contributions you would be able to make. :) It's a free and open source community effort, after all. We are all very grateful that they have so far chosen to freely share their hard work with the world.

I appreciate this comment and have considered contributing. It's certainly not fair to make demands of an open source project without being willing to do the work yourself.
At this point we're still in the decision phase of whether or not we will even be using Native Base and our decision lands largely on what happens in this thread. The lack of communication from the maintainers does not lend confidence to the sustainability of the project even if we did decide to contribute. It doesn't make sense to contribute to a failing project when there are other up and coming projects that seem to be getting much more attention (i.e. Tamagui).

Yeah for adding my 2c. We took a project from NBv2 to NBv3 as part of making sure all dependencies were upgraded. This seemed great until we noticed the performance hit.
It became very apparent when we had NBv2 / NBv3 builds side by side, so we found this thread and read through all the discoveries and test fixes of v3.5.
Then we saw the discussion of 4.0 and set an internal deadline to revisit on Dec 15. Which came and went - that is fine in the scope of things - I understand things change. However, we are hitting tough discussions which basically boil down to:

revert back to NBv2 (less of a performance hit).
wait for NBv4 and hope (resolves performance hit).
leave NB for alternative (Tamagui for example has performance as prime pillar)

So yeah in short - I'm waiting for any news either.

Yeah for adding my 2c. We took a project from NBv2 to NBv3 as part of making sure all dependencies were upgraded. This seemed great until we noticed the performance hit.
It became very apparent when we had NBv2 / NBv3 builds side by side, so we found this thread and read through all the discoveries and test fixes of v3.5.
Then we saw the discussion of 4.0 and set an internal deadline to revisit on Dec 15. Which came and went - that is fine in the scope of things - I understand things change. However, we are hitting tough discussions which basically boil down to:

revert back to NBv2 (less of a performance hit).
wait for NBv4 and hope (resolves performance hit).
leave NB for alternative (Tamagui for example has performance as prime pillar)

So yeah in short - I'm waiting for any news as well.

same here

Yeah for adding my 2c. We took a project from NBv2 to NBv3 as part of making sure all dependencies were upgraded. This seemed great until we noticed the performance hit.
It became very apparent when we had NBv2 / NBv3 builds side by side, so we found this thread and read through all the discoveries and test fixes of v3.5.
Then we saw the discussion of 4.0 and set an internal deadline to revisit on Dec 15. Which came and went - that is fine in the scope of things - I understand things change. However, we are hitting tough discussions which basically boil down to:

revert back to NBv2 (less of a performance hit).
wait for NBv4 and hope (resolves performance hit).
leave NB for alternative (Tamagui for example has performance as prime pillar)

So yeah in short - I'm waiting for any news as well.

Hey, i advise you to consider the 3rd option as i will do, AGAIN the said it will be out is second week of January 2023.

Hey folks, We know it's been a long time since any update on this issue and we are sorry for the delay in the communication. We were working on this issue for a long time and were able to bring significant improvements, but we soon realized that it was not enough. And that it comes with a lot of baggage from v3.4. Since it is not a permanent solution we decided to pause it indefinitely now (i.e. v3.5).
We are working on a new solution that may turn into v4. That keeps performance as a first-class citizen and is ready to compromise on some fronts to do so. We are also aiming at a Preview release for the community to use by 15th December 2022 🤞.

Sorry for the not so constructive "how's it going" type of comments, but still - do you have any update regarding v4 to share?
Let me/us know if there is anything we can help with!

this performance issue from spesific component or the core?

@chris-chapin We experienced similar issues. This happens when the React Native render loop is swamped, which easily happens when you have many Native Base components (or are doing other computationally expensive things).
You can analyze this issue with the React Profiler which is part of https://fbflipper.com/
One possible band-aid is to eliminate unnecessary renders by memoizing as much as possible.

Any updates on this topic? We're currently rolling out our production app using Native-Base. Performance is not good.

Any updates on this topic? We're currently rolling out our production app using Native-Base. Performance is not good.

We officially switched to Tamagui with Vercel and so far the results are excellent. That project is seeing a high level of support and I would highly recommend it. Very active Discord where they are actively answering questions and giving support. We're not yet in production (shooting for end of February), but the early performance tests and the flexibility of the design system have been impressive.
Not sure what's going on with Native Base, but the lack of communication here seems to show that they aren't very active or simply don't have the support to continue moving things forward in a meaningful way. Would love to see that turn around, but with all the people here asking how they can help with no response from the maintainers isn't encouraging. My best guess is that Native Base is just swimming in too much tech debt and needs a complete rebuild to fix the performance issues which is taking or will take much more time than originally anticipated.

@vasafix Does it happen with any 3.x version?
I am experiencing an issue with 3.0.6 in Android: the more Native Base components are rendered the slower further rendering performance (i.e. when switching between visible app components). Each time I create and render a component including Native Base components I see more visible delays before my component starts to interact (run useEffect callback on mount). Seems like something is blocking event loop.
I don't see any performance issues if I switch to React Native components.
I thought that these issues might be related.

same issue, when i navigate to screen that contain FormControl (or native-base component) the transition like delayed for a few ms before redirection.
the difference is so visible with other screens that redirect instantly after the button is clicked.
but when i remove FormControl the issue was gone
is there any solution?

Yeah for adding my 2c. We took a project from NBv2 to NBv3 as part of making sure all dependencies were upgraded. This seemed great until we noticed the performance hit.
It became very apparent when we had NBv2 / NBv3 builds side by side, so we found this thread and read through all the discoveries and test fixes of v3.5.
Then we saw the discussion of 4.0 and set an internal deadline to revisit on Dec 15. Which came and went - that is fine in the scope of things - I understand things change. However, we are hitting tough discussions which basically boil down to:

revert back to NBv2 (less of a performance hit).
wait for NBv4 and hope (resolves performance hit).
leave NB for alternative (Tamagui for example has performance as prime pillar)

So yeah in short - I'm waiting for any news as well.

Hey, i advise you to go with the 3rd option for time saving as i will do, AGAIN the said it will be out is second week of January 2023.

it's already 3rd weeks of january, is there any update?

@rayan1810 here is a simple snack example that demonstrates the performance issue with buttons on Android. I hope it can be used to test the latest improvements that you're working on.
https://snack.expo.dev/@zilhk/native-base-perf?platform=web
To see issue please run the app with ExpoGo on a low end Android device.
The app shows a list of buttons, clicking on them adds a new line of text displayed below.
The "Switch" button makes the app switch between Native Base and React Native buttons.
The "Clear" button clears the text.
Using the Native Base button the app is very sluggish on my low end Android, but when switching to React Native it runs smoothly.

@rayan1810 here is a simple snack example that demonstrates the performance issue with buttons on Android. I hope it can be used to test the latest improvements that you're working on.
https://snack.expo.dev/@zilhk/native-base-perf?platform=web
To see issue please run the app with ExpoGo on a low end Android device.
The app shows a list of buttons, clicking on them adds a new line of text displayed below. The "Switch" button makes the app switch between Native Base and React Native buttons. The "Clear" button clears the text.
When using the Native Base button the app is very sluggish on my low end Android, but when switching to React Native it runs smoothly.

i can see in Appetize android too, it's too obvious.
i suggest using react-native-gesture-handler for Button and Touchable

Twitter update on 2023-01-23 from Nativebase's @sanketsahu
Here's the thread unroll, for your convenience:

NativeBase update: We realize we haven't been communicating well about our updates. Thank you for your patience. We're working hard to build a robust & performant UI library for the next update.
The current state: We've identified some issues in the current version, including performance issues & difficulty in maintaining the library.
How we're fixing it: We're addressing performance by rebuilding parts of NativeBase & precompiling styles during build time.
We're also splitting the library into 3 distinct libraries:
• A universal CSS-in-JS lib
• A library for accessibility
• A component library
We're also working on an experimental codemod to transpile the existing codebase to use the new libraries. Our goal is to have versions ready by mid-February.
Our long-term plans: We'll maintain the 3 libraries, and the community help would be greatly appreciated.
We will have a transparent roadmap from now on.
We'll add more components, extend the library with features & adhere to web standards without reinventing things.
When to expect the new libraries: We're starting the rollout towards the end of January over 2-3 weeks.
Thank you for your support and we'll be sure to deliver more frequent updates and quality work from the core team of NativeBase.

@sanketsahu is it about NativeBase or Gluestack (website)?
I noticed that for almost 2 months there was no active development of NativeBase, but instead NativeBase team was working on Gluestack.
Taking your Tweet about 3 distinct libraries, I believe you were talking about these libraries (correct me if I'm wrong):

https://github.com/gluestack/dank-style - A library that allows you to use CSS in your React and React Native projects with a modern, powerful and flexible way. dank-style allows you to write CSS using JavaScript, which enables you to take advantage of the power and expressiveness of both languages. With its simple and intuitive API, you can easily create dynamic styles, responsive design, and handle themes for your applications.
https://github.com/gluestack/react-native-aria - A library of React Hooks for React-Native (Android/iOS/web) to provide accessible UI primitives for a design system.
https://github.com/gluestack/ui - gluestack/ui provides a collection of accessible, customizable and reusable components for building user interfaces with React And React Native. (dev repo seems to be this one?)

If that's the case, I have several follow-up questions:

Does it mean that NativeBase repository is going to be archived or do you plan to support this repository after Gluestack is released?
Will it be too different from NativeBase? I.e. how hard will it be for NativeBase users to migrate to Gluestack UI?
Will it be possible to use Gluestack UI without other Gluestack components?
Will Gluestack UI performance be improved and compatible to Tamagui in alpha release or is it a plan for future releases? I just received an email noting that so far A basic version of a UI library for gluestack is made, so it's not clear what features a basic version includes and what are the benchmarks if compared to other libraries.

I know that's too many questions in a single comment, so if you can share any information about any of the above questions it will be helpful. Thank you :smile:

Twitter update on 2023-01-23 from Nativebase's @sanketsahu
Here's the thread unroll, for your convenience:

NativeBase update: We realize we haven't been communicating well about our updates. Thank you for your patience. We're working hard to build a robust & performant UI library for the next update.
The current state: We've identified some issues in the current version, including performance issues & difficulty in maintaining the library.
How we're fixing it: We're addressing performance by rebuilding parts of NativeBase & precompiling styles during build time.
We're also splitting the library into 3 distinct libraries:
• A universal CSS-in-JS lib
• A library for accessibility
• A component library
We're also working on an experimental codemod to transpile the existing codebase to use the new libraries. Our goal is to have versions ready by mid-February.
Our long-term plans: We'll maintain the 3 libraries, and the community help would be greatly appreciated.
We will have a transparent roadmap from now on.
We'll add more components, extend the library with features & adhere to web standards without reinventing things.
When to expect the new libraries: We're starting the rollout towards the end of January over 2-3 weeks.
Thank you for your support and we'll be sure to deliver more frequent updates and quality work from the core team of NativeBase.

Still not an update ?

Thanks for all the patience, everyone! Here is the update:

Releasing a Universal & Performant Styling library later today or, max, tomorrow.
Releasing the alpha version of the new UI library next week.

@porunov's questions are on the top of my mind now after that response. It sounds like the Gluestack investigation above may be right. So instead of hoping for a NBv4 for performance - we may get an entire new library?
That really changes our internal discussions if so, since it then doesn't become a matter of NBv3 -> NBv4, but it becomes a discussion of NBv3 -> Gluestack or NBv3 -> Tamagui.
Which then I guess technically makes this issue "no fix", if the resolution is an entirely different library.

@iBotPeaches is completely right; if it's an entirely new library and I can't reuse what was done so far using NBv3 I think I will do myself a favor and finally take the time to switch to tamagui.
Not trying to be rude or anything, but after a whole year of patiently waiting and still believing, an entire switch to a new library that would require a rewrite of our codebase would just be a huge stab.

@pierroo @iBotPeaches I understand what you're saying, I would like to support you and everyone else facing this issue, but a few API changes are needed for the performance fix. We would have called the new library NativeBase v4, but we are making sure that the library works well everywhere and not just on mobile platforms, and that's why the name change.

We have a new styling library that solves a lot of performance issues of NativeBase!
It's called Dank! We have started testing it internally extensively. It's in alpha right now.
https://dank.style/ (alpha version)
We are building a full-blown library on top of Dank that will be the successor of NativeBase. We will provide a migration guide later too. We have ported a lot of components; we will update you soon!
Thanks for all the patience, and thanks for being so supportive!  🤍

Also, answering @porunov's question:

Does it mean that NativeBase repository is going to be archived or do you plan to support this repository after Gluestack is released?

We will provide the migration guide and help people move to gluestack-ui. Also, gluestack is a fullstack framework while gluestack-ui is the UI library.

Will it be too different from NativeBase? I.e. how hard will it be for NativeBase users to migrate to Gluestack UI?

It would be similar to NativeBase. We will provide migration guides.

Will it be possible to use Gluestack UI without other Gluestack components?

Yes, gluestack-ui can be used in any React / Next or React Native projects. There is no lock-in, it will be open-source and it will be the successor of NativeBase (better maintained, performant and reliable backed by a company & a group of contributors).

Will Gluestack UI performance be improved and compatible to Tamagui in the alpha release or is it a plan for future releases? I just received an email noting that so far A basic version of a UI library for gluestack is made, so it's not clear what features a basic version includes and what are the benchmarks if compared to other libraries.

We have run the benchmark, and we are getting great results compared to other libraries. We don't want the comparison with other libraries to be the ultimate scoring system. It doesn't give the full picture of any library. There are other important metrics too. Also, we may go wrong in how we run the benchmark, we may end up with selection bias too (unintentionally).

I suggest a way to test the performance is to build real examples, create complex pages and native screens with a large number of elements, and test with Lighthouse and PageSpeed Insights. For eg: we are getting a 99 or 100 score on our docs website built with Dank.
Check this page for more: https://dank.style/docs/overview/performance
We are here to help you!

Also, answering @porunov's question:

Does it mean that NativeBase repository is going to be archived or do you plan to support this repository after Gluestack is released?

We will provide the migration guide and help people move to gluestack-ui. Also, gluestack is a fullstack framework while gluestack-ui is the UI library.

Will it be too different from NativeBase? I.e. how hard will it be for NativeBase users to migrate to Gluestack UI?

It would be similar to NativeBase. We will provide migration guides.

Will it be possible to use Gluestack UI without other Gluestack components?

Yes, gluestack-ui can be used in any React / Next or React Native projects. There is no lock-in, it will be open-source and it will be the successor of NativeBase (better maintained, performant and reliable backed by a company & a group of contributors).

Will Gluestack UI performance be improved and compatible to Tamagui in the alpha release or is it a plan for future releases? I just received an email noting that so far A basic version of a UI library for gluestack is made, so it's not clear what features a basic version includes and what are the benchmarks if compared to other libraries.

We have run the benchmark, and we are getting great results compared to other libraries. We don't want the comparison with other libraries to be the ultimate scoring system. It doesn't give the full picture of any library. There are other important metrics too. Also, we may go wrong in how we run the benchmark, we may end up with selection bias too (unintentionally).

I suggest a way to test the performance is to build real examples, create complex pages and native screens with a large number of elements, and test with Lighthouse and PageSpeed Insights. For eg: we are getting a 99 or 100 score on our docs website built with Dank.
Check this page for more: https://dank.style/docs/overview/performance
We are here to help you!

Thanks a lot for such a detailed answer! This is definitely very promising and I'm excited to try that out!
Great to hear these news and congratulations on the alpha release 👏 😀

Also, answering @porunov's question:

Does it mean that NativeBase repository is going to be archived or do you plan to support this repository after Gluestack is released?

We will provide the migration guide and help people move to gluestack-ui. Also, gluestack is a fullstack framework while gluestack-ui is the UI library.

Will it be too different from NativeBase? I.e. how hard will it be for NativeBase users to migrate to Gluestack UI?

It would be similar to NativeBase. We will provide migration guides.

Will it be possible to use Gluestack UI without other Gluestack components?

Yes, gluestack-ui can be used in any React / Next or React Native projects. There is no lock-in, it will be open-source and it will be the successor of NativeBase (better maintained, performant and reliable backed by a company & a group of contributors).

Will Gluestack UI performance be improved and compatible to Tamagui in the alpha release or is it a plan for future releases? I just received an email noting that so far A basic version of a UI library for gluestack is made, so it's not clear what features a basic version includes and what are the benchmarks if compared to other libraries.

We have run the benchmark, and we are getting great results compared to other libraries. We don't want the comparison with other libraries to be the ultimate scoring system. It doesn't give the full picture of any library. There are other important metrics too. Also, we may go wrong in how we run the benchmark, we may end up with selection bias too (unintentionally).

I suggest a way to test the performance is to build real examples, create complex pages and native screens with a large number of elements, and test with Lighthouse and PageSpeed Insights. For eg: we are getting a 99 or 100 score on our docs website built with Dank.

Check this page for more: https://dank.style/docs/overview/performance

We are here to help you!

I see on the website that Dank supports multiple themes, however, I don't see any example of how theming works. Our app currently supports multiple themes like warm, cool, light, dark, etc. Would this be possible using Dank?

@ealmiladi You can replace the dank config and pass the one you want to  during the runtime. This should work, but we haven't tried replacing the entire theme on the fly yet! We are using multiple providers on dank.style, one for the root and another for the examples.
Dynamically updating the dank theme/config may add some runtime overhead, and the babel precompilation of styles wouldn't work either. In most cases, it should just be fine! But if you're looking for that extra performance, we would need to add a feature in the babel-plugin to support multiple themes.

I wanted to point out that the issue still exists in native-base version 3.4.28 with React Native 0.71.3, I recently migrated from native-base version 2.15.2 and experience the significant hit in performance, mainly with android. I agree this library is not production viable at the moment.

@FusionReaction Based on official communications from the people working on Native Base I don't think version 3.x will ever be updated to address those performance issues unfortunately (see above replies from sanketsahu)

@obasille I mostly wanted to help point out the issue for anyone looking to update to native-base v3, which is a large overhaul since there is not a one to one component migration from v2 - v3. I would wait until gluestack-ui is ready or switch to another library.

@FusionReaction which library is stable and the performance is good right now? apart from tamagui

Pretty sad about the change to gluestick, have been a fan of NativeBase from the first version, working now in an app that is almost for production and we are having heavily issue in android performance :(

Pretty sad about the change to gluestick, have been a fan of NativeBase from the first version, working now in an app that is almost for production and we are having heavily issue in android performance :(

I share your sentiment. The prospect of transitioning to an entirely new framework entails significant time and financial investments, which is far from ideal. However, it seems that we may have no choice but to undertake this challenging process.

I wish I had read this thread earlier. We just released the alpha version of our app, but the performance on Android is unacceptable.

so，Is there a solution now？I ran into the same problem in version 3.4.28

There ought to be a warning in the README for NativeBase, and a link to alternatives such as https://gluestack.io with it's https://ui.gluestack.io and https://dank.style, and even https://tamagui.dev for good measure (even though it is a "competitor").

Do you guys think that this problem can be leveled by better performance of new React Native architecture?

@404-html no

Given this is an income generating library (sponsors + promoting GeekyAnts) it seems somewhat dishonest and misleading not to have this very clearly outlined in the docs and readme yet still having all of the marketing content up.
React navigation have an anti-pitch page which might be applicable here however given this issue seems to be unfixable and the company have jumped ship it may not be enough.

Looking at the gluestack-Ui docs, so far the API is trivially different from Nativebase. So even though there is a new package / different name they have are using the same awesome API. As far as I have seen, gluestack doesn't even come close to a rewrite if already using Native Base, it would just be a major version breaking change kind of migration.
I agree some official communication would be great around this.
I am personally excited about what GeekyAnts is doing with gluestack.

I really wouldn't say the API is trivially different - especially if you have made use of pseudo props and theming etc and if it native base touches almost every part of a large codebase (which is pretty common with utility first component libraries), it's also not even in beta yet.
I'm using @foyarash 's solution until I move to tamgui or plain react native

@Sid-Turner-Ellis I think that most (if not all) NB components are already memoized.
Button for example (see the last line):
https://github.com/GeekyAnts/NativeBase/blob/master/src/components/primitives/Button/Button.tsx

Yeah you're right - that probably didn't lead to much performance gain. I
did if for a few components and applied my own memo callback though which
may have helped in my case
On Mon, 8 May 2023 at 15:19, obasille @.***> wrote:

@Sid-Turner-Ellis https://github.com/Sid-Turner-Ellis I think that most
(if not all) NB components are already memoized.
Button for example (see the last line):
https://github.com/GeekyAnts/NativeBase/blob/master/src/components/primitives/Button/Button.tsx
—
Reply to this email directly, view it on GitHub
https://github.com/GeekyAnts/NativeBase/issues/4302#issuecomment-1537877057,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOWLSCZNVGNVZ5O2CLI5HUDXFCM7BANCNFSM5IBEQ55A
.
You are receiving this because you were mentioned.Message ID:
@.***>

Gents,
looks like alpha gluestack is available: https://ui.gluestack.io/

has anyone started using gluestack.io? Our App is already in production using native-base and we are planing to migrate it without completely removing native base.

The problem is that the issue wasn't handled at all. They just abandoned this project and moved to another one. That behavior is really irresponsible and because of that they won't have my support for their Gluestack project, even if it was the best UI lib out there. I mean who's guaranteeing you that they won't silently abandon that project either, like they did this one? We shouldn't support people like them, financially or in any other sense.
On another note: I managed to completely ditch native-base from my project and proceed using my own, custom implementation. Replacing native-base had to be as painless as possible, so I decided to have a similar API (for the utility props at least) as they have. For anyone who's interested in the implementation, I have created a test project and you can check it out here.

End of an era. Unsubscribing from this thread. We left for Tamagui. Took about ~30 billed hours for a migration off of NB to Tamagui.
I wish no ill will or toxic comments, but this did not play out in a positive light to us for how the situation was handled. So we felt it was best to move on.

First of all, I accept and own this issue. This was my fault in its entirety. We tried our level best to solve it, and we have worked day in and day out to fix the perf issue with the existing APIs but we couldn't.

The API in v3 was built so that it had to depend on the JS runtime, and it couldn't be swapped out with a build-time equivalent. So, a rewrite of the library and the migration to the existing project was necessary. For eg, in the initial design of NativeBase v3, we didn't consider using the $ prefix, which makes it easy to write the build-time optimizers, which we built with gluestack-style (aka dank.style).
The library had styles baked into it which made it hard to decouple it, and the only good way to write your own theme was to extend the base one
Third, the component library and the styling engine was coupled together, which made it unmaintainable.

Why did we abandon this project for another one?
We actually didn't! gluestack-ui / gluestack-style was named NativeBase v4 initially, but considering the number of necessary changes, we renamed it to something else.
Why should you trust the library authors any more?
We are literally trying our best. But it's up to you. In full transparency, about 20 engineers and designers are working full-time on gluestack since December 2022. Most of the work has gone into gluestack-ui and gluestack-style. We are building more projects on top of gluestack-ui at GeekyAnts. In fact, if you check gluestack.io and all the websites, they are all built with gluestack-ui.
And tamagui is a great project, and Nate is extremely talented! @iBotPeaches You have made the right choice! Sorry for the ~30 hours of extra billed hours. It wasn't our intention to waste your time - we're working our socks off here. Beyond the 30 hours, I've had my share of sleepless nights over this. My heartfelt wishes for your projects, and I hope for nothing but success for you.

First of all, I accept and own this issue. This was my fault in its entirety. We tried our level best to solve it, and we have worked day in and day out to fix the perf issue with the existing APIs but we couldn't.

The API in v3 was built so that it had to depend on the JS runtime, and it couldn't be swapped out with a build-time equivalent. So, a rewrite of the library and the migration to the existing project was necessary. For eg, in the initial design of NativeBase v3, we didn't consider using the $ prefix, which makes it easy to write the build-time optimizers, which we built with gluestack-style (aka dank.style).
The library had styles baked into it which made it hard to decouple it, and the only good way to write your own theme was to extend the base one
Third, the component library and the styling engine was coupled together, which made it unmaintainable.

Why did we abandon this project for another one? We actually didn't! gluestack-ui / gluestack-style was named NativeBase v4 initially, but considering the number of necessary changes, we renamed it to something else.
Why should you trust the library authors any more? We are literally trying our best. But it's up to you. In full transparency, about 20 engineers and designers are working full-time on gluestack since December 2022. Most of the work has gone into gluestack-ui and gluestack-style. We are building more projects on top of gluestack-ui at GeekyAnts. In fact, if you check gluestack.io and all the websites, they are all built with gluestack-ui.
And tamagui is a great project, and Nate is extremely talented! @iBotPeaches You have made the right choice! Sorry for the ~30 hours of extra billed hours. It wasn't our intention to waste your time - we're working our socks off here. Beyond the 30 hours, I've had my share of sleepless nights over this. My heartfelt wishes for your projects, and I hope for nothing but success for you.

That is fine, your reasons are on point. The only thing that you could've done better is be more transparent about that. A little warning or note in the Readme of the NativeBase project (something like: we're migrating to gluestack/dank.style) should've been sufficient. Or better yet: a warning about the migration and a link to a more detailed explanation about why you decided to do that.
I am sorry about not trusting you and calling you irresponsible, because you're not irresponsible. It's just that I wasn't aware of what exactly is going on with this project.

@kapobajza Thanks for understanding! We have taken note of your feedback. We will update the content wherever necessary and be transparent going forward.

@gvanderclay Thanks for your kind words! The migration guide is on our list. We have written the initial version on Notion. We will share it as soon as we have a draft.

Thank goodness I read this before I started using it in my app I'm about to build. I think I'll go with pure RN or do you have a better UI library to suggest me?

@dimitrisoikonomou check out tamagui. It's super fast and sleek with sweet animation capabilities. Problem is it has a complex setup process and a seemingly incomplete documentation. I'm currently using it for my app and I have to do a lot of learning. It slows down the process in the beginning but it'll get faster the more you understand it. It's definitely worth checking out.

Thank goodness I read this before I started using it in my app I'm about to build. I think I'll go with pure RN or do you have a better UI library to suggest me?

You can also check ui.gluestack.io which is the successor of NativeBase with a focus on performance & DX!

Thank goodness I read this before I started using it in my app I'm about to build. I think I'll go with pure RN or do you have a better UI library to suggest me?

@dimitrisoikonomou You can also check ui.gluestack.io which is the successor of NativeBase with a focus on performance & DX!

@sanketsahu does it have the exact same features and setup as nativebase? Also, do you know the performance quality compared to tamagui?

@dondxniel We have more features than NativeBase. The API has changed a bit to have build time optimizations. You can find out more here: https://nativebase.io/blogs/road-ahead-with-gluestack-ui
The perf is similar to tamagui as we are doing the same thing. We will release the benchmark comparison in the coming days. The entire website is built using gluestack-ui.

That's nice to know. I'll check it out right away; thanks!

@dondxniel We have more features than NativeBase. The API has changed a bit to have build time optimizations. You can find out more here: https://nativebase.io/blogs/road-ahead-with-gluestack-ui
The perf is similar to tamagui as we are doing the same thing. We will release the benchmark comparison in the coming days. The entire website is built using gluestack-ui.

my android app facing the performance problem too.  and I take long time to find  out this issue from nativebase.
and  the  solution is to rewrite the app?

@jy1989 yep. it's very frustrating. there should have been a giant readme banner back in 2021 telling people that this library has serious performance issues. i replaced everything with my own primitive components that support utility props and have never looked back

@uen I found that this native base version "3.5.0-rc.7" has better performance. So I am currently using this version for the time being

Hi Everyone,
We have made @gluestack-ui/themed-native-base that will work as a drop-in replacement for native-base.
It shares the same API, styling, functionality as native-base. But internally it uses gluestack-ui, so you will notice a massive performance boost in your application (web and native).
Basically, you get the performance of gluestack-ui without changing your code base, you just need to change the imports (you can alias the imports).
The library is currently in beta (apart from minor styling and typing issues, it is stable), we would love for you to try it and report as many bugs/issues you can find, so we can release a more stable version .

@akash3gtm Are there plans to have it support the old native-base way of extending the theme types?
Or any other compatible way to use the same theme to declare theme types?
// Get the type of the CustomTheme
export type CustomThemeType = typeof theme;

// Extend the internal NativeBase Theme
declare module 'native-base' {
  interface ICustomTheme extends CustomThemeType {}
}

Hi @kylegwalsh ,
Yes we have plans to give 100% ts-support the same way we gave in native-base so all the typings come correct.
As soon as we are done with minor fixes and issues, we will release v1.0.0 soon with everything.

Thanks for the reply @akash3gtm! I attempted to replace all instances of native-base with the new gluestack package as an experiment, but ran into some issues getting it to render in my expo app.
There could be any number of confounding issues since native base was so engraved into my code (and I handled custom theming for different users), so I'll keep a lookout for v1.0.0 and try again once it's released!

Thanks for the reply @akash3gtm! I attempted to replace all instances of native-base with the new gluestack package as an experiment, but ran into some issues getting it to render in my expo app.
There could be any number of confounding issues since native base was so engraved into my code (and I handled custom theming for different users), so I'll keep a lookout for v1.0.0 and try again once it's released!

Hey @kylegwalsh ,
As of right now it should not break, but we have not tested it extensively on any large complex projects.
The projects we did test it on, were our native-base docs website that was made using native-base, some expo apps and react apps and some other 4-5 pages nextJS app.
If you could open an issue in the git repo @gluestack-ui/themed-native-base, and provide either an expo snack or code-sandbox, we would be able to see what is the error causing this.

Hi @akash3gtm, got it. I will give it a shot after finishing a few other priorities on my plate. It may be a bit difficult to boil it down into a snack because of the complexity of the application. It will probably take me several days of digging.
I even tried commenting out the entire app tree to just get a successful render and still saw the error (it seems that expo-router is erring when trying to require screens from other areas of the app that leverage gluestack components:
Uncaught Error: Requiring module "app\(interstitials)\_layout.tsx", which threw an exception: TypeError: Cannot read properties of undefined (reading 'colors')

Hi @kylegwalsh, would be more than happy to help you resolve the issue.
Whenever you have enough time, Please raise an issue in that repo, and we will help you get it all setup.

Hi @foyarash can you show me how to make  with space props? A bit lost in there


Increase linux vm capacity in flutter prod and try fleets

Increase by 25 in each pool.

completed.


Update ws module

Deals with vulnerability https://nodesecurity.io/advisories/550

Hi! Quick question on this update: does GTT spawn a WS server somewhere inside?

Not in general; it's a client.
There is some ws server code which acts as a proof-of-concept for talking to gtt-ui components, but this is not documented and will likely be deprecated in future (probably in favour of FIX API).


Linux support

Your bot closed my feature request!
I mean does this feature request really need further elaboration beyond its title?
Ok, I propose that you use Qt, distribute DEB packages and support other major package formats. Also provide a Snap! Ok, I hope I satisfied your bot now.

I am not affiliated with the team here, but you can use the query linux in:title to find that similar issues have been submitted, see #624, #563 and #504.

See also #2331.

Yea I'm going to close this as a dupe of the countless other issues we've already closed for the exact same ask. Please search before filing new issues.


Readme for pkg/signal, #11585

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "11585-2" git@github.com:VladimirAus/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

This will update the existing PR, so you do not need to open a new one.


Why two actions click outsite drag drop area and use jquery trigger click element outside are different?

Custom
Case 1: I use my mouse to click one area outside of drag and drop, and I see "sortable-selected" class in items are removed.
Case 2: Like case 1 but I use jquery to click to element A but "sortable-selected" can not be removed. In this case I want to do the same result as case 1.
Why??? and how to do case 2 like case 1.

The click has to bubble to the document object for it to deselect, but you can use Sortable.utils.deselect to deselect any or all of the selected elements whenever you want
https://github.com/SortableJS/Sortable/tree/master/plugins/MultiDrag#sortableutils


feat: add QuantityInput component

wip
#377 needs to be merged first because this PR here needs it validation functionality.

This looks great. I give it 1000 cabbage 🥬
I made some small changes to the style of the entered value/quantity indicators (as always), and replaced the error copies just to see if the ones indicated in the designs are clear enough. While doing that, I noticed the nit-pickiest thing: that the error message of the second QuantityInput (when the unit field is being validated) is not properly aligned like the rest. I wasn't sure what's causing it or how to fix it:

Regarding the transparent end border applied to the first field: this make the component look closer to the designs, but the solution is a bit hacky. In case there's not a better way to achieve creating that shared 1px border, it might be better to make the border visible instead.

P.S.
Its looks great, btw :)

While doing that, I noticed the nit-pickiest thing: that the error message of the second QuantityInput (when the unit field is being validated) is not properly aligned like the rest. I wasn't sure what's causing it or how to fix it:

Mh, that looks perfectly fine to me:

What browser are you using and does this also happen on other validation messages?

Regarding the transparent end border applied to the first field: this make the component look closer to the designs, but the solution is a bit hacky. In case there's not a better way to achieve creating that shared 1px border, it might be better to make the border visible instead.

I have to confess, I'm only aware of different bad solutions.:

The transparent border allows us to actually show 4 sides of red border in case of an error. But that means in the case of an error there is also a double border there.
What we did for the ToggleButton group is to just drop the right border for all but the rightmost button. Luckily that is almost imperceptible unless one knows exactly where one has to look when.
double border always is always consistent but also always a double border.


ValueError: unknown locale: en_IL on Ubuntu 18.04.1 LTS

I can not open spyder in anaconda at ubuntu 18. I tried the solutions in #4131 and #7051, but it didn't work.
What steps reproduce the problem?

I installed Anaconda for Python 2.7 on Ubuntu 18.04
Launch spyder
I get the following ValueError message regarding unknown locale: en_IL

XmbTextListToTextProperty result code -2
XmbTextListToTextProperty result code -2
XmbTextListToTextProperty result code -2
XmbTextListToTextProperty result code -2
XmbTextListToTextProperty result code -2
XmbTextListToTextProperty result code -2
XmbTextListToTextProperty result code -2
XmbTextListToTextProperty result code -2
Traceback (most recent call last):
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/app/mainwindow.py", line 3208, in main
    mainwindow = run_spyder(app, options, args)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/app/mainwindow.py", line 3084, in run_spyder
    main.setup()
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/app/mainwindow.py", line 1172, in setup
    self.setup_layout(default=False)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/app/mainwindow.py", line 1457, in setup_layout
    self.setup_default_layouts('default', settings)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/app/mainwindow.py", line 1633, in setup_default_layouts
    widget.toggle_view(True)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/plugins/ipythonconsole.py", line 725, in toggle_view
    self.create_new_client(give_focus=False)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/plugins/ipythonconsole.py", line 1046, in create_new_client
    self.connect_client_to_kernel(client, is_cython=is_cython)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/plugins/ipythonconsole.py", line 1074, in connect_client_to_kernel
    is_cython=is_cython)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/spyder/plugins/ipythonconsole.py", line 1509, in create_kernel_manager_and_kernel_client
    config=None, autorestart=True)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/traitlets/traitlets.py", line 958, in __new__
    inst.setup_instance(*args, **kwargs)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/traitlets/traitlets.py", line 986, in setup_instance
    super(HasTraits, self).setup_instance(*args, **kwargs)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/traitlets/traitlets.py", line 977, in setup_instance
    value.instance_init(self)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/traitlets/traitlets.py", line 1691, in instance_init
    self._resolve_classes()
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/traitlets/traitlets.py", line 1696, in _resolve_classes
    self.klass = self._resolve_string(self.klass)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/traitlets/traitlets.py", line 1507, in _resolve_string
    return import_item(string)
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/traitlets/utils/importstring.py", line 34, in import_item
    module = __import__(package, fromlist=[obj])
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/jupyter_client/session.py", line 61, in <module>
    from jupyter_client.jsonutil import extract_dates, squash_dates, date_default
  File "/home/ohm/anaconda2/lib/python2.7/site-packages/jupyter_client/jsonutil.py", line 28, in <module>
    datetime.strptime("1", "%d")
  File "/home/ohm/anaconda2/lib/python2.7/_strptime.py", line 274, in <module>
    _TimeRE_cache = TimeRE()
  File "/home/ohm/anaconda2/lib/python2.7/_strptime.py", line 192, in __init__
    self.locale_time = LocaleTime()
  File "/home/ohm/anaconda2/lib/python2.7/_strptime.py", line 70, in __init__
    self.lang = _getlang()
  File "/home/ohm/anaconda2/lib/python2.7/_strptime.py", line 29, in _getlang
    return locale.getlocale(locale.LC_TIME)
  File "/home/ohm/anaconda2/lib/python2.7/locale.py", line 564, in getlocale
    return _parse_localename(localename)
  File "/home/ohm/anaconda2/lib/python2.7/locale.py", line 477, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_IL

Versions

Spyder version: 3.2.8
Python version: 2.7.15
Qt version: 5.9.5
PyQt version: 5.9.2
Operating System name/version: Ubuntu 18.04.1 LTS

This is fixed in our latest version (3.3.0). Please update by opening a terminal and running there
conda update spyder

Experienced this with Spyder 3.3.1 , and python 2.7.15 . Ubuntu 18.04.
Workaround is to change to system to en_US.


[clusteragent/autoscaling] Use PodWatcher to update current replicas in status

What does this PR do?

Use PodWatcher to update current replica count in DatadogPodAutoscaler status  instead of Horizontal /scale sub-resource.
Motivation

If horizontal scaling has no changes/is not activated, the current replica count may be inaccurate. This change moves the logic to update the number of current replicas to the controller loop to ensure it is as up-to-date as possible.
Additional Notes

Possible Drawbacks / Trade-offs

During testing, sometimes some lag between when PodWatcher information is updated and when a scaling action happens exists. This can lead to a maximum of 5 min of inconsistent number of replicas being reported (info is fixed on next run of the controller loop).
~~There is currently duplicated logic between the controller and vertical controller to get the number of pods - would it make sense to combine these two to avoid calling podWatcher.GetPodsForOwner twice? The now duplicated logic:
https://github.com/DataDog/datadog-agent/blob/2f3053a37cbe4c1fc2327763f39e9bef1cac3ab1/pkg/clusteragent/autoscaling/workload/controller_vertical.go#L70-L84~~
Describe how to test/QA your changes

Run an autoscaling workload
Verify that the Current Replicas count in the status is updated after scaling actions (even if horizontal scaling is disabled)

/merge


 While actually the value is not 0 ;)

bot merge


Add the concept of a legal entity AND organization

On the OpenChain call 7 Aug 2017 we discussed the issue that larger companies may only have some organizations certified.  Ideally, the application would capture both the company and the organization and maintain the releationship between the two.
In the sort term, we plan on documenting both the organization and legal entity (e.g. company name) in the current organization signup in some standard format (e.g. Company / Organization).
In the future, we would like to have 2 text fields, a required company and an optional organization (or perhaps organization and sub-organization).  We could then use the relationships between organizations and companies to better group and display self-certifications.

Per comment from Shane, we may want to use a term "Program" rather than organization.  See https://wiki.linuxfoundation.org/openchain/specification-questions-and-answers#does-all-software-in-an-organization-need-to-be-covered-by-an-openchain-conforming-program-to-achieve-program-conformance

The specification consistently references a program being comforting as oppose to an organization. The FAQ referenced here was intended to further clarify that it is about a program.  The thinking was to allow an organization to claim a particular release could receive the conformance mark if it was reviewed under a conforming program.

@MarkGisi If we updated the self certification to include an optional "Program Name" when filling out the self certification, would that be consistent with the policy?
There are a number of UI design decisions we need to make:

Do we only allow one user per company and that user can specify multiple Programs or do we require one user to represent only one program?
If a single user can have survey responses for multiple programs, what is the UI to manage the multiple programs?
How do we display the certified program results?  This seems more straight forward - adding another column to the certified results table for Program and allow it to be blank.
What help text to we provide for "Program"?

@shanecoughlan will this impact the display of self-certified companies we display on the website?

Do we only allow one user per company and that user can specify multiple
Programs or do we require one user to represent only one program?

To allow one organization to register multiple programs would be consistent with the spec. I would imagine the Conformance team could support either i) one organization, one user who is allowed to register multiple programs or ii) one organization, multiple users, each of which could register one more programs. In both cases you are allowing a one to many relationship, that is, one organization to many programs. Both seem consistent and it would the the Conformance team's decision on which/how to support it. Option ii) seems more flexible but a bit more complicated.

If a single user can have survey responses for multiple programs, what is the
UI to manage the multiple programs?

IN this case yes. The system would maintain (Organization-id, Program-id) relationships. For example, company ABC, Inc. might have two programs, one for GA Products and another for Professional services. This would lead to two different conformance instances for ABC, Inc.:
(ABC, Inc., GA Products)
(ABC, Inc., Professional Services)
I think of the Organic Food analogy (e.g., General Mills; https://www.generalmills.com/Brands/organic-natural):
(General Mills, Annie's)
(General Mills, Cascadian Farm)
Although General Mills has many other product lines that are not organic.

How do we display the certified program results? This seems more straight forward -
adding another column to the certified results table for Program and allow it to be blank.

You would need to represent the one to many relationship (ABC, Inc, X) for a given organization. Perhaps another column might achieve that

What help to we provide for "Program"?

I am not sure I understand the question. Perhaps it is a matter of explaining that an organization can have more than one program (one to many) and that a give product release that references the conformance trademark must have been reviewed under one of the programs that is registered and satisfy the conformance criteria. We could use the Organic food analogy to explain this. Although I am not sure I answered the right question.

Hi @goneall. I don't see an immediate need for change. However, after implementation I believe our conformance team could discuss whether we need to illustrate the program conformance rather than only the overarching logo.
e.g.:
(ABC, Inc., GA Products)
(ABC, Inc., Professional Services)
The Organic Food analogy (e.g., General Mills; https://www.generalmills.com/Brands/organic-natural):
(General Mills, Annie's)
(General Mills, Cascadian Farm)

We should hold off working on this until a consensus is reached by the OpenChain work groups.


Create GCD.py

Fastest and Simple way to find Greatest Common Divisor using Euclid formula
Assigned Issue Number ?
#250
Language Opted ?
Python
Number of files added or updated ?
1
Name of these file ?
GCD.py
algo_ds_101 => Maths_And_Stats => Algebra => GCD => GCD.py
Checklist

[*] I've read the contribution guidelines.
[] I've referred the correct issue number.
[] I've fill up this entire template correctly.

Perfect Code 👏🏽
Thanks @AjinkyaSahu
Happy Contributing 🎉


No image shown in submissions table

In an ODK survey, no image is shown in the submissions table even though the image exists. This is part of a survey that collects an image. When clicking download attachments, the images are downloaded.

This form image is not stored in the image field but as village_picture: http://zambia.hotosm.org/omk/data/submissions/Zambia_Minigrid_Village_Survey_V02/a6ba2370-4432-43ff-9ff3-287228a0c541/data.json
Do you think we can instruct the users to set the image field as "image" in the form?

Do you think we can instruct the users to set the image field as "image" in the form?

That's a good catch. Thanks @willemarcel. You're probably right, we should provide documentation that it needs to be the image field. I'm not sure there is another way to grab the field type instead of the name but I think that makes sense.

I think it's better to set the image field. The users can add more than one image field, so it wouldn't solve the problem and it would be more complicated to handle.


feat: parrallel implementation

Timed:

Folder with 315 duplicates of a random .sql file called  test.sql -> SELECT * FROM test
sqruff lint  6.57s user 0.86s system 97% cpu 7.648 total
sqlfluff lint --dialect ansi  3.79s user 0.31s system 95% cpu 4.285 total

Is it possible that the changes don't actually parallelise the listing process? The run method for each iterator is updated but thei iterator still processes each file sequentially I think.
Perhaps we need to parallelise the ParallelRunner?


☂  Idiomatic conversions

[ ] T getSomeValue() that returns a private value T someValue with the same type and doesn't get any arguments can be converted to a Dart's getter T get someValue – potentially only under a config flag
[ ] void setSomeValue(T t) that gets a value of type T and returns void can be converted into a Dart's setter set someValue(T t) – potentially only under a config flag
[ ] get methods that only get a single argument can be converted to operator [] – potentially only under a config flag
[ ] put methods that only get two arguments can also be converted to operator []=. We still probably want to generate put because put usually returns the value in Java while []= returns void – potentially only under a config flag
[ ] equals method can overload operator == and hashCode can override the hash code getter.

More conversions that can make the code more idiomatic to Dart? Feel free to suggest.

Big +1 for doing the first two!
That would be similar to what Kotlin to Java interop does: https://kotlinlang.org/docs/java-interop.html#getters-and-setters

Big +1 for doing the first two!
That would be similar to what Kotlin to Java interop does: https://kotlinlang.org/docs/java-interop.html#getters-and-setters

Kotlin is doing some other conversions for operators as well but the documentation is somewhat vague about it: https://kotlinlang.org/docs/java-interop.html#operators
For example list[i] turns into list.get(i), and so on... (Similar to the other proposed conversions in this issue).


installation for nvcr images

I use the nvcr base image: nvcr.io/nvidia/pytorch:23.06-py3.
Pip install directly failed as follows.

Should I install from sources and how to set these variables below in setup.py for nvcr base image?

Thanks for your advice.

nvcr uses pytorch nightly versions so it's a bit hard to make sure the compiled CUDA wheels are compatible. causal-conv v1.1.1 should work with nvcr 23.12.

thanks.
installed succefully from source build with force build.


Add option to format output with Width param in lager_default_formatter

Width :: integer() | {left  | right | centre, integer()}
placeholders: date, time, message, sev, metadata and new placeholder blank::blank | {blank, string()} ignore Width param
example :

["[",{undef, "", [severity], {right, 10}},"]"] ->    if severity is error  print [     error]
["[",{undef, "", [severity], {left, 10}},"]"] ->      if severity is error  print [error     ]
["[",{undef, "", [severity], {centre, 10}},"]"] -> if severity is error  print [  error   ]
["[",{undef, "", [severity], 10},"]"] ->               if severity is error  print [error     ]
["[",{undef, "", [severity,{blank,"|"},severity], {left, 10}},"]"] ->   if severity is error  print [error     |error     ]
["[",{undef, "", [severity,"|",severity], {left, 10}},"]"] ->   if severity is error  print [error     |         error     ]

Interesting contribution. Thanks for the PR - the word width is misspelled in all of the test cases. Would you please fix that? Then I can run the tests locally and merge this if it all looks good.
Thanks.

All done

Yes, sorry. +Some test for bad arguments

OK, looks good, tests pass, dialyzer doesn't complain.


Compilation error on lint errors on react-scripts upgrade

I upgraded react-scripts 0.9.0 to 2.0.3 after which the compilation fails due to linting errors. Is there a way to bypass linting errors in the compilation? I am not using an ejected CRA.

It was because of using global window objects directly and not importing modules on the top. These are reported by linter but I guess there are very few important rules which Create react app enforces.