+1
Rencontre exactement le même problème. A fonctionné avec 0,5 mais a rompu avec 0,6.

Cela devrait être corrigé en 0.7

J'ai rencontré exactement le même problème.

cloneWithRows fonctionne très bien. mais pas cloneWithRowsandSections.

Voyez-vous cloneWithRowsandSections ne pas fonctionner avec 0.7 ?

En outre, vous voudrez peut-être essayer de définir initialListSize sur un nombre plus grand - cela pourrait aider comme solution de contournement si les choses ne sont pas corrigées dans 0.7 pour vous.

Bigger initialListSize n'aide pas et 0.7 je n'ai pas encore essayé à cause de la dépendance des fournisseurs. Comme ce sera possible, je vous préviendrai environ 0.7 si quelqu'un ne sera pas plus rapide :)

Ayant le même problème avec cloneWithRows dans la version 0.6, fonctionnait en 0.5.

Je ne l'ai pas essayé en 0.7. Je vais essayer. Je sais que j'avais déjà essayé de définir initialListSize sur un nombre plus élevé et que cela n'avait pas aidé.

travaillé en 0,7

Ne fonctionne pas non plus dans la 0.7.1

Avoir le même problème avec cloneWithRows dans la version 0.7.1

Pour moi, cela fonctionne bien en 0.7.1.

Ne fonctionne pas dans la 0.8.0.

Toujours en utilisant cloneWithRows au lieu de cloneWithRowsAndSections

cloneWithRows fonctionne pour vous yamill ? Pas pour moi dans la 0.8.0.

@coderdave en fait cloneWithRows ne fonctionne pas pour moi non plus. mon erreur.

@sahrens @ide @michalraska mon scrollY n'était pas mis à jour. J'essayais essentiellement de transmettre le décalage de défilement à mon composant, comme ceci :

    renderRow: function (rowData, sectionID, rowID) {
          return (
            <Row
            key={rowData.id} data={rowData} scrollY={this.state.contentOffset}
             />
          )
    });

Mais la correction de cette ligne m'a permis de recevoir avec succès le prop scrollY sur mon composant. Je me demande si ce changement résout tous les autres problèmes ?

https://github.com/facebook/react-native/blob/757d6d204ae2d743634af64e3f78a4aad9d53f70/Libraries/CustomComponents/ListView/ListView.js#L342 -L343

Je l'ai changé de :

var shouldUpdateRow = rowCount >= this.state.prevRenderedRowsCount && dataSource.rowShouldUpdate(sectionIdx, rowIdx);

à

var shouldUpdateRow = true;

J'ai également remarqué cela sur 0.11.0-rc.

Voici deux exemples qui peuvent reproduire le problème.

Lignes : https://rnplay.org/apps/d3DM6A
Lignes + Sections : https://rnplay.org/apps/xnyaYw

La solution temporaire que j'ai trouvée consistait à faire défiler le ListView 1pt lors de son montage.

let listViewScrollView = this.refs.listView.getScrollResponder();
listViewScrollView.scrollTo(1);

Vous pouvez décommenter cette section dans l'exemple sur rnplay.org à des fins de test.

Question bête. Cela pourrait-il avoir quelque chose à voir avec l'utilisation de NavigatorIOS ? J'ai eu quelques problèmes avec le rendu, le remplissage, etc. lorsqu'une vue de liste était rendue en tant qu'enfant de NavigatorIOS.

@jaygarcia Je ne pense pas car les exemples n'utilisent pas NavigatorIOS. De plus, dans mon propre projet, j'utilise Navigator au lieu de NavigatorIOS.

+1 pour moi, je rencontre actuellement ce comportement lors de l'utilisation de Navigator. Je suis sur 0.11 et j'utilise cloneWithRows.

Comme solution de contournement, j'ai dû utiliser la solution de @christopherdro , mais j'aurais besoin de la faire défiler suffisamment pour que mes éléments soient rendus (ils sont gros).

Fait intéressant, la solution de contournement est liée à la solution de contournement de ce bogue : https://github.com/facebook/react-native/issues/1878 donc mon code final est :

    listViewScrollView.scrollWithoutAnimationTo(80);
    listViewScrollView.scrollWithoutAnimationTo(-80);

ok, en utilisant le code mentionné ci-dessus, j'ai eu quelques bugs bizarres dans les ScrollViews imbriqués : Après le montage, un événement onScroll a été déclenché qui a repositionné mon décalage de défilement initial sur ces vues.

Encore un bug dans 0.12.0. Voici la hiérarchie des vues :

Mêmes problèmes que @Sidnicious sur 0.11.0. Mon application a eu ce problème depuis une première version de react-native. Tout fonctionne comme prévu si je déplace le ListView hors de la hiérarchie Navigator .

Je rencontre le même problème avec 0.13.0-rc

J'ai ce problème dans 0.13.1 avec seulement ceci :

    constructor(props) {
        super(props);
        var ds = new ListView.DataSource({rowHasChanged: (r1, r2) => r1 !== r2});
        this.state = {dataSource: ds.cloneWithRows(Array.apply(null, {length: 100}).map(Number.call, Number))};
    }
    render() {
        return (
    <ListView
        style={{paddingTop: 20, flex: 1}}
        dataSource={this.state.dataSource}
        renderRow={(rowData) => <Text>{rowData}</Text>}
    />
    )

Pour moi, ce problème vient d'apparaître lors de la mise à niveau de 0.14.2 vers 0.16.0-rc . Le correctif qui a fonctionné pour moi consistait à définir la prop pageSize sur ListView sur 3. 2 n'a pas fonctionné pour moi, mais 3 a très bien fonctionné.

_(ツ)_/¯

même problème ici avec 0.15.0, essayé toutes les astuces, pas de chance. ios 9.1 iphone 6

@nicklockwood - pouvez-vous aider ici ? On dirait qu'il y a encore des bugs.

0.14, même problème

Lier un problème LisView similaire : https://github.com/facebook/react-native/issues/4728

Lien avec un autre problème similaire : https://github.com/facebook/react-native/issues/4179

Je vois cela dans 0.16.0. Quelqu'un a-t-il placé cela sur le radar sur Product Pains? Celui-ci devient assez douloureux. :/

J'ai posté ceci sur Product Pains . Si cela vous affecte toujours, n'hésitez pas à voter là-dessus.

0.16, même problème

Le problème persiste toujours dans 0.17 en utilisant cloneWithRows sur la source de données. La liste ne restitue les éléments que lorsqu'elle défile.

Je voyais ce même problème sur 0.17 mais la désactivation de removeClippedSubviews semble l'avoir résolu.

+1
Je voyais ce même problème sur 0.17, mais la désactivation de removeClippedSubviews semble l'avoir résolu.

Pour moi, cela arrive toujours en 0.17 avec ou sans removeClippedSubviews . Ce que j'ai remarqué, c'est que mon problème pourrait être lié à un contentOffset défini manuellement et à initialListSize . Si le décalage est au-delà de la hauteur des éléments qui seraient rendus pour le initialListSize , il ne rendrait pas les éléments requis tant que l'utilisateur n'aurait pas fait défiler.

Il semble également y avoir un problème avec les listes qui ont flexDirection: 'row' défini. Lorsque je supprime cette propriété, tous les éléments s'affichent. Si elle est définie, la liste ne restitue initialement que deux éléments.

Pour le problème removeClippedSubviews lors de l'utilisation de Navigator.
Vous voudrez peut-être vérifier https://github.com/machard/react-native-advanced-navigation où le problème ne se produit pas (probablement parce que le rendu est retardé après que la vue soit vraiment à l'écran)

Il y a aussi un problème avec flexDirection: 'row' et flexWrap: 'wrap' définis dans la propriété contentContainerStyle . La solution de contournement qui fonctionne pour moi consiste à définir pageSize .

version native de réagir : 0.19.0

merci @jittuu d' avoir défini l'accessoire pageSize l'a fait pour moi aussi !

définir la taille de la page à quoi ?

@gre cela dépend de votre mise en page. Si vos vues sont organisées en lignes, pageSize doit être un multiple des éléments par ligne. Vous pouvez expérimenter avec la valeur exacte, pour voir comment elle affecte les performances.

Vous devez également définir initialListSize suffisamment grand pour remplir tout l'écran.

Vous pourriez trouver l'explication dans ce commit utile : https://github.com/facebook/react-native/commit/e7005f7f5429422b6f2e9c2aa29c9d57bda7b77a

@jittuu Cela a fonctionné pour moi; J'ai également rencontré le bogue lors de l'utilisation de flexWrap .

merci @jittuu définissez la pageSize avec la valeur 2 m'a également résolu le problème !!

le problème persiste lorsque vous faites défiler la liste, naviguez dans l'application et revenez en arrière.
pageSize n'a pas aidé (j'ai essayé différentes valeurs de 1 à 60).

