@oliviertassinari envisageriez-vous d'ajouter un conteneur virtuel au corps pour augmenter les performances lors du rendu de longues listes sans pagination?
Je vais essayer si vous pouviez juste me diriger dans la bonne direction ( react-virtualized
?)
Nous espérons que l'API actuelle permettra une intégration simple avec react-virtualized
. Nous sommes ouverts à toute modification de l'implémentation afin de simplifier l'intégration.
Avoir un exemple de démonstration dans les documents serait génial.
Si cela peut vous aider, voici un exemple d'intégration avec la liste / menu https://codesandbox.io/s/oQ0nkl5pk.
@oliviertassinari Je l'ai fait sans react-virtualized
parce que c'était un gâchis et qu'il ne fonctionnait pas bien avec les composants mui.
De plus, ma solution actuelle est un corps à tête fixe et défilable pur-css avec une hauteur de table dynamique et une largeur de colonnes dynamique (testé également sur Safari).
Le thead toujours sur le dessus avec un corps déroulant est un must pour les grilles de données.
J'ajoute un anti-rebond du défilement, peaufine les performances et corrige un problème, mais cela fonctionne très bien: je suis "virtuellement" en train de rendre environ 2400 lignes, tellement fluide.
Questions sur les composants Table
:
ref
avec des composants MUI? Je calcule automatiquement TableThead
hauteur: le problème est que<TableHead ref={ ref => this.tableThead = ref }>
ne renvoie pas l'élément conteneur DOM réel de TableThead
mais l'instance React (comportement natif de React lors de l'application de ref
sur un élément non-DOM) car c'est quelque chose qui devrait être appliqué dans le TableThead
composant lui-même; d'autres composants peuvent en avoir besoin, alors pourquoi ne pas avoir un refHandler
sur chaque composant MUI qui applique le rappel donné dans le premier élément rendu? (J'espère avoir réussi à expliquer cela @ _ @)
Ma solution actuelle est bizarre
const theadHeight = ReactDOM.findDOMNode(this.tableThead).clientHeight; // eslint-disable-line react/no-find-dom-node
ce qui signifie utiliser le findDomNode
obsolète et désactiver également eslint.
pourquoi border-bottom
appliqué sur des cellules plutôt que sur des lignes?
Qu'en est-il d'avoir un accessoire stripe={true}
pour rayer automatiquement les lignes TableBody
?
pourquoi .MuiIconButton.root
a-t-il une propriété de style zIndex? 🤔
J'espère publier quelque chose de stable à ce sujet bientôt afin que vous puissiez y jeter un coup d'œil, c'est quelque chose qui peut être adopté de manière générale.
Désolé de déranger autant mais j'utilise beaucoup mui @ next donc je repère beaucoup de cas d'utilisation!
Je l'ai fait sans réagir-virtualisé parce que c'était un gâchis et qu'il ne jouait pas bien avec les composants mui.
Oh, c'est dommage pour nous. Une idée de ce que nous pourrions faire est possible?
Vous pouvez essayer le innerRef
pour obtenir une référence sur le TableHead
. ref
vous obtiendra une référence sur le composant withStyles(TableHead)
. Si cela ne fonctionne pas, nous pourrions exposer une propriété rootRef
. C'est un modèle que nous utilisons déjà.
Aucune idée
~~Oh, c'est dommage pour nous.
En fait, c'est un mélange de react-virtualized
propres conteneurs, d'éléments natifs table/thead/tbody
DOM et de la nécessité d'avoir un tbody
défilant qui a causé le problème.
Trop de travail était nécessaire: créer simplement une solution ad-hoc pour MuiTable
était un jeu d'enfant.
exposer un rootRef
serait génial (en supposant que l'élément principal TableThead
dans la méthode render
est l'élément Thead
DOM lui-même)
faut-il alors déplacer border-bottom
vers tr
? Dois-je déplacer cela dans un numéro dédié?
Je veux dire des lignes rayées: facile à réaliser avec like tr:nth-child(odd) { backgroundColor: f2f2f2
mais puisque nous avons déjà la coloration pratique hover={true}
pourquoi ne pas avoir la pratique striped={true}
? :)
génial!
TableCell
.ref={rootRef}
sur chaque composant.<FormControl ref={rootRef} ...>
renverra à nouveau une référence au composant React (car FormControl
n'est pas un élément DOM) et demandera au développeur d'utiliser la solution de contournement que j'ai dû utiliser.rootRef
se comporte comme suit:Le conteneur du composant rendu est-il un élément DOM?
ref={rootRef}
rootRef={rootRef}
dessus => qui va se propager jusqu'au premier élément DOM: de cette façon, le codeur aura toujours la vraie référence DOMLa solution fourre-tout à laquelle je peux penser est d'avoir les propriétés muiRef
et rootRef
où le premier applique le rappel au conteneur "mui component" (le cas échéant) et le second applique le rappel lorsque je dit avant.
De cette façon, le développeur peut facilement avoir à la fois / soit la référence MUI et la référence DOM (tout ce dont il a besoin, quand il en a besoin).
Pensez-vous que cela a du sens?
vraiment? @ _ @
ops! J'oublie toujours les spécifications matérielles
ref
et une propriété rootRef
ref
et appliquez-le sur l'élémentrootRef
et l'applique en tant que référence sur le composant racine Cref
et appliquez-le sur l'élémentMais que se passe-t-il si le composant C a également une propriété rootRef?
Le composant A peut être sur le terrain de l'utilisateur, le composant B peut être le TextField et le composant C peut être le FormControl.
Donc ma réponse, au début, nous avons introduit rootRef
comme une simple aide. Nous n'avons pas pensé à l'industrialisation. Donc, je pense que le comportement actuel est excellent car déterministe, simple et sans la limitation que vous décrivez, si les gens sont intéressés à accéder à l'élément dom sous-jacent, ils peuvent utiliser l'API findDOMNode .
@damianobarbati Est -ce que react -virtual-list l'expérience avec Table et virtualisation est mentionnée ici ?
Je suppose que listComponent = TableBody, itemComponent = TableRow?
J'ai commencé ce projet qui utilise React-virtualized avec Material 1.0 qui pourrait vous intéresser.
https://github.com/techniq/mui-table
C'est toujours un travail en cours (voir https://github.com/techniq/mui-table/blob/master/TODO.md) mais pourrait vous être utile. Les documents manquent, mais jetez un œil aux histoires pour avoir une idée de la façon de l'utiliser.
@techniq Cela semble prometteur 😄! Je pense que ce serait bien de réorganiser la section de documentation de table à un moment donné pour avoir:
- https://github.com/DevExpress/devextreme-reactive~~ (licence commerciale)
Nous pouvons également l'ajouter à la section https://material-ui-next.com/discover-more/related-projects/#material-ui-specific-projects.
Alors, faites-nous savoir quand le projet est plus mature. Je pense que nous pouvons accepter une pull request pour promouvoir le projet :).
J'ai fait un PR pour react-virtual-list
ici https://github.com/clauderic/react-tiny-virtual-list/pull/30 qui permet son utilisation avec material-ui. J'ai eu du mal à faire fonctionner react-virtual et à créer du HTML valide car il a un code en dur de div
.
cc: @kgregory
@eyn beau travail! Je viens de terminer une implémentation d'une table à défilement infini en utilisant react-virtualized et material-ui. J'espère jeter un résumé ensemble bientôt. Lorsque je le ferai, je le lierai ici pour tous les futurs visiteurs de ce numéro et éventuellement à titre d'exemple dans la documentation.
@kgregory avez-vous fini votre essentiel? Je suis toujours à la recherche d'une solution basique pour la table d'interface utilisateur matérielle virtualisée et ce n'est pas facile à trouver ... Ce serait d'une grande aide!
Merci pour votre travail!
@neofox Non, désolé. Je n'y suis jamais parvenu, mais votre réponse est un bon rappel. Je vais essayer de trouver le temps de mettre quelque chose ensemble.
@oliviertassinari votre exemple dans l'un des premiers commentaires qui montre censément comment utiliser la liste de matériaux avec la liste virtualisée de réaction ne fonctionne pas. Avez-vous toujours cet exemple?
@rolandjitsu Désolé, je n'ai pas d'exemples. C'est le sujet de ce problème :).
@oliviertassinari l'a compris. Je pensais que ce problème concernait la table et non le <List>
, ou qu'il couvre également les listes?
@rolandjitsu La liste, le tableau, le papier, la liste quadrillée. C'est tout pareil. Ce problème concerne l'ajout d'une démo simple afin que les gens puissent voir le modèle et l'appliquer à différents composants. La table est un composant dont vous aurez probablement besoin de virtualisation.
@oliviertassinari Je voudrais donner une chance à cela, si vous pouvez me diriger dans la bonne direction. Pour autant que je sache, nous avons besoin d'un élément essentiel avec material-ui @ next intégré à react-virtualized?
@ hassan-zaheer Oui, je pense qu'une simple démo avec react-virtualized à la fin de la page de documentation des tables fera l'affaire :).
Salut. Arrive à tomber sur ce fil lors de la recherche de mon projet. Je voudrais savoir s'il y a une mise à jour ici concernant la démo ou la documentation d'utilisation? @kgregory Ou pouvez-vous nous donner un aperçu de l'intégration des deux? Ce serait bien de rendre la table cohérente avec le style
@ zd-project Vous pouvez jeter un oeil à mon projet mui-virtualized-table .
Auparavant, c'était mui-table
exploite directement le DOM et vous permet d'utiliser des choses comme position: sticky
et <table>
(étendues de lignes / colonnes, largeurs automatiques, etc.) qui étaient difficiles avec react-virtualized.
Cela dit, mui-virtualized-table
vient d'ajouter le redimensionnement de la
Où en sommes-nous sur ces gars?
@techniq , merci pour mui-virtualized-table
! C'est bien! Y a-t-il une chance que nous puissions le fusionner en mui-org/material-ui
?
Je serais heureux si quelqu'un ouvrait un PR qui présente une démo à la documentation. De cette façon, nous pourrions examiner si nous pouvons améliorer l'API de table pour une meilleure intégration avec les stratégies de virtualisation.
@mastertinner Pourquoi avons-nous besoin d'ajouter ceci au noyau? La virtualisation est une stratégie d'optimisation. Tout le monde ne rend pas de grands ensembles de données, donc je ne chargerais pas le paquet de tout le monde avec.
@mastertinner Nous pourrions commencer par référencer le projet dans la documentation, par exemple ici: https://material-ui.com/demos/tables/#advanced-use-cases :)
👍 ressemble à un plan
@mastertinner Bien que je l'utilise encore (lorsque la virtualisation est nécessaire), j'utilise également ma nouvelle mui-table lorsque je n'ai pas besoin d'une virtualisation, et je peux tirer parti du dom (en utilisant table
, tr
, td
, ou grille css pour la mise en page, supprimant le besoin de largeurs de colonne explicites, etc.) et active certains modèles avancés comme plusieurs en-têtes position: sticky
(comme celui-ci )
@rogerstorm a financé ce numéro avec 30 $. Voir sur IssueHunt
Décidé de jouer avec ça aujourd'hui, je ne recommande pas 😭 Voici ce que j'ai produit jusqu'à présent:
Veuillez excuser le décalage, mon ordinateur portable n'est pas génial 👎 Il utilise des composants Material-UI et des composants react-virtualized
@joshwooding J'ai fait exactement la même chose que vous avez fait, virtualisé + en-tête fixe (avec barre de défilement sur le corps uniquement) . Si votre implémentation utilise deux <Table>
séparés, alors je pense que vous avez les mêmes problèmes que j'ai trouvés.
numeric
) ne fonctionnent pas, car vous pourriez utiliser un composant comme <div>
pour la mise en page à l'intérieur de <TableCell>
.td
et tr
pour travailler correctement virtualisé. Il n'y a aucun moyen de donner height
ou max-height
à td
et tr
et le matériel <TableCell>
a son propre remplissage, les choses de marge donc il fait il est difficile de fixer la hauteur de la ligne.Eh bien, le point est qu'un composant à l'intérieur de <TableCell>
est inévitable. Je me demande si vous avez résolu ce problème de manière élégante. Sinon, je pense que l'en- tête virtualisé + fixe (avec une barre de défilement sur le corps uniquement) est difficile d'être un petit composant (aussi petit que sa fonction), bien défini.
@worudso Actuellement, il n'utilise qu'un seul <Table>
J'ai besoin de trouver un moyen de transmettre le numérique mais je pourrais peut-être le faire fonctionner. Ce n'est certainement pas un petit composant et mon code est encore un peu partout mais je vais y travailler un peu plus et voir si je peux l'affiner
J'ai créé un bac à sable qui illustre l'utilisation de material-ui et réagit-virtualisé pour produire une table virtualisée. Cet exemple particulier utilise react-virtualized pour dimensionner la table à la hauteur de la fenêtre.
Le composant MuiVirtualizedTable
de l'exemple est également disponible dans cet article .
MuiVirtualizedTable
peut accepter n'importe quel accessoire supporté par une table . Le rowClassName
n'est pas directement appliqué, mais est à la place appliqué en plus d'autres styles définis dans le MuiVirtualizedTable
.
Le prop columns
attend un tableau d'objets qui est utilisé lors du rendu des cellules pour chaque colonne. Chaque objet peut accepter n'importe quel accessoire pris en charge par Column .
Mes excuses pour avoir pris si longtemps. J'ai été occupé.
Pour info, il y a maintenant aussi react-window
qui est censé être le successeur de react-virtualized
. Au cas où quelqu'un voudrait essayer celui-là.
@kgregory Merci d'avoir partagé les codesandbox.
@joshwooding Excellente démo. C'est super d'avoir un en-tête fixe :). J'espère que vous serez en mesure de terminer la mise en œuvre! Concernant le transfert numérique, qu'est-ce qui vous empêche de postuler directement sur les cellules? react-window vs react-virtualized
@oliviertassinari Je me suis fixé pour objectif d'utiliser l'API du composant Table
et pour l'instant il ne semble pas que vous puissiez passer des accessoires personnalisés via le composant Column
. Il existe probablement des moyens de le faire sans utiliser la méthode de réaction virtualisée
@joshwooding Avez-vous essayé https://github.com/bvaughn/react-virtualized/blob/master/docs/Table.md#headerrowrenderer ?
@oliviertassinari J'ai essayé d'utiliser HeaderRowRenderer mais il semble que vous ne pouvez pas passer d'accessoires personnalisés sans manipuler les accessoires existants car c'est ce qui est appelé pour créer les colonnes à passer par l'en-têteRenderer:
const renderedHeader = headerRenderer({
columnData,
dataKey,
disableSort,
label,
sortBy,
sortDirection,
});
@oliviertassinari Pour une table à hauteur fixe, vous pouvez simplement modifier légèrement la démo de https://codesandbox.io/s/6vo8y0929k
@joshwooding a l'air génial! Je ne vois rien qui manque pour en faire une démo officielle.
@issuehuntfest a financé 60,00 $ pour ce numéro. Voir sur IssueHunt
@oliviertassinari Je vais travailler sur l'implémentation de ceci :)
@joshwooding a soumis une demande d'extraction. Voir sur IssueHunt
@oliviertassinari a récompensé 81,00 $ à @joshwooding. Voir sur IssueHunt
@oliviertassinari a récompensé 81,00 $ à @joshwooding. Voir sur IssueHunt
Bien mérité. Beau travail @joshwooding!
J'ai un besoin similaire mais pour le composant Liste ... la même approche fonctionnerait-elle pour faire fonctionner la liste?
@mdizzy Oui, nous pourrions ajouter une démo similaire pour la liste.
J'essaie en ce moment de créer une liste virtuelle avec react-window (comme le créateur a suggéré de l'utiliser à la place de virtualisée si vous n'avez pas besoin de l'API complète, mais à la fin, l'API pour une liste ne change pas vraiment autant)
Jusqu'à présent, j'ai deux gros problèmes:
1) Le style des éléments de liste est cassé, en particulier pour des éléments tels que les bonnes icônes / actions. Je suppose que le style injecté par la liste virtuelle ne joue pas bien avec le style de material-ui
2) Les sous-en-têtes collants deviennent également très désordonnés, probablement pour la même raison (position absolue de la fenêtre de réaction pour mettre en page les éléments)
Je vais probablement essayer de virtualiser les réactions pour voir s'ils fonctionnent mieux ensemble
@MastroLindus Je suppose que vous avez d'abord essayé notre démo de virtualisation?
@oliviertassinari J'ai commencé par ma propre voie, j'ai trouvé les problèmes que j'ai décrits ci-dessus, j'ai recherché sur Google, j'ai trouvé ce fil.
Ensuite, j'ai découvert la démo de virtualisation, j'ai vérifié son code et j'ai découvert que c'est fondamentalement la même chose que je fais moi-même (appliquée uniquement aux tables au lieu des listes).
Mes problèmes sont un peu plus liés à des listes. Le concept général fonctionne, mais des éléments tels que des icônes, des actions, des en-têtes collants ne fonctionnent pas correctement.
En détail, en se référant à mes 2 points dans le commentaire ci-dessus:
Le problème numéro 1 pourrait être un problème avec react-window qui ne sera pas présent avec react-virtualized. Je vais vous le faire savoir dès que j'essayerai aujourd'hui ou demain. Peut-être que nous avons de la chance et que cela fonctionnera simplement avec react-virtualized. Voyons voir.
Problème numéro 2 (les sous-en-têtes collants ne fonctionnent pas correctement) Je pense que c'est quelque chose qui nécessitera de toute façon une solution ad hoc, car leur positionnement créera probablement un conflit quoi qu'il arrive. Quelqu'un a construit https://github.com/marchaos/react-virtualized-sticky-tree pour un problème similaire (ayant un accord de réaction virtualisé avec des en-têtes collants) mais je n'ai pas eu le temps de l'examiner pour le moment
@MastroLindus Quels problèmes avons-nous avec https://next.material-ui.com/demos/tables/#virtualized -table?
@oliviertassinari Aucun.
J'ai précisé que mes problèmes sont spécifiques aux listes virtuelles, pas aux tables virtuelles. (Encore une fois: je suis désolé d'écrire sur le problème de Table Virtualized, il n'y en a pas pour les listes virtualisées et je suivais le commentaire de
En ce qui concerne les listes: l'utilisation de ListItemSecondaryAction, ListItemIcon et ListSubheader (avec des en-têtes collants) ne semble pas fonctionner, car leur positionnement est perturbé.
Sans ces composants, j'ai une liste de base pour travailler avec react-window (et je suppose que je ferais la même chose en react-virtualized)
@MastroLindus Je pense que vous pouvez déplacer la discussion vers # 15149.
Commentaire le plus utile
@oliviertassinari Je l'ai fait sans
react-virtualized
parce que c'était un gâchis et qu'il ne fonctionnait pas bien avec les composants mui.De plus, ma solution actuelle est un corps à tête fixe et défilable pur-css avec une hauteur de table dynamique et une largeur de colonnes dynamique (testé également sur Safari).
Le thead toujours sur le dessus avec un corps déroulant est un must pour les grilles de données.
J'ajoute un anti-rebond du défilement, peaufine les performances et corrige un problème, mais cela fonctionne très bien: je suis "virtuellement" en train de rendre environ 2400 lignes, tellement fluide.
Questions sur les composants
Table
:ref
avec des composants MUI? Je calcule automatiquementTableThead
hauteur: le problème est quene renvoie pas l'élément conteneur DOM réel de
TableThead
mais l'instance React (comportement natif de React lors de l'application deref
sur un élément non-DOM) car c'est quelque chose qui devrait être appliqué dans leTableThead
composant lui-même; d'autres composants peuvent en avoir besoin, alors pourquoi ne pas avoir unrefHandler
sur chaque composant MUI qui applique le rappel donné dans le premier élément rendu? (J'espère avoir réussi à expliquer cela @ _ @)Ma solution actuelle est bizarre
ce qui signifie utiliser le
findDomNode
obsolète et désactiver également eslint.pourquoi
border-bottom
appliqué sur des cellules plutôt que sur des lignes?Qu'en est-il d'avoir un accessoire
stripe={true}
pour rayer automatiquement les lignesTableBody
?pourquoi
.MuiIconButton.root
a-t-il une propriété de style zIndex? 🤔J'espère publier quelque chose de stable à ce sujet bientôt afin que vous puissiez y jeter un coup d'œil, c'est quelque chose qui peut être adopté de manière générale.
Désolé de déranger autant mais j'utilise beaucoup mui @ next donc je repère beaucoup de cas d'utilisation!