[Bottom Navigation] Confusing Duplicate Bottom Navigation Components and Broken Package

[JumpLink]

I'm new to NativeScript and wanted to start with Material Design's BottomNavigation component. I encountered several issues that I believe need to be addressed:

1. Package Confusion:

   • There are two similar packages available:
     • @nativescript-community/ui-material-bottom-navigation
     • @nativescript-community/ui-material-bottomnavigationbar
       This creates confusion for new users like myself, as it's unclear which one should be used.

2. Broken Package:

   • The @nativescript-community/ui-material-bottom-navigation package appears to be broken:
     • All TypeScript files have incorrect prefixes (using index instead of bottomnavigation)
     • After manually renaming the files (e.g., from index.d.ts to bottomnavigation.d.ts), it partially worked
     • The other package (@nativescript-community/ui-material-bottomnavigationbar) works better

This issue is potentially related to #468, as it might be caused by the same underlying problems.

Suggested Actions:

1. Clarify which package is the recommended one
2. Either fix or deprecate the broken package
3. Update documentation to prevent confusion for new users
4. Consider merging the functionality into a single, well-maintained package

Environment:

• NativeScript version: 8.9.2
• Platform: Fedora Linux 41

[dyazincahya]

up

[farfromrefug]

@JumpLink @dyazincahya i am really sorry feels like i missed that issue.
The bottom-navigation package should be fixed

Now both packages are different and bring different things. None is recommended over the other.
bottom-navigation brings a all in one solution which works but should not fill all needs. Especially when you want behavior customization.

bottomnavigationbar brings only the bar feature. It is good when you want a material bar but custom navigation behavior with Frame for example.

Also should mention that the bottomnavigationbar was a community addition. bottom-navigation was a port of an old plugin.

Let me know if you need any help

[dyazincahya]

@JumpLink @dyazincahya i am really sorry feels like i missed that issue. The bottom-navigation package should be fixed

Now both packages are different and bring different things. None is recommended over the other. bottom-navigation brings a all in one solution which works but should not fill all needs. Especially when you want behavior customization.

bottomnavigationbar brings only the bar feature. It is good when you want a material bar but custom navigation behavior with Frame for example.

Also should mention that the bottomnavigationbar was a community addition. bottom-navigation was a port of an old plugin.

Let me know if you need any help

Am using NS Core (Javascript), When using Bottom Navigation, I found it quite difficult to arrange the layout. I tried following the styling from the documentation, but it didn’t work properly.

BottomNavigation.bottom-nav {
    background-color: orangered;
    color: gold;
    font-size: 18;
}

MDTabStripItem.tabstripitem-active {
    background-color: teal;
}

MDTabStripItem.tabstripitem-active:active {
    background-color: yellowgreen;
}

MDTabContentItem.first-tabcontent {
    background-color: seashell;
    color: olive;
}
MDTabContentItem.second-tabcontent {
    background-color: slategray;
    color: aquamarine;
}
MDTabContentItem.third-tabcontent {
    background-color: blueviolet;
    color: antiquewhite;
}
BottomNavigation TabStrip {
    highlight-color: red;
}

[JumpLink]

@dyazincahya Due to the problems in this package, I wrote my own button navigation component, so unfortunately I can't help you, sorry.

[dyazincahya]

@dyazincahya Due to the problems in this package, I wrote my own button navigation component, so unfortunately I can't help you, sorry.

So amazing,,,

I think that with a relatively small team, NativeScript is trying too hard to support multiple frameworks without a clear focus on a single core technology. In contrast, React Native has grown more rapidly by focusing exclusively on one ecosystem—ReactJS. This focused approach compels all developers to adopt a single technology, resulting in a more streamlined, consistent, and maintainable development process.

Meanwhile, although NativeScript supports various JavaScript frameworks, the results tend to be suboptimal. This scattered approach feels half-hearted and significantly increases the maintenance burden, causing many parts of its ecosystem to become disorganized and harder to manage.

[farfromrefug]

@dyazincahya Due to the problems in this package, I wrote my own button navigation component, so unfortunately I can't help you, sorry.

That's what i always do. Gives me much more control

[farfromrefug]

@dyazincahya that s actually what the N team is doing, focusing on the core technology/package.
Most flavors are brought and maintained by the community. like svelte which i am maintaining.
Now i also think ReactNative and Nativescript are not comparable on any other level than the technology and being cross platform mobile frameworks.
Facebook is putting a lot of money in react native, nativescript is living on very small funding and mostly on people free time.
Community are nor comparable either in term of size.
Finally flavors is one the Nativescript features which makes it "better" than RN by allowing people with different skills, or not liking React, to write native JS apps.
The core team is focusing on the core, its quality and its abstraction allowing flavors to exist.

[dyazincahya]

@dyazincahya that s actually what the N team is doing, focusing on the core technology/package. Most flavors are brought and maintained by the community. like svelte which i am maintaining. Now i also think ReactNative and Nativescript are not comparable on any other level than the technology and being cross platform mobile frameworks. Facebook is putting a lot of money in react native, nativescript is living on very small funding and mostly on people free time. Community are nor comparable either in term of size. Finally flavors is one the Nativescript features which makes it "better" than RN by allowing people with different skills, or not liking React, to write native JS apps. The core team is focusing on the core, its quality and its abstraction allowing flavors to exist.

I’ve been using NativeScript since 2018 and have really enjoyed working with it. I’ve built many projects using the framework, and I sincerely hope the platform continues to thrive, evolve, and improve—even with limited resources 😊❤ 🚀 👍

[JumpLink]

@farfromrefug @dyazincahya As you can see from the linked project above, I'm currently taking my first steps with Android development using NativeScript, trying to port my GNOME application—originally developed in TypeScript—to Android. That’s why TypeScript was a must-have criterion for me.

I also noticed that NativeScript seems to be fading a bit among the newer frameworks, but I still chose it because it aligns well with the way I develop my GNOME app. That app uses native libraries like Gtk and Libadwaita, accessed through partially auto-generated JavaScript bindings (GJS). With NativeScript, I can work in a similar way: I can access native APIs via the respective JavaScript bindings, build my own native components, and still work in TypeScript.

P.S. Right now I’m stuck with an issue where my UI freezes when the 6502 simulator runs (it runs in the same JavaScript thread since it's also written in TypeScript). Maybe someone has a tip for that? :)