@gre définissez -vous initialListSize suffisamment grand? Y a-t-il un dépôt que nous pouvons voir ?

@jaygarcia @nicklockwood J'ai une démo pour reproduire ce bug, url du dépôt :

étape:

1. ouvrez l'application.
2. cliquez sur l'élément de la barre d'onglets "#1".
3. l'élément de liste ne s'affiche qu'après un défilement.

Je suis sûr que ce bogue concerne la prop removeClippedSubviews de ListView, et le bogue ne se produit que lorsqu'il est défini sur true.

Cela se passe toujours pour nous sur la RN 0.26.0. Même situation ici :

• removeClippedSubviews={true}
• ListView est rendu hors écran
• en allant à cet écran, la liste est glissé jusqu'à ce que l'utilisateur interagisse avec elle

cc @javache

Je crois que cela est corrigé par https://github.com/facebook/react-native/commit/1fcd73f3841d5afbabfa3adecfb7d4036d91a60e

@javache J'ai ajouté manuellement cette ligne localement et cela n'a pas résolu le problème.

J'ai également appliqué celui-ci par-dessus https://github.com/facebook/react-native/commit/1048e5d3445094393298d4e818ff04c41f4e56a7 mais sans succès non plus. ;)

le seul commit https://github.com/facebook/react-native/commit/1fcd73f3841d5afbabfa3adecfb7d4036d91a60e au-dessus de RN 0.28 crée toujours le bogue pour moi aussi.

En enquêtant un peu là-dessus, je me demande si ListView est toujours mis à jour en arrière-plan (par exemple lors d'une mise à jour de défilement) même lorsqu'il n'est plus visible?

Car, en fait, le bug est facilement reproductible pour moi si je scrolle sur la vue, fais une navigation quand elle défile encore avec 'gravity' , attends un peu et clique en arrière. Le plein écran sera blanc jusqu'à ce
Mais c'est fondamentalement le seul scénario où ce bogue m'arrive. Est-ce ~ le même scénario de repro pour tout le monde, ou le bogue est-il plus large que cela ?

Ce scénario n'est pas si éloigné de @janmonschke https://github.com/facebook/react-native/issues/1831#issuecomment -22799032 .

Il est difficile de comprendre la raison de ce bug, mais voici mes 2 centimes :

Il semble que les lignes soient rendues _white_ pendant l'arrière-plan. Lorsque vous rendez à nouveau la vue de défilement visible _(par exemple revenir en arrière)_, ils sont toujours blancs et ne sont pas mis à jour _(parce qu'ils n'ont aucune raison d'être mis à jour, ils sont mis en cache)_ jusqu'à ce qu'un nouveau défilement se produise.

Est-ce que cela résoudrait le bogue si le ScrollView rendait ses enfants ( updateClippedSubviews ?) seulement s'il est toujours visible ? (si les lignes ne sont pas rendues en arrière-plan, elles ne seront plus jamais affichées en blanc)

@javache 1fcd73f peut corriger le cas ListView avec une ou deux rangées qui ne remplissent pas tout l'écran. dans ce cas, même le défilement ListView ne peut pas réafficher la ligne de la liste.

Je trouve un moyen simple de reproduire le bug :

1. Afficher un ListView avec removeClippedSubViews = true;
2. Appuyez sur une ligne pour entrer dans la page suivante ;
3. Faites pivoter l'orientation de l'écran de 90 ;
4. Faites pivoter l'écran vers l'arrière ;
5. Retour à l'écran ListView ;

ListView sera vide, avec des lignes plus qu'un écran, faites défiler le ListView sera réaffiché, avec des lignes moins qu'un écran, même le défilement ListView ne peut rien réafficher. avec 1fcd73f scroll ListView peut réafficher :)

1. Toujours voir ce problème à partir de 0.26.3
2. Sur mon projet non RN, j'ai vu le problème dans Android natif.

La solution que nous avons choisie était de faire un décalage scrollTo 1px en avant et en arrière sur Refresh. C'est un travail de contournement, mais cela a fonctionné dans les deux cas.

requestAnimationFrame(() => { this.listview.scrollTo({y: 1}); });

@JBerendes oui ce hack fonctionne.

voici une solution de contournement plus sophistiquée qui ne casse pas le défilement de l'utilisateur :

class ...YourListAbstraction {

  _scrollY = 0;
  _lastTimeScrolled = 0;

  scrollHackToWorkaroundWhiteBug (amount) { // call at appropriated time, with -1 or 1. if possible alternate so you don't change the actual scroll over calls xD
    const { list } = this.refs;
    if (!list) return;
    if (Date.now() - this._lastTimeScrolled < 500) return; // don't mess with user scroll
    list.getScrollResponder().scrollTo({
      y: this._scrollY + amount,
    });
  }

  onScroll = ({ nativeEvent }) => { // give onScroll={this.onScroll} to ListView
    this._scrollY = nativeEvent.contentOffset.y;
    this._lastTimeScrolled = Date.now();
  };

}

à mettre dans votre abstraction ListView. Ensuite, vous devez appeler scrollHackToWorkaroundWhiteBug à l'heure appropriée. Pour moi c'est à chaque fois que je change d'écran (avant et après la transition).

Je pense que cela est lié au scrollRenderAheadDistance ListView (car il rend les lignes non rendues après avoir été touchés) et j'ai réussi à le corriger en définissant le scrollRenderAheadDistance sur une valeur supérieure à 1800. Il y a certainement une corrélation entre scrollRenderAheadDistance et le nombre de lignes qui sont rendues mais c'est incohérent. J'ai constaté qu'il s'affiche généralement comme suit (bien que parfois il affiche toutes les lignes):

| scrollRenderAheadDistance | Nombre de lignes rendues |
| --- | --- |
| 1000 | 2 |
| 1200 | 2-5 |
| 1400 | 5 |
| 1600 | 6 |
| 1800 | 7+ |

Je rends un ListView avec des lignes de 80 pt de hauteur. J'ai dérivé une formule qui devrait vous aider à définir exactement le bon scrollRenderAheadDistance pour votre ListView :

scrollRenderAheadDistance = 680 + (ROW_HEIGHT_IN_PIXELS * INITIAL_PAGE_SIZE_IN_PIXELS)

Cependant, je ne comprends pas la signification de 680 (ou 340 * 2 ).

EDIT : Cette solution fonctionne en Debug mais pas en Release Scheme (pour iOS)...

D'accord, définir removeClippedSubviews sur false résout le problème pour moi.

