Remove native-base

[MateuszRostkowski]

Right now we are using native base and maintainers of the native base are abandoning the support for this library.

That means we need to find other alternative and use it in the template.

[MateuszRostkowski]

We have three options of doing this:

1. Use components library like: gluestack / native-base / tamagui
2. Use config / helper library like: native-wind / react-native-whirlwind / styled components
3. Create everything on our own

Personally I see pros and cons of every solution but my favorite is the second one.

[MSzalowski]

In order to structure the thread and discussion somehow, I propose that the potential solutions be presented in the form of a table with pros and cons.

This will make it easier to make a decision once these key solutions have been analyzed.

So to start without investigating on any specific solution, rather general one:

1. Component Libraries

Pros	Cons
Speed of Development: Component libraries typically provide a suite of pre-styled and pre-configured components, reducing the time needed to build common UI elements from scratch.	Performance Overheads: Some libraries may be bloated with unnecessary code or components, leading to slower app performance.
Consistency: Using a UI library can ensure a consistent look and feel across the app without additional effort.	Flexibility: The components might not be as customizable as you would like, leading to potential design compromises.
Documentation & Community Support: Established libraries often come with comprehensive documentation and an active community, which can assist in troubleshooting and best practices.	Dependence: If the library is no longer maintained (like native-base), it may become problematic in the future. There’s the risk of becoming too reliant on third-party solutions.
Feature-Rich: Many of these libraries come packed with extra functionalities like animations, transitions, etc., which can enhance user experience.	Learning Curve: New team members might need some time to get accustomed to the library's way of doing things.

2. Config/Helper Libraries

Pros	Cons
Flexibility: These libraries provide tools to create your own styles and components, offering more freedom in design decisions.	Speed of Development: Without pre-styled components, the initial development might be slower as you have to define more styles yourself.
Tailored Performance: By using only what you need, you can often achieve better performance without unnecessary overhead.	Consistency: Without standardized components, there’s a higher chance of inconsistency across the app. This requires more rigorous design and code reviews.
Maintainability: You're not locked into a third-party component's way of doing things, which can simplify future updates and changes.	Need for More Documentation: You might have to create your own documentation for how to use your styles/components effectively.

3. Creating Everything On Our Own

Pros	Cons
Full Control: Complete control over the design, functionality, and performance of your components.	Time Consuming: Building from scratch is the most time-consuming option, especially for complex components.
Tailored Performance: No unnecessary code, meaning potential for the highest app performance.	Reinventing the Wheel: There’s a risk of spending time-solving problems that others have already solved in established libraries.
No Third-Party Risks: No risks related to third-party library updates, deprecations, or discontinuations.	Lack of Support: Without a community or existing documentation, troubleshooting can be more challenging.

---

I would go for option 3, as we can rely on a large and experienced team which would allow us to minimise the risk of over-engineering. And, in my opinion, the much greater time required to implement this solution would pay off in the future, if only by building the organisation's own brand as well as that of the developers working on the library.

[MateuszRostkowski]

@MSzalowski

Thank you for this detailed overview, you are right creating everything on our own will be much better, I'm only thinking if this will be easier in use for development in feature projects.

We need to support at least two themes (dark / light) and web app, so we need to come up with some good solution to solve all this challenges, and make the development of the app easy :D

Let me think about it couple of days and I will back with my thoughts.

[MateuszRostkowski]

@MSzalowski

I was thinking about it and I'm still not 100% sure that implementing all of it for our self will be the best idea.

I know that creating atom components like Box and Button will be easy, but what about styling other components like ScrollView / Image / Some components from libraries. Previously we were using react-native-whirlwind which provided us some styling helpers like s.bgPrimary and that have created this style { backgroundColor: colors.primary }, and thanks to that we don't have to bother about dark and light theme.

@MSzalowski What are your thoughts on solving this issues?

[MSzalowski]

@MateuszRostkowski You are right. I'll do some minimal examples with the UI libs listed by you and I will provide a summary after all

[MateuszRostkowski]

@MSzalowski I was thinking about some solution to this problems without using any libraries. How to implement dark / light mode easily, how to easily style components, and so on

Maybe we will create our own wrapper and it will work like this:

import { View, Image } from 'react-native'

const Box = generateStyledComponent(View)

{...}

<Box 
  pt={4}
  bg="primary"
/>

const Row = generateStyledComponent(View, {
  flexDirection: 'row'
})

{...}
<Row
  pt={4}
  bg="primary"
/>

And then developer can create their own components like:

import { Image } from 'expo-image'

const StyledImage = generateStyledComponent(Image)

{...}

<StyledImage 
  mx={4}
/>

[MSzalowski]

Linked pull request includes import updates of native-base.