tsdmrfth / react-native-steve Goto Github PK

Great library! I'm able to get it to work on iOS, But on android even after I followed all instructions from react-native-animated 2, I only able to render but not able to scroll

I'd expect there to be a sensible default that works in the case that it isn't specified.

I'm testing this with a ScrollView. It's not possible to scroll vertically when swiping on this component as the PanGestureHandler captures it. An improvement would be for this component to only capture horizontal panning, but not vertical.

I've been using a fork where I modified the reanimated dependency specification to ^2 to satisfy another dependency that currently only works for reanimated 2.0. Seems to work without a hitch so I suggest making the peer dependency more liberal.

Really very good component, I've used this component in one of my apps but don't know how to make it work for RTL? any reference and help would be highly appreciated. Thank you so much.

Currently, the example shows 3 rows based on the number of items in topics. Is the number of rows configurable?

Don't have a reproduction for you, but I've observed when updating data, the following error:

TypeError Cannot read property 'layout' of undefined
This error is located at:
    in Item (at Steve.js:107)
    in Items (at Steve.js:200)
    in RCTView (at View.js:32)
    in View (at createAnimatedComponent.js:448)
    in AnimatedComponent(View) (at createAnimatedComponent.js:459)
    in AnimatedComponentWrapper (at Steve.js:199)
    in RCTView (at View.js:32)
    in View (at createAnimatedComponent.js:448)
    in AnimatedComponent(View) (at createAnimatedComponent.js:459)
    in AnimatedComponentWrapper (at Steve.js:198)
    in PanGestureHandler (at Steve.js:195)

I've also noticed that layout recalculation isn't performed when updating data (items may overlap each other). The library should support data updates, or at a minimum warn users.

That's at least my guess. Here's the likely offending line:

                    const firstKey = keyExtractor(data[firstIndex], firstIndex)
                    const secondKey = keyExtractor(data[secondIndex], secondIndex)

The assumption is that the 1 index (whether firstIndex or secondIndex depending on RTL) is valid, which isn't necessarily the case.

If you begin an inertial scroll but place finger down to stop it, it will not stop. It only stops if you actually move your finger.