Je n'ai pas rencontré cela avant la mise à niveau de 0,26 à 0,29, donc quelque chose a été introduit dans 0,27, 0,28 ou 0,29 (je n'ai pas encore testé contre 0,27 ou 0,28 mais je peux si cela peut aider).

@gnestor C'est cassé en 0.29, vérifiez #8607 et https://github.com/facebook/react-native/commit/1048e5d3445094393298d4e818ff04c41f4e56a7

@gnestor @nihgwu Je suis presque sûr que le bogue n'est pas une régression récente. Ce problème a été créé il y a un an, et j'en ai personnellement fait l'expérience depuis RN 0.13 et j'ai toujours utilisé une solution de contournement pour "survivre" avec ListView. ne pas utiliser removeClippedSubviews rend la grande liste lente.
Peut-être qu'il y a eu des tentatives pour le corriger ou au moins pour réduire les cas où le bogue apparaît, mais cela se produit toujours à peu près comme ce qui a été signalé dans ce message de problème initial.

@gre mais je pense toujours que #8607 a été introduit dans 0.29, c'est vraiment gênant d'aller en vue vide, je viens d'annuler le changement de https://github.com/facebook/react-native/commit/1048e5d3445094393298d4e818ff04c41f4e56a7 et tout fonctionne très bien comme avant sans éteindre removeClippedSubviews

Définissez initialListSize sur une valeur appropriée et définissez removeClippedSubviews sur false pour résoudre mon problème

Vous avez ce problème après la mise à niveau de 0,28 à 0,29.
removeClippedSubviews={false} résolu le problème.
De plus, dans mon cas, je mets à jour ListView height sur componentDidUpdate() .
Envelopper le code de mise à jour de la hauteur dans componentDidUpdate() avec setTimeout avec un délai d'attente personnalisé est également utile.

J'ai également vécu cela, mais c'était sur une ListView remplie de données locales. Je ne voyais cela que sur iOS et après la mise à niveau vers 0.29. Le ListView en question utilise this.state.dataSource.cloneWithRowsAndSections et componentDidMount est quand je le charge.

Et donc removeClippedSubviews={false} abordé ce problème.

Le réglage de removeClippedSubviews sur mon composant ListView fonctionné pour moi. Je ne rencontrais ce problème qu'avec le schéma Release sur 0.29 lors de l'utilisation du composant Navigator par défaut.

J'ai le même problème, j'ai mis flexDirection : 'row' et flexWrap : 'wrap', je suis sur RN 0.29.2. Sur d'autres listviews (où je n'ai pas défini flexDirection: 'row'), je n'ai pas ce problème.

Une solution rapide, comme l'ont dit d'autres affiches, consiste à définir les paramètres initialListSize et pageSize appropriés, mais je pense que ceux-ci rendront l'application moins réactive, par exemple si vous avez des filtres qui n'afficheront que les parties d'une liste d'éléments que vous avez dans la liste. , taper entre les filtres sera lent car la liste essaie de restituer toute la zone visible.

Sur d'autres listviews, j'ai résolu ce problème en définissant initialListSize=0 pageSize=1. Mais je ne peux pas sur la grille listview (flexDirection : 'row' et flexWrap : 'wrap').

Je frappe ceci sur RN v0.31.0-rc.0.

L'ajout de removeClippedSubviews={false} semble avoir résolu le problème.

"removeClippedSubviews={false}" ne semble pas être une bonne solution, il rendra toutes les lignes et aura un problème de gestion de la mémoire. Quelqu'un a-t-il une meilleure solution à l'exception de "listView. scrollTo" et "removeClippedSubviews" ?

