I am using react-native-reanimated v1. I want to make a <Reanimated.View> appear as if it is fixed within the scroll view by using translateY. GIF of how of it should behave is at very end of post. I have simplified the code in the snippet below, and I have the full working code in the snack.
https://snack.expo.io/#noitidart/reanimated-scroll-view
As you scroll, you notice the position of the view is not staying fixed at the top. I attached a video taken on iOS of the snack.
If I add scrollEventThrottle={16} it fixes the issue on iOS, but on Android if you scroll even a little faster than normal you see the transform is lagging. I think there should be a way on iOS without the scrollEventThrottle property too, it doesn't make sense to me that we need this as reanimated is supposed to update every frame.
Any ideas on how to fix this?
const ReanimatedScrollView = Reanimated.createAnimatedComponent(ScrollView);
export default function App() {
const translateY = Reanimated.useValue(0);
const handleScroll = Reanimated.event([
{
nativeEvent: nativeEvent => Reanimated.block([Reanimated.set(translateY, nativeEvent.contentOffset.y)])
}])
return (
<ReanimatedScrollView onScroll={handleScroll}>
<Reanimated.View style={{ transform: [{ translateY }] }} />
</ReanimatedScrollView>
);
}
Janky on iOS
Janky on Android (with and without scrollEventThrottle={16})
Here is video of how it should be (with scrollEventThrottle={16} on iOS, but it doesn't fix up Android)
Related
How do I convince a vertical React Native FlatList to virtualize correctly inside another vertical (non-virtualizing) FlatList, in React Native Web?
So far, it seems that by default, scrolling to a certain point or responsive resize re-renderings tend to cause the virtualization to go haywire. This Snack demonstrates the problem. Be sure you're on the "Web" tab as the device builds seem to work correctly. Here's a repro through codesandbox too.
Update: Per request, here's the code inline as well. This is a full program that can paste into, say, a new expo init project (or similar) to see the strange behavior and experiment with it.
import React, { useCallback } from 'react';
import { FlatList, Text, useWindowDimensions, View } from 'react-native';
// Make 200 rows for the big list (which will draw green and red with some info).
const bigListData = Array(200).fill(0).map((element, index) => index);
function onViewableChange({ viewableItems }) {
if (viewableItems.length < 2) {
console.log(`VIEWABLE CHANGE! Only ${viewableItems.length} visible...`);
} else {
console.log(`VIEWABLE CHANGE! ${viewableItems[0].index} to ${viewableItems[viewableItems.length - 1].index}`);
}
}
function BigList() {
const { height, width } = useWindowDimensions();
const betweenRows = 10;
const itemHeight = height / 8;
const totalRowHeight = itemHeight + betweenRows;
const renderer = useCallback(({ item }) => {
const key = `i_${item}`;
return <View key={key} style={{
backgroundColor: item % 2 ? "red" : "green",
height: itemHeight,
width: '90%',
marginLeft: '5%',
marginBottom: betweenRows }}>
<Text>{key}, rh: {totalRowHeight}, offset: {totalRowHeight * item}, i {item}</Text>
</View>;
}, [itemHeight, totalRowHeight]);
const getItemLayout = useCallback((__data, index) => ({
index,
length: itemHeight,
offset: index * totalRowHeight
}), [itemHeight, totalRowHeight]);
return <FlatList
data={bigListData}
getItemLayout={getItemLayout}
key={'flatList'}
numColumns={1}
onViewableItemsChanged={onViewableChange}
renderItem={renderer}
/>;
}
function NoNestedFlatLists() {
const windowHeight = useWindowDimensions().height;
return <View style={{ height: windowHeight, width: '80%' }}><BigList /></View>;
}
function renderComponent({ item }) {
if (item.type === "widget") {
// Using height 600 here, but assume we cannot easily predict this height (due to text wrappings).
return <View key={item.type} style={{ backgroundColor: 'blue', height: 600, width: '100%', marginBottom: 15 }} />
}
return <BigList key={item.type} />;
}
function NestedFlatLists() {
const windowHeight = useWindowDimensions().height;
const components = [{ type: "widget" }, { type: "bigList" }];
return <FlatList
data={components}
key={'dynamicAppFlatList'}
numColumns={1}
renderItem={renderComponent}
style={{ height: windowHeight, width: '80%' }}
/>;
}
export default function App() {
const windowHeight = useWindowDimensions().height;
// Rendering just the following has no virtualization issues.
// The viewable change events make sense, no items suddenly disappear, no complete app meltdown...
//return <NoNestedFlatLists />;
// However:
// Any useful dynamic "rows of components" architecture melts down when virtualization comes into play.
// This sample represents such an app whose feeds have asked the app to render a "widget" followed by a
// "bigList" who could well have a few hundred items itself and thus really needs virtualization to work
// well on low-end devices. This demo leans on console logs. In snack.expo.dev, at time of writing, these
// feel hidden: Click the footer bar, either on the checkmark or an empty space, and then the "Logs" tab.
// Once you scroll down about half way in the "App", even slowly, you'll get logs like the following:
// Chrome: VIEWABLE CHANGE! 83 to 90
// Chrome: VIEWABLE CHANGE! 85 to 92
// Chrome: VIEWABLE CHANGE! Only 0 visible...
// Chrome: VIEWABLE CHANGE! 176 to 183
// Chrome: VIEWABLE CHANGE! 177 to 184
// At which time, all the UI disappears. What it thinks is viewable is quite wrong. Try to scroll around,
// but none of the mid rows are drawing. There is no easy way to repair app behavior from this state. The
// only rows which still draw correctly during the problem are the top and bottom non-virtualizing rows.
//
// As an alternate repro, you can scroll to near the middle and then resize the bottom of the window, and
// similar virtualization problems can occur. (In our real app, we can be scrolled almost anywhere out of
// the non-virtualizing rows, and make a 1px window resize to break the app. We have a more complex app
// structure, but I'm hoping a fix for this snack will still be applicable to our own symptoms...)
return <NestedFlatLists />;
}
Hopefully I am missing something trivial, as it seems clear React Native is attempting to handle nested FlatLists of the same orientation, and for the most part does great. Until you happen to have enough data items to bring virtualization into play, and even then, only fails for Web. (We've tried upgrading React Native to all the way to 0.67.2 and React Native Web to 0.17.5 - the latest releases - with no luck, and none of the Expo dropdown versions yield correct behavior in the linked Snack either.) What can I change in either sample to have correct virtualization in the nested FlatList?
Short answer is: You can't convince FlatList to virtualize this way correctly. At least currently (0.17), it's broken.
Although I was able to get some FlatList virtualization improvements into React Native Web's 0.18 preview, ultimately the measurement problems are deeper than I could afford to spend more weeks to fully fix. (If someone wants to try picking up from there - I recommend to focus on reconciling RNW's ScrollView versus RN's ScrollView and then digging into the ScrollView's measurements going absolutely haywire in the repro scenario, if replicating RN's evolution of ScrollView to RNW isn't enough.)
It ended up being much faster though to build our own virtualizing list component from scratch. Ours is specialized to our needs ATM so probably won't become open source, but who knows. But if you need to go this route... think about throttling reactions to scroll events and such to ".measure" the container view ref periodically and decide which things you need to render versus just rendering reserved empty space for... etc. There are other approaches but that seems to work.
I have made an example code here with Snack expo
Animated Header
The issue that I'm having is that my animation is not smooth enough.
It looks like it's shaking.
Demo video YouTube Video
I can't seem to find what's the issue here and also tried to fiddle around with the scrollEventThrottle, alwaysBounceVertical, bounces, bouncesZoom props in ScrollView.
I figure out what the problem is and the issue is not because of the performance.
The problem is because of the styling on the header.
Adding the position to absolute will solve this problem.
But there's another issue that appeared when having the position as absolute, the component inside the header such as TextInput won't appear when a touch event occurs.
To solve this new issue, you have to add the zIndex.
More tutorial about zIndex
Animated Header Fixed
Try adding useNativeDriver:
onScroll={
Animated.event([
{
nativeEvent: {
contentOffset: {
y: scrollY,
},
},
},
],
{ useNativeDriver: true })
}
But I think in React Native, ScrollView is not supposed to work with extremely long duplicated content. I suggest you to use a flatlist for your use case.
Adding removeClippedSubviews = {true} on top most ScrollView solved my issue and app performance feels so light.
I’m currently using LayoutAnimation to animate a view when children are added. However, since LayoutAnimation causes everything to be animated, globally, and I can’t easily use built-in Animated library to fit my use-case, I’m wondering if react-native-reanimated is able to help.
Here's a snack of my current solution:
https://snack.expo.io/#insats/height-adapation
This is what the result of that looks like:
Is there a way to achieve the same thing without using LayoutAnimation? I've looked through all exampled in react-native-reanimated, and I've read through the docs but I'm still not sure if this is possible to do or how I should get started. I've thought about using Animated to move the item-wrapper out of the viewable area and "scroll" it upwards (using transform translateY) when items are added, but that would require fixed height, which I don't have.
I have 2 approaches that I can suggest out of my mind:
You can configure your LayoutAnimation only when your desired state changed. If you use hooks it would be too easy:
const [state,setState] = useState([]);
useEffect(()=>{
/*rest code*/
LayoutAnimation.configureNext(LayoutAnimation.Presets.easeInEaseOut)
},[state])
Or if you use class component you can catch your desired state change in componentDidUpdate:
componentDidUpdate(prevProps,prevState){
if(prevState.items!==state.items){
LayoutAnimation.configureNext(LayoutAnimation.Presets.easeInEaseOut)
}
}
You can use onLayout function of view:
addItem = () => {
this.setState({
items: [...this.state.items, {title:'An item',isNew:true}]
})
};
renderItems = () => {
return this.state.items.map((item, index) => {
let opacity = new Animated.Value(0);
return (
<Animated.View onLayout={({nativeEvent})=>{
if(this.state.item.isNew){
// here you got the height from nativeEvent.layout.height
// Then you have to store the height animate height and opacity to its precise value
// PS I used opacity:0 to calculate the height
}
}} key={index} style={[styles.item,{opacity}>
<Text>{item.title}</Text>
</View>
)
});
};
When it comes to react-native-reanimated I regard it as more faster version of react-native's Animated library. So either way you will have to calculate the height!
The react-native-webview has in my experience proved difficult to behave as I want around the keyboard on iOS. It doesn't automatically change it's height when the keyboard is shown and its contents gets concealed by the keyboard.
It also behaves strangely wrapped with the KeyboardAvoidingView. In my case it seems to adjust the content of the WebView too much, approximately twice the height of the keyboard. This same behavior appeared when I manually listened for the keyboard open/close events and adjusted the height of the WebView accordingly:
componentDidMount(){
Keyboard.addListener("keyboardWillShow", this.keyboardDidShow.bind(this));
Keyboard.addListener("keyboardWillHide", this.keyboardDidHide.bind(this));
}
componentWillUnmount(){
Keyboard.removeListener("keyboardWillShow", this.keyboardDidShow.bind(this));
Keyboard.removeListener("keyboardWillHide", this.keyboardDidHide.bind(this));
}
keyboardDidShow(event){
this.setState({
keyboardHeight: event.endCoordinates.height
});
}
keyboardDidHide(event){
this.setState({
keyboardHeight: 0
});
}
render(){
return (
<WebView
style={{flex: 1, maxHeight: Dimensions.get("window").height - this.state.keyboardHeight}}
/>
);
}
I've found a solution, not optimal, but a solution non the less. My answer is posted below.
As I couldn't find any discussions on this particular behavior and no solutions that worked for me, I worked my way through the props of the react-native-webview docs. What finally worked for me in version 0.59.9 of React Native and version 5.11.0 of React Native WebView was as described above, manually setting the height of the WebView in the keyboard event listeners and setting the WebView prop useWebKit={false}.
Unfortunately this means that on the native side of the WebView, it's now using UIWebView which is deprecated and will in a future release be deleted.
Either way, this is what I'm rolling with and simply wanted to share my findings in case anyone finds themselves with the same issue.
I'm using onLayout to detect screen orientation and it's working fine inside my root view, but when I implemented inside the drawer it didn't work, any reason why this happens ?
code :
import Drawer from 'react-native-drawer'
...
onLayout(e) {
console.log('onLayout');
}
<Drawer onLayout={this.onLayout}
It didn't log any thing when orientation changed!
This is because the Drawer component doesn't take onLayout as a prop. You can see in the source code that the rendered View does use onLayout, but it's not pulling from something like this.props.onLayout.
I'm not exactly sure what you're looking to do, but maybe this issue will help you. As it shows, you can pass a function into openDrawerOffset instead of an integer or a ratio in order to be a little more dynamic with how you set your offset:
openDrawerOffset={(viewport) => {
if (viewport.width < 400) {
return viewport.width * 0.1;
}
return viewport.width - 400;
}}
You might also benefit from the Event handlers that react-native-drawer has to offer.