Closed timomeh closed 6 years ago
Not sure if you're open to the opinion of random passerby, but instead of blocking tab presses I feel you should cancel the animation and begin the new animation back to the original tab. And if possible, don't queue up every touch event.
If the events get queued up, the animations quickly fall behind and you're left with an app that is switching tabs by itself. You can replicate it by quickly alternating tab presses.
I'm always open for opinions. 🙂 I totally agree with you, blocking the TabPress isn't the best thing to do. Instead of canceling the animation right away, I'd really like to just run a new Animation on top of the old Animation. I think that would look dope. Canceling the animation would be the second choice, if this doesn't work.
Right now I'm a bit busy and can't concentrate on features for this library. If you'd like to, you can grab it and try to implement it. If not, I think I could tackle this in a few weeks.
Agreed, starting a new animation would be dope.
I'll try to take a crack at it tomorrow if I have time.
Nice! Maybe a jump start if you'll try to wrap your head around this thing:
lib/BottomNavigation.js
: <RippleBackgroundTransition />
and <PressRipple />
. You can find them rendered here.RippleBackgroundTransition
is the big color-changing animation in the background. PressRipple
is the subtle Ripple Touch Feedback when pressing a Tab.run
on them, see here.<View />
.overflow: 'visible'
doesn't work on Android and thus the Animations can't be rendered inside a Tab.(And of course only if you'll have some time)
So after taking a closer look and thinking about what I really want, I think I'm going to try to implement a react wrapper around the [Android BottomNavigationView](https://developer.android.com/reference/android/support/design/widget/BottomNavigationView.html#BottomNavigationView(android.content.Context, android.util.AttributeSet))
I'm already using React Native's TabBarIos component, so I only need an android solution. The downside is I don't think this view has the nice color changing transitions that your component has, but my priority is for the tab switching to be as responsive as possible.
When adjusting your library, I played around with the idea of removing all the animations and setTimeout calls and basically ended up with something pretty snappy, and it actually behaves very closely to the TabBarIos component. But of course then you don't have animations which I believe is a major selling point of this library. Sorry I kinda jumped in here and then didn't implement what I suggested, but thanks for laying out the details! Those will come in handy the next time this issue gets some attention :)
I'm going to close this since there is no recent activity and it's also no highly-requested fix. Although I think blocking isn't the best solution UX-wise, it's simple and keeps the animation clean. Other solutions will imo be more complex and (unnecessary?) bloat.
Pressing on a Tab while another Tab is animating will cause wrong background colors and weird animations. Pressing another Tab should be blocked while the animation runs.