Ce problème est bien pire sur ios 10 beta avec RN 0.31 :-(

removeClippedSubviews ne m'a pas aidé sur Android, j'ai dû passer de ListView à ScrollView place.

Un bug vraiment énorme. Je l'ai rencontré aussi.

Assurez-vous que tout le monde le vote sur Product Pains. C'est déjà assez haut, mais pas encore assez haut pour atterrir dans la boîte de réception de quelqu'un :-( Voici le lien

À ce stade, je dirais que c'est probablement le même problème que #8607. Découvrez-le pour mon plan comment y faire face.

Continue d'exister dans 0.33.0

Existe toujours en 0.32

J'ai rencontré ce bogue hier et le paramètre removeClippedSubviews = {false} fonctionné.

+1 sur 0.33

Ouais, moi, même problème ! +1
0,33,
Éditer:
removeClippedSubviews = {false}, a également résolu le problème pour moi.

+1

Pourriez-vous essayer ce correctif https://gist.github.com/majak/b0ee1fb6ca725d2cf810d2f0ab394f2e (à partir de #8607) et laissez-moi savoir si cela aide à résoudre ce problème ?

@majak Merci d'avoir partagé ce patch. Nous venons de l'appliquer, maintenant ce problème est parti (RN 0.34).

@majak cela semble régler le problème pour moi aussi, bon travail !

cela se passe sur la RN34, quand removeClippedSubviews={true}

J'ai eu ce problème sur React Native 0.34.
Le problème ne s'est produit que lorsque j'ai eu:

    flexDirection: 'row',
    flexWrap: 'wrap',
    justifyContent: 'center',

sur le style listview.

initialListSize={100}
l'a réparé pour moi

@majak envisagez-vous de créer un PR avec ce patch ?

@janmonschke ouais ! Suivez le problème lié pour les mises à jour.

A eu ce problème sur React Native 0.36

Je peux confirmer que cela se produit sur 0.36

Il fonctionne parfaitement en émulateur, en mode débogage uniquement, mais jamais sur un appareil. La liste ne fonctionne jamais sur un appareil, a essayé tout ce qui est recommandé ci-dessus, a même remplacé le ListView par ScrollView , tout ce que je vois sur mon appareil Android est un navigateur. (J'ai même essayé de mettre la liste en dehors du navigateur)
0.37

Je peux toujours trouver le problème sur 0.36 mais merci pour le travail autour !

Je le vois toujours à 0,36.1

Je le vois toujours à 0,36.1

exister en 0.31
initialListSize={1} résous le pour moi

A eu ce problème sur React Native 0.38

renderScrollComponent={(props) => <ScrollView style={flex: 1} /> }

cela résout le problème dans la version 0.38, je ne sais pas si cela fonctionne également dans les versions précédentes.
cette archive le problème dans la version 0.38, je ne sais pas si travailler sur les premières versions

Ce problème existe sur 0.36.
Impossible de le faire fonctionner avec removeClippedSubviews = {false} et initialListSize={8}

plus d'un an s'est écoulé, cette question est toujours ouverte ??

existe toujours sur 0.39. définir removeClippedSubviews = {false} fonctionne.

"removeClippedSubviews={false}" ne semble pas être une bonne solution, j'ai une nouvelle solution et cela fonctionne pour moi. Plateforme iOS. Fichier RCTView.m

dois-je créer un PR ?

Quelqu'un a-t-il testé sur RN0.40, je ne rencontre plus ce problème après la mise à niveau vers RN0.40

Ce problème existe.
1, Afficher un ListView avec removeClippedSubViews = true;
2, appuyez sur une ligne pour entrer dans la page suivante ;
3, rotation de l'orientation de l'écran 90 ;
4, retour à l'écran ListView ;

ListView sera vide, avec des lignes plus qu'un écran, faites défiler le ListView sera réaffiché

@endpress J'ai suivi vos étapes, je ne peux toujours pas le reproduire, en utilisant RN0.41RC0

Avoir ce problème en 0.38.

Ma solution de contournement consiste à modifier le paddingTop de ListView entre 0 et 1, de sorte que ListView sera actualisé à chaque fois.

Vous pouvez essayer de changer la couleur d'arrière-plan, la bordure, etc. Veuillez me faire savoir si d'autres propriétés fonctionnent.

@nihgwu existe toujours sur 0.40.0

C'est le problème

@endpress le changement (https://github.com/facebook/react-native/issues/1831#issuecomment-270552011) fonctionne pour mon cas, et cela peut également aider facebook/react-native#8607.
Je sais que le patch est peut-être encore loin d'être parfait, mais je vous suggère quand même de créer un PR.

pour moi, même le réglage initialListSize={0} le corrige rn 0.40.0

@majak Y a-t-il de bonnes nouvelles à ce problème fatal ?

Qu'en est-il de https://github.com/facebook/react-native/commit/a3457486e39dc752799b1103ebe606224a8e8d32 ?

FlatList est encore expérimental, donc aucune garantie qu'il ait moins de bogues ou qu'il change de manière incompatible avec l'arrière, mais vous pouvez l'essayer à vos risques et périls.

@sahrens @gre Est-il possible de créer une couche abstraite au-dessus de FlatList qui fournit la même API que l'ancien ListView afin que notre ancien code d'application puisse conserver le même.

@sahrens FlatList est implémenté avec UITableView ?

Une fois que FlatList est stabilisé et n'est plus expérimental, nous pouvons créer un adaptateur avec une API identique à ListView, ou peut-être remplacerons-nous l'implémentation de ListView sous le capot.

Il n'utilise pas UITableView. En fait, il n'utilise aucun nouveau code natif, il s'agit uniquement de JS avec nos primitives natives/framework existantes - vous pouvez consulter l'implémentation ici : https://github.com/facebook/react-native/commit/a3457486e39dc752799b1103ebe606224a8e8d32

@sahrens merci, c'est assez cool et utile.

@savanthongvanh définir la taille initiale sur 0 a pour effet de rendre tous les éléments de la ListView lors du chargement initial. Soyez prudent avec cela si vous avez beaucoup d'articles.

Traitant également de ce rn 0.41.2. Est-ce que quelqu'un a une implémentation simple de FlatLIst que je peux copier, en espérant vraiment une solution bientôt.
Merci,
ron

FlatList (et VirtualizedList) sont en master si vous voulez jouer avec.

Voici un moyen simple de commencer maintenant avec FlatList pour toute personne confrontée à cela : https://hackernoon.com/react-native-new-flatlist-component-30db558c7a5b#.xnp03gd2u

Définissez initialListSize sur une valeur appropriée et définissez removeClippedSubviews sur false pour résoudre mon problème

Merci @hoperce , avec removeClippedSubviews fonctionne pour moi, le initialListSize cause un défilement saccadé

J'ai RN .42 et je ne vois aucune bibliothèque expérimentale ici pour la FlatList, donc je suis bloqué jusqu'à ce que je puisse mettre à niveau (pas avant un petit moment) avec ce problème.

Vous pouvez toujours copier le code FlatList dans votre application, même si vous n'utilisez pas la dernière version de RN.

Je peux toujours reproduire le bogue "la vue complète devient blanche lors du retour" avec FlatList. Je me demande si ce n'est pas plus lié à ScrollView.

Le problème de passer brièvement au blanc est totalement différent et unique à FlatList. Nous travaillons à l'atténuer, mais c'est une conséquence délicate du rendu fenêtré asynchrone. Le bogue auquel ce problème fait référence est qu'aucun contenu n'est visible sur le rendu initial jusqu'à ce que l'utilisateur défile, ce qui, j'espère, est corrigé avec FlatList.

J'ai également rencontré ce problème avec ListView (et FlatList également).

Je viens de découvrir que je pouvais faire en sorte que la liste s'affiche correctement en réinitialisant ma source de données sur [] dans le constructeur de la vue, puis en la réinitialisant à la liste des éléments dans un setTimeout()

Pour info, ma listview est intégrée dans un ReactNavigation StackNavigator dans un TabNavigator.

De plus, le hack pour déclencher un défilement de 1px par programme fonctionne toujours à la fois pour ListView / FlatList. mais vous devez l'appeler au bon cycle de vie (généralement lorsque vous revenez à l'écran).

@gre : avez-vous une application de repro pour le problème avec FlatList ? J'aimerais que ça soit réparé au plus vite !

@gre , avez-vous un exemple de code pour cela ? Et voulez-vous dire dans componentWillMount pour ce composant englobant un ListView?

@ericvicenti - on dirait qu'il faut pas mal d'autres morceaux de code de RN. J'avais peur qu'il emprunte des morceaux d'ailleurs. Je peux le retirer. Peut-être le jeter dans un dépôt pour que d'autres personnes l'utilisent - est-ce autorisé?

@sahrens désolé c'est dans mon application d'entreprise, mais peut-être que je peux essayer de créer un exemple vierge pour le reproduire !

@natdm un peu au dessus dans un commentaire : https://github.com/facebook/react-native/issues/1831#issuecomment -231069668 – c'est l'idée de base, j'en ai plus ou moins divergé avec un système qui va alterner entre un -1px et 1px pour qu'il n'accumule pas visuellement un scroll au fil du temps XD énorme hack

J'ai ce problème avec SectionList - vide lors du rendu initial jusqu'à ce que je défile. @sahrens y a-t-il un correctif en vue ?

@smkhalsa avez-vous une repro claire? Est-ce que le paramètre removeClippedSubviews={false}

@sahrens Il semble que le paramètre removeClippedSubviews={false} résout ce problème pour moi. Sans cela, j'obtiens un écran vide à chaque fois que je navigue vers cette vue particulière.

Je vais essayer d'isoler le problème dans un nouveau dépôt et de le poster si je peux.

même chose pour moi (removeClippedSubviews est définitivement un déclencheur du bogue). nous venons d'avoir une reproduction facile dans notre application qui contient des listes dans react-native-tab-view . Je ne sais pas cependant si un exemple plus simple le reproduira.

voir les 2 derniers paragraphes de ma réponse ici https://github.com/facebook/react-native/issues/1831#issuecomment -228775913

Je pense que ça pourrait être quelque chose autour de ça (juste une hypothèse):

(1) la liste est rendue dans un onglet d'arrière-plan, car elles sont "hors de la zone de délimitation" removeClippedSubviews supposera qu'elles ne sont pas ici et ne rendra rien (blanc)
(2) lorsque l'onglet se concentre, et parce que cet onglet utilise probablement quelque chose comme un <StaticContainer> , rien n'est "rafraîchi", il est toujours blanc
(3) dès que l'utilisateur « fait défiler », vous actualisez la logique removeClippedSubviews qui détermine maintenant que les cellules de la liste sont visibles et les actualisez.

Merci pour la piste @gre

existe toujours sur RN 0.41.2, android est ok, juste l'ios10, set removeClippedSubviews={false} peut résoudre ce problème. Mon listView est petit, donc pas un gros problème. Le listView à l'intérieur d'un stackNavigator de tabNavigator(react-navigation).

 render() {
    return (
      <View style={{ flex: 1, justifyContent:'center'}}>
        <ListView
          dataSource={this.state.dataSource}
          renderRow={this._renderRow.bind(this)}
          removeClippedSubviews={false}
        />
      </View>
    );
  }

Même problème ici. Rien d'autre à ajouter, à part removeClippedSubviews={false} l'a également résolu pour moi.

@agentilela Merci pour le correctif, même problème ici

Le réglage removeClippedSubviews={false} corrigé

ce problème existe dans react-native-maps MapView que AFAIK n'utilise pas ScrollView et n'a rien à voir avec ListView .

Le problème persiste dans RN44, initialListSize={200} résout le problème, mais je ne pense pas que ce soit une bonne solution à long terme car le rendu prend un certain temps avant de l'afficher. C'est évident dans une vue de liste de plus de 100 lignes.

ps removeClippedSubViews={false} ne résout pas mon problème

removeClippedSubViews={false} fonctionné pour moi pour ListView .
De plus, FlatList a le même problème.

J'ai le même problème avec ListView/FlatList et react-navigation.
Je l'ai corrigé avec lazy: true dans les options de TabNavigator et removeClippedSubViews={false} dans ListView

Je peux également confirmer que le bogue se produit dans RN 0.44.0 :

Se produit lors de l'utilisation de react-navigation + TabNavigator + (ListView ou FlatList).
Lorsque vous accédez à un onglet, il semble vide. Ce n'est que lorsque vous faites défiler un peu que la liste s'affiche.

Le seul onglet où cela ne se produit pas est dans le initialRouteName du TabNavigator

Comme mentionné, définir lazy: true sur . le TabNavigator résout ce problème.

même problème ici, résolu avec removeClippedSubViews
comme décrit dans le numéro en double https://github.com/facebook/react-native/issues/14069
J'ai créé un dépôt pour reproduire le problème https://github.com/jcharlet/react_native_listview_bug si cela peut être utile.

De plus, ce problème ne se produit pas lors de l'utilisation de 'react-native-router-flux' au lieu de 'react-navigation' pour le même cas d'utilisation

Un problème avec la navigation réactive dans TabNavigator. removeClippedSubViews={false} n'aide pas.

Même problème pour moi. Utilisation de react-navigation avec TabNavigator et un StackNavigator en tant qu'enfant dans l'onglet en question, et simple ListView. RN 0.44 / Expo 17, et ni removeClippedSubviews ni paresseux ne m'ont aidé :-/

removeClippedSubviews m'a aidé à corriger la version IOS, mais pour Android, j'ai dû utiliser initialListSize

Avec

"dependencies": {
    "react": "16.0.0-alpha.6",
    "react-native": "0.44.2",
    "react-navigation": "1.0.0-beta.11"
}

et lazy: true dans TabNavigator 's TabNavigatorConfig tout s'affiche bien :

const AppNavigator = TabNavigator({
  HomeTab: {
    screen: HomeScreen,
    path: '/'
  },
  PeopleTab: {
    screen: PeopleNavigator,
    path: '/people',
  }
}, {
  lazy: true
});

const PeopleList = ({ people }) => {
  return (
    <FlatList
      data={people}
      renderItem={({item}) => <Text>{item.name}</Text>}
    />
  );
};

Mise à niveau vers
{
"react-native": "0.44.2",
"react-navigation": "1.0.0-beta.11"
}
a fonctionné pour moi, lazy=true ne semble pas être requis pour StackNavigator

{
"react-native": "0.44.2",
"react-navigation": "1.0.0-beta.11"
}
paresseux=vrai
removeClippedSubViews={false}
ne fonctionne pas

C'est vraiment intéressant, j'aimerais voir quand ce bug de 2 ans sera enfin résolu.

J'ai mis à niveau vers react-navigation 0.44.2, react-navigation 1.0.0-beta.11 et défini "lazy=true" sur le TabNavigator en question et cela l'a corrigé. Peut-être que le simple fait de définir lazy=true aurait fait l'affaire, mais j'avais déjà mis à jour.

@jhalborg J'ai résolu le problème des listes avec FlatList & removeClippedSubViews={false}.

J'utilise react-navigation et removeClippedSubViews fonctionne pour moi avec cette structure :

pile modale -> pile d'onglets actuelle -> inclure plusieurs onglets avec des piles de navigation

Mon problème était le manque de performances, j'ai donc créé la valeur removeClippedSubViews en fonction d'une valeur d'état afin que je puisse l'activer / la désactiver en fonction du chargement ou non de l'écran.

J'ai des listes qui se rechargent sur un autre onglet, j'utilise donc quelque chose comme ce qui suit :

constructor (props) {
   super(props)

   this.state = { removeClippedSubViews: false }
} 

componentDidMount () {
  this.setState({ removeClippedSubViews: true })
}

resetData () {
  const callback = (newRecords) => {
    this.setState({ removeClippedSubViews: true, records: newRecords })
  }

  this.setState({ removeClippedSubViews: false, records: [] }, () => {
    someDataHelper.reloadData(callback)
  })
}

render () {
  return (
    <ListView removeClippedSubViews={this.state. removeClippedSubViews} />
  )
}

J'espère que cela aidera quelqu'un car cela m'ennuyait depuis un certain temps mais s'est avéré être une solution assez simple.

Il semble que ce problème puisse maintenant être clos, pour les raisons suivantes :

• Nous recommandons aux gens d'utiliser FlatList/SectionList maintenant, aucune amélioration ne sera apportée à ListView.
• Il semble qu'une solution de contournement raisonnable ait été identifiée dans le fil.

Les pensées?

N'est-ce pas un vrai bug ? Si oui, pourquoi clore le problème ?

A propos des raisons :

• Cela se produit également sur FlatList, il ne s'agit donc pas uniquement d'un problème de ListView.

• Supprimer removeClippedSubViews semble être un hack avec des coûts de performances, pas une solution de contournement raisonnable à mon avis.

Confirmant qu'il s'agit toujours d'un bogue actif dans FlatList/SectionList.

Il existe également quelques problèmes liés aux performances de FlatList/SectionList, ce qui signifie que certaines personnes ne peuvent pas encore quitter ListView, il semble étrange de l'avoir déjà déprécié.

Est-ce que quelque chose comme ce que j'ai posté ci-dessus pourrait être intégré dans les composants eux-mêmes ?

Quels problèmes avez-vous rencontrés lors de la migration de ListView ?

13727

Je ne vois pas de détails sur l'endroit où ListView est meilleur. Notez que vous pouvez augmenter la taille de la fenêtre ou désactiver la virtualisation si cela vous pose problème, car ListView ne fait rien de tout cela.

J'attendrais qu'ils répondent aux questions que vous venez de poser avant de passer à autre chose, mais ce n'est pas le sujet, ce problème se produit toujours sur FlatList et devrait rester ouvert.

Juste pour la connaissance générale de la communauté.

J'ai rencontré ce problème dans mon scénario où j'utilise Nested ListView, c'est-à-dire ListView dans une ligne ListView. Ma solution a été corrigée en appliquant removeClippedSubviews={false} aux ListView imbriqués.

react-native-cli: 2.0.1
react-native: 0.41.2

Il est impossible d'avoir un défilement fluide dans de grandes listes en utilisant ListView / FlatList / VirtualizedList / WindowedListView (quel que soit) dans un ancien matériel comme l'iPad 3 / iPad Mini sous iOS 9.x.

Remarque : je parle de listes plates, pas d'images, uniquement des composants de texte en lignes.

Quelqu'un pourrait partager un exemple fonctionnel avec un ensemble de données de 7000 enregistrements où le défilement est fluide et non saccadé, j'essaye toutes les configurations d'attributs et pas de chance 😢

D'accord - J'efface également les cellules hors de vue pour la gestion de la mémoire. Il est dommage qu'un composant aussi essentiel dans de nombreuses applications manque autant de performances pour de nombreux cas d'utilisation. Je vais m'y plonger au cours de la semaine prochaine pour voir s'il y a des gains de performances significatifs à faire.

Le 10 juin 2017, 15h30 +1000, Ariel Falduto [email protected] , a écrit :

Il est impossible d'avoir un défilement fluide dans de grandes listes en utilisant ListView / FlatList / VirtualizedList / WindowedListView (quel que soit) dans un ancien matériel comme l'iPad 3 / iPad Mini sous iOS 9.x.
Remarque : je parle de listes plates, pas d'images, uniquement des composants de texte en lignes.
Quelqu'un pourrait partager un exemple fonctionnel avec un ensemble de données de 7000 enregistrements où le défilement est fluide et non saccadé, j'essaye toutes les configurations d'attributs et pas de chance 😢
-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

Génial @lprhodes , je partage ici un cas d'utilisation simple utilisant FlatList avec ~ 200 enregistrements, cet exemple est saccadé sur un iPad 3 avec iOS 9.

import React, { Component } from 'react';
import {
  FlatList,
  StyleSheet,
  View,
} from 'react-native';
import Expo from 'expo';
import {
  Text,
  ListItem,
  SearchBar,
} from 'react-native-elements';

class Feed extends Component {

  loadFeed() {
    const {data} = this.props;
    const sections = [];
    data.forEach((value, index) => {
      const sectionName = value.name_line_sp;
      const section = sections.find((section) => {
        return section.title === sectionName;
      });
      if (section) {
        section.data.push(value);
      } else {
        sections.push({
          title: sectionName,
          data: [value]
        });
      }
    });
    if (__DEV__) {
      console.log('Sections size', sections.length);
    }
    return sections[0];
  }

  componentDidMount() {
    this.flatListRef.scrollToOffset({
      animated: false,
      offset: 48
    });
  }

  render() {
    const feed = this.loadFeed();
    return (
      <View style={{flex: 1}}>
        <Text h5 style={styles.section_title}>{feed.title} ({feed. data.length})</Text>
        <FlatList
          style={{flex: 1}}
          ref={(list) => { this.flatListRef = list; }}
          debug
          ListHeaderComponent={() => (
            <SearchBar
              lightTheme
              placeholder='Search...' />
          )}
          data={feed.data} // ~217 records
          keyExtractor={(item) => (
            item.code_group
          )}
          renderItem={({ item }) => {
            return (
              <ListItem
                hideChevron
                key={item.code_group}
                title={`${item.name_group_sp}`}
                subtitle={`${item.price_prod}`}
                containerStyle={{ backgroundColor: 'white' }}
              />
            );
          }}
        />
      </View>
    )
  }
}

import catalog from './data/catalog.json'; 

class App extends Component {
  render() {
    const data = catalog;
    return (
      <View style={styles.container}>
        <Text h3 style={styles.title}>Skillcase</Text>
        <Feed data={data} />
      </View>
    );
  }
}

const styles = StyleSheet.create({
  title: {
    margin: 20,
    marginBottom: 10,
    color: 'white'
  },
  section_title: {
    padding: 20,
    color: 'white',
    backgroundColor: '#1976D2',
  },
  container: {
    flex: 1,
    paddingTop: Expo.Constants.statusBarHeight,
    backgroundColor: '#42A5F5',
  },
});

Expo.registerRootComponent(App);

ou expo uri : exp://8v-xvw.outatime.skillcase.exp.direct :80

Merci !!!

Votre exemple de code contient de nombreuses mauvaises pratiques qui sont abordées dans la documentation. Par exemple, vous recréez et reliez constamment des fonctions, ce qui représente une taxe sur le processeur et entraîne des rendus inutiles de vos éléments de liste. Vous devez vous assurer que votre composant ListItem est un PureComponent, et assurez-vous que tous les accessoires qui lui sont transmis restent peu profonds égaux pour éviter les re-rendus inutiles. C'est également une bonne pratique pour le reste de votre application.

Cela devrait beaucoup aider, mais je ne peux pas garantir des performances parfaites sur les appareils lents. Dans quelle mesure les autres applications telles que le navigateur Web fonctionnent-elles mieux sur ces appareils ?

@outaTiME vous ne devriez pas non plus appeler loadFeed à chaque rendu

La méthode de rendu

import React, { Component, PureComponent } from 'react';
import {
  FlatList,
  ListView,
  Text,
  StyleSheet,
  View,
} from 'react-native';
import Expo from 'expo';
import {
  ListItem,
  SearchBar,
} from 'react-native-elements';

class FeedRow extends PureComponent {

  render() {
    const item = this.props.data;
    return (
      <Text>{item.name_group_sp}</Text>
    )
  }

}

class Feed extends Component {

  constructor(props) {
    super(props);
    this.storeListRef = this.storeListRef.bind(this);
  }

  loadFeed() {
    const {data} = this.props;
    const sections = [];
    data.forEach((value, index) => {
      const sectionName = value.name_line_sp;
      const section = sections.find((section) => {
        return section.title === sectionName;
      });
      if (section) {
        section.data.push(value);
      } else {
        sections.push({
          title: sectionName,
          data: [value]
        });
      }
    });
    if (__DEV__) {
      console.log('Sections size', sections.length /*, images.length */);
    }
    return sections[0];
  }

  componentDidMount() {
    this.flatListRef.scrollToOffset({
      animated: false,
      offset: 48
    });
  }

  renderItem(item) {
    return (
      <FeedRow data={item.item} />
    );

  }

  keyExtractor(item) {
    return item.code_group;
  }

  listHeaderComponent() {
    return (
      <SearchBar
        lightTheme
        placeholder='Buscar...' />
    );
  }

  storeListRef(list) {
    this.flatListRef = list;
  }

  render() {
    const feed = this.loadFeed();
    return (
      <View style={{flex: 1}}>
        <Text h5 style={styles.section_title}>{feed.title} ({feed. data.length})</Text>
        <FlatList
          style={{flex: 1}}
          ref={this.storeListRef}
          debug
          // pagingEnabled
          ListHeaderComponent={this.listHeaderComponent}
          data={feed.data} // ~217 records
          keyExtractor={this.keyExtractor}
          renderItem={this.renderItem}
        />
      </View>
    )
  }

}

import catalog from './data/catalog.json';

class App extends Component {

  render() {
    const data = catalog;
    return (
      <View style={styles.container}>
        <Text h3 style={styles.title}>Skillcase</Text>
        <Feed data={data} />
      </View>
    );
  }

}

const styles = StyleSheet.create({
  title: {
    margin: 20,
    marginBottom: 10,
    color: 'white'
  },
  section_title: {
    padding: 20,
    color: 'white',
    backgroundColor: '#1976D2',
  },
  container: {
    flex: 1,
    paddingTop: Expo.Constants.statusBarHeight,
    backgroundColor: '#42A5F5',
  },
});

Expo.registerRootComponent(App);

Mieux, mais la définition de debug ralentira énormément les choses. Vous devez également vous assurer que vous exécutez une version de production optimisée, et non une version de développement/débogage, lors de l'évaluation des performances. Enfin, vous créez toujours un nouvel objet de style à chaque rendu et vous pouvez utiliser initialScrollPosition au lieu d'appeler scrollToOffset dans onMount.

@sahrens yup sans le drapeau debug et avec une production optimisée, la construction fonctionne mieux et moins saccadée, comme je l'ai dit avant d'utiliser expo 17 qui utilise react-native 0.44, je suppose que la nouvelle version de react-native (0.45 ) a des améliorations sur le FlatList .

d'ailleurs, pourquoi les styles créent-ils dans chaque rendu ? dans ce cas le rendu avec les styles flex (dans le composant Feed ) est exécuté une seule fois :

1. App rendu
2. Feed rendu
3. Puis plusieurs FeedRow rendus

Très similaire à ce que @lprhodes m'a dit à propos du loadFeed sur chaque rendu, je comprends que le rendu Feed n'est exécuté qu'une seule fois, est-ce correct ?

Quand vous dites initialScrollPosition vous voulez dire initialScrollIndex n'est-ce pas ? ça ne marche pas comme scrollToOffset je dois cacher le ListHeaderComponent (48px de hauteur) quand Feed monte

Qu'en est-il de cet avertissement de la console ? j'utilise un PureComponent pour renderItem, non?

VirtualizedList: You have a large list that is slow to update - make sure your renderItem function renders components that follow React performance best practices like PureComponent, shouldComponentUpdate, etc. {"dt":85588,"prevDt":1497296394821,"contentLength":10023}

Merci !!

Cet avertissement est une sorte de bogue qui a été corrigé sur master, mais 85 secondes pour votre montage initial sont incroyablement lents - vous devriez vraiment creuser plus profondément dans votre code pour comprendre ce qui prend si longtemps. Il existe de nombreuses ressources si vous recherchez sur Google les performances de réaction ou si vous demandez de l'aide dans la communauté React au sens large.

Et oui, je voulais dire initialScrollIndex . Vous devrez implémenter getItemLayout pour que cela fonctionne, ce qui devrait représenter ListHeaderComponent .

super @sahrens , j'ai peur de l'ancien matériel comme l'iPad 3 ou la version OS iOS 9 ... tester sur des appareils plus récents il n'y a pas de problèmes de performances, je voulais savoir si quelqu'un d'autre rencontrait le même problème matériel ... Dans un certain temps Je demanderai à la communauté de voir si j'arrive à quelque chose de plus profond, merci !!!

Salut le mien corrigé en donnant style={{ backgroundColor: 'white' }} à la liste plate

Alors @hramos & @sahrens , quelle est exactement la meilleure solution de contournement pour ce problème avec FlatList ? Se heurter à cela avec réagir 0.44.0 utilisant react-native-tab-vew , et ce n'est pas vraiment clair ce que l'équipe principale recommande pour le moment.

@sjmueller ne @sahrens disent que cela est déjà fixé dans le maître?

@hramos Je viens de revoir tout ce fil. Je l'ai peut-être manqué, mais nulle part je n'ai vu @sahrens mentionner que FlatList devenant invisible est corrigé sur le maître. Je n'ai pas non plus vu de commit/PR faisant référence à ce problème, et enfin aucune solution de contournement recommandée pour résoudre le problème.

Je vois que @yaronlevi recommande de définir lazy={true} sur react-native-tab-view ou TabNavigator , mais cela provoque des retards nerveux même sur un iPhone 7 plus.

@knappdev dit que cela fonctionne sans lazy sur 0.44.2 et au-delà, donc je vais essayer de mettre à niveau à partir de 0.44.0 et voir si j'ai du succès.

Mon travail consiste à activer/désactiver removeClippedSubviews selon que la liste à plat est utilisée ou non.

  constructor (props) {
    super(props)

    this.state = { removeClippedSubviews: false }

    this._disableRemoveClippedSubviews = this._disableRemoveClippedSubviews.bind(this)
    this._onViewableItemsChanged = this._onViewableItemsChanged.bind(this)
    this._renderItem = this._renderItem.bind(this)
  }

  _disableRemoveClippedSubviews () {
    this.setState({ removeClippedSubviews: false })
  }

  _onViewableItemsChanged({ viewableItems, changed }) {
    if (!this.state.removeClippedSubviews) this.setState({ removeClippedSubviews: true })
    if (this._disableRemoveClippedSubviewsTimeout) clearTimeout(this._disableRemoveClippedSubviewsTimeout)
    this._disableRemoveClippedSubviewsTimeout = setTimeout(this._disableRemoveClippedSubviews, 3000)
  }

  render () {    
    const { removeClippedSubviews } = this.state

    return (
      <FlatList
        renderItem={this._renderItem}
        removeClippedSubviews={removeClippedSubviews}
        onViewableItemsChanged={this. _onViewableItemsChanged}
      />
    )
  }

removeClippedSubviews est désormais désactivé par défaut pour FlatList.

Pour les problèmes sur les appareils lents, avez-vous essayé l'application RNTester FlatListExample ?

Comment FlatListExample fonctionne-t-il pour vous ?

removeClippedSubviews est désormais désactivé par défaut pour FlatList.

Ouais - c'est pourquoi je l'allume lorsque le défilement est en fait. J'ai moins de tremblements aléatoires de cette façon.

Je remplace ensuite les cellules (loin) hors de vue par des cellules vides afin de réduire davantage la mémoire entendue que FlatList ne le fait par elle-même

Donc, enfin, toujours aucun moyen de le réparer au lieu d'utiliser removeClippedSubviews={false} même si cela coûte si cher en performances ?

Le correctif pour moi était de désactiver le débogage js à distance pour le simulateur ios

Le réglage lazy: true semble avoir fonctionné pour moi. Je n'ai pas encore testé les performances.

Je résous ce problème par removeClippedSubViews={false}

MEILLEUR TRAVAIL AUTOUR
Fonctionne sur tous les matériels/simulateurs. removeClippedSubViews={false} ne fonctionne pas toujours sur iPhone 7.

Assurez-vous de forcer le mouvement dans la vue de liste.

componentDidMount() {
   requestAnimationFrame(() => {
      // HACK TO RELOAD DATA
      this.refs._list.scrollTo({x: 1, y: 0, animated: false})
    });
}

Exemple de référence.

 <ListView
     ref="_list"
     dataSource={this.state.dataSource}
     renderRow={(data, sectionId, rowId) => <Row
        rowId={rowId}
        selectedRow={this.state.selectedRow}
        onPressRow={this._pressRow.bind(this)}
        {...data}/>}
     renderSeparator={(sectionId, rowId) => <View key={rowId} style={styles.separator} />}
     removeClippedSubViews={false}
     initialListSize={SortedBrandList.count}/>

Le problème est qu'il a peut-être déjà été monté

Le 24 août 2017, à 15h44, Peter Suwara [email protected] a écrit :

SOLUTION DE CONTOURNEMENT
Fonctionne sur tous les matériels/simulateurs.

'''componentDidMount() {
requestAnimationFrame(() => {
// HACK POUR RECHARGER LES DONNÉES
this.refs._list.scrollTo({x : 1, y : 0, animé : faux})
});
}'''

'''
ref="_list"
dataSource={this.state.dataSource}
renderRow={(données, sectionId, rowId) => }
renderSeparator={(sectionId, rowId) => }
removeClippedSubViews={false}
initialListSize={SortedBrandList.count}
/>'''

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

J'ai résolu ce problème, au moins sur le simulateur, avec :

<ListView removeClippedSubViews={false} .... />

Je suppose ici que la routine qui gère les sous-vues coupées ne vérifie pas correctement les limites lorsque ListView n'est pas actuellement à l'écran. Cela se produit assez souvent avec n'importe quel composant ListView qui s'affiche hors écran puis se déplace à l'écran. Cela ne devrait pas être un bug trop difficile à corriger.

Je suis presque sûr que cette fonction est le problème : https://github.com/facebook/react-native/blob/master/React/Views/RCTView.m#L321 -L369

Je suppose que l'espace de coordonnées qu'il mesure est incorrect quelque part. En le regardant maintenant.

C'est peut-être la solution ? https://github.com/facebook/react-native/pull/15669/files

Toujours pas de solution pour ça ?

@petersuwara : ce que vous avez proposé de travailler. Merci. @MattFoley : Quand votre correctif sera-t-il disponible en téléchargement ?

Pas spécifique uniquement à FlatList, semble également poser un problème pour le charger dans une ListView.
J'ai trouvé une solution de contournement en utilisant un léger retard dans la définition de la source de données.

Lorsque les données sont chargées à partir d'une source distante dans la méthode componentWillMount, le code suivant est exécuté.
Semble fonctionner :

setTimeout(function(){
       this.updateDataSource(array,newArray)
},30)

updateDataSource = (comments,dataSource) =>{
        this.setState({
            allComments:comments,
            dataSource: this.state.dataSource.cloneWithRows(dataSource),
            isLoading:false

        })
}

Et pendant le léger délai, vous pouvez toujours afficher un écran de chargement. Il est si court qu'il n'est même pas visible.

J'ai trouvé la méthode de @nathvarun pour fonctionner. Il semble y avoir une condition de concurrence entre le thread de montage du composant et le thread de la source de données de mise à jour du composant. Si c'est effectivement le cas, je ne comprends pas pourquoi cela se produirait puisque les deux threads devraient jouer séquentiellement bien l'un avec l'autre.

Cela se produit dans les composants déjà montés, tels que les écrans affectés aux onglets dans la navigation de réaction, mais qui sont plus actuellement sélectionnés - je ne sais donc pas comment une modification de componentWillMount pourrait résoudre ce problème.

Mon RP ci-dessus semble avoir résolu le problème, mais je n'ai pas eu de chance de le fusionner. Est-ce que quelqu'un d'autre aimerait intervenir sur ce RP ?

@MattFoley Que

Configurer le TabNavigator de react-navigation pour qu'il soit lazy: true fonctionne également... Mais ce serait bien de voir cela corrigé par react-native .

Si vous utilisez SectionList ou Flatlist, utilisez simplement ref = {(ref)=> this.sectionList = ref }
et dans votre code this.sectionList.recordInteraction() - devrait rendre votre vue

Le correctif proposé par @MattFoley a été fusionné et fait désormais partie de la version 0.50 : https://github.com/facebook/react-native/commit/03ae65bc25185fe6d7f62e66f5575ced5c3e8378

Je viens de mettre à jour et je vois toujours ce problème sur <ListView /> . Est-ce que je fais quelque chose de mal? Voici mon package.json :

  "dependencies": {
    "native-base": "^2.3.1",
    "react": "^16.0.0",
    "react-native": "^0.50.0-rc.1",
    "react-native-linear-gradient": "^2.3.0",
    "react-native-modal": "^4.1.0",
    "react-native-simple-store": "^1.3.0",
    "react-navigation": "^1.0.0-beta.11"
  },

Je pense que ListView est obsolète maintenant. il vaut mieux essayer avec FlatList et voir ce qui se passe.

Je crois que nous voyons toujours cela sur 0.50.3. Quelqu'un d'autre peut-il confirmer ?

J'ai résolu ce problème en passant à FlatList.
Le vendredi 17 novembre 2017 à 8h39 Colin Ramsay [email protected]
a écrit:

Je crois que nous voyons toujours cela sur 0.50.3. Quelqu'un d'autre peut-il confirmer ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/facebook/react-native/issues/1831#issuecomment-345294840 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAZnGZ9oz7uKXx-wz3KFg-FSizejAfM6ks5s3bavgaJpZM4FP1nt
.

Ah, nous utilisons déjà FlatList.

C'est toujours un problème avec 0.50.3. removeClippedSubviews ne semble pas avoir d'effet. Pouvons-nous rouvrir cela s'il vous plaît?

Nous avons encore un problème en 0.50.3. Veuillez rouvrir celui-ci.

Désolé de vous déranger à nouveau, mais pouvons-nous rouvrir cela s'il vous plaît ? C'est un problème urgent.

J'ai rencontré cela à l'aide du dernier SDK natif d'Expo React. Cela n'arrive qu'au troisième ListView dans un TabNavigator. Si j'échange la 2e et la 3e, la nouvelle 3e page sera affectée. removeClippedSubviews l'a cependant corrigé dans mon cas.

requestAnimationFrame(() => { this.listview.scrollTo({y: 1}); }); fonctionné pour moi.

utiliser this.listView.scrollToEnd() n'a pas fonctionné , j'ai donc dû calculer manuellement les coordonnées de la fin de la liste pour ensuite passer à scrollTo()

Pour flatlist, cela peut être dû à la mise à jour du même tableau. FlatList vérifie si les données sont différentes. Alors utilisez des tableaux immuables

removeClippedSubviews={false} corrige le bogue pour mon cas.

<ListView
            data={this.state.mockData}
            renderRow={(rowData) => this.renderRow(rowData)}
            removeClippedSubviews={false}
 />

@edmengel a raison. Je travaillais sur un projet et j'ai eu exactement le même bug.

Avant de faire défiler :

Après le défilement :

React-native-router-flux@^4.0.0-beta.27 est utilisé pour la navigation et App.js le renvoie. Ma page de recherche contient une liste et il y avait ce bogue. C'est sur le troisième onglet.

<Provider store={store}>
        <View style={{flex: 1}}>
            <Router hideNavBar={true}>
                <Scene key="modal" modal>
                    {/* Tab Container */}
                    <Scene key="tabbar" tabs={true} tabBarPosition="bottom" tabBarStyle={{borderTopColor:'black', borderTopWidth:1,backgroundColor:'white'}}>
                      {/*Tabs */}
                        <Scene key="NewPage" component={NewPage} title="NewPage" icon={TabIcon}  hideNavBar={true} />
                        <Scene key="NewPage2" component={NewPage2} title="Newpage2" icon={TabIcon}  hideNavBar={true} />
                        <Scene key="SearchPage" component={SearchPage} title="Search"  hideNavBar={true} />
                    </Scene>
                </Scene>
            </Router>
        </View>
</Provider>

Lorsque j'ai changé la page de recherche (qui contient une liste) du troisième onglet au deuxième onglet, la liste a bien fonctionné.

Trouvé un Hack de travail pour cela.

render() {
       setTimeout(() => {
            this.sectionList && this.sectionList.recordInteraction(); 
        }, 50);
        return (
            <SectionList ref={(view) => { this.sectionList = view }} />
        )
}

<Flatlist style={{ flex: 1 }}/>
Cette astuce fonctionne pour moi.

Même problème sur 0.55.4 avec à la fois ScrollView et ListView . L'ajout de removeClippedSubviews={false} fonctionne.

Malheureusement, dans notre cas, ce n'est pas une option, car elle est nécessaire pour éviter de manquer des images sur Android https://github.com/facebook/react-native/issues/13600#issuecomment -315629140

Le défilement d'avant en arrière sur le rendu ne se produit qu'après la navigation, cela ressemble donc à une transition vers un écran initialement vide.

Flexion de la vue n'a pas aidé non plus.

D'autres suggestions?

J'ai trouvé que cela ne se produisait qu'après une certaine position de défilement ...
https://streamable.com/l5arv

En utilisant chrome-devtools pour inspecter la vue, je peux voir que toutes les sous-vues sont coupées.

Toujours bloqué, @hramos s'il vous plaît

Vous avez toujours un problème avec une fonction aussi simple ? C'est pourquoi nous sommes passés de React Native au code natif pur.

Si c'est aussi simple, donnez un coup de main pour le réparer @petersuwara

Ce problème est clos depuis un moment. Si cela vous concerne, _veuillez ouvrir un nouveau numéro_ et fournissez autant de détails que possible. Je verrouille ce problème car le problème d'origine signalé ici a été résolu, et il n'est pas clair que chaque personne qui a commenté par la suite soit confrontée au même problème.

Nous utilisons FlatList _largement_ sur Facebook, et aucune plainte de ce genre n'a fait surface en interne. Il est possible que ce type de problème se produise avec une bibliothèque de navigation particulière, par exemple. L'ouverture d'un nouveau numéro avec plus d'informations sur votre problème, avec une liste claire des étapes à reproduire, ou idéalement un petit projet, serait d'une grande aide.