Material-ui: [Grille] Largeur supplémentaire du conteneur et de la barre de défilement

J'ai trouvé le même problème sur flexboxgrid . Je pense que c'est une limitation de notre solution de marge négative qui implémente l'espacement.
J'ai vérifié ce que fait le bootstrap, ils n'ont pas cette fonction d'espacement, donc pas de problème de leur côté.

Vous avez donc 3 solutions de contournement disponibles:

• En n'utilisant pas la fonction d'espacement et en l'implémentant sur le userland spacing={0} , nous pourrions en faire le comportement par défaut.
• Ajout d'un remplissage sur le parent avec au moins la valeur d'espacement: https://codesandbox.io/s/WnpKlQ32n

    <div style={{ padding: 20 }}>
      <Grid container spacing={40}>

• Ajout de overflow-x: hidden; sur le parent.

Je termine car je ne peux pas penser à une meilleure alternative. Si quelqu'un a une meilleure solution pour la fonction d'espacement, veuillez élever la voix :).

Pour moi, il semble que spacing={0} devrait être le comportement par défaut. Au moins jusqu'à ce qu'une meilleure solution arrive, car cela semble être un bogue avec <Grid /> pour les nouveaux utilisateurs de material-ui.

@hboylan À la lumière de toutes ces questions ouvertes pour cette limitation, je commence à me demander! J'aurais aimé que nous ayons accès à des analyses d'utilisation de l'API 📈.

J'ai ajouté la balise waiting for users upvotes . Je ne suis pas sûr que les gens préféreraient avoir spacing={0} . Veuillez donc voter pour ce problème si vous l'êtes. Nous prioriserons nos efforts en fonction du nombre de votes positifs.

Au moins 8 problèmes dupliqués sont un signal fort. J'ajouterai une note sur cette limitation dans la documentation.

Je me demande simplement: y a-t-il des mises en garde lors de l'utilisation de la deuxième solution de contournement que vous avez décrite ?

Sinon, vous pouvez l'ajouter dans le Grid-container-Component par défaut?

mettre à jour:
=> idiot moi;) bien sûr: nous perdons l'espace, désolé.

Je ne peux pas résoudre ce problème dans material-ui @ next en utilisant spacing={0} dans le conteneur, ou l'une des deux autres solutions, y compris overflowing-x et autres. Peut-être que je manque quelque chose?

flexboxgrid (que @oliviertassinari a mentionné avoir les mêmes problèmes) a un fork qui prétend l'avoir corrigé. https://github.com/kristoferjoseph/flexboxgrid/issues/144#issuecomment -321694572 Je n'ai pas creusé dans le code, mais cela pourrait valoir la peine d'enquêter pour voir s'il y a quelque chose que nous pouvons utiliser dans Grid.

Salut,

Nous avons récemment commencé à adopter cette bibliothèque pour l'un de nos projets.

Vous pouvez imaginer notre surprise lorsque nous avons découvert ce fil.

Fondamentalement, il s'agit d'un bogue qui a été résolu sans solution de contournement à partir de la dernière version de Material-Next. C'est inquiétant.
Encore plus inquiétant est l'idée qu'au lieu de corriger ce bogue, nous avons maintenant ajouté du texte dans la documentation parlant de "limitation".

Avez-vous des procédures concernant les bogues et les corrections de bogues? Ou est-ce que tout est décidé sur place?

Voici la version 1.0.0:
https://github.com/mui-org/material-ui/issues?q=is%3Aopen+is%3Aissue+milestone%3Av1.0.0-prerelease

En extrapolant à partir de ce fil, devons-nous supposer que la version 1.0.0-avant-version contient en fait beaucoup plus de bogues que ce que nous voyons là-bas? (c'est-à-dire ce problème par exemple)

Combien de bogues de l'interface matérielle valides avez-vous résolus jusqu'à présent sur github, et au lieu de corriger, vous avez ajouté du texte dans la documentation?

Sinon le cadre est super. Ce sont les procédures qui sont un peu inquiétantes.

Merci, et je m'excuse si j'ai offensé quelqu'un et / ou si je suis venu un peu fort.

@kmlx

devons-nous supposer que la version bêta de la

Vous devriez certainement (voir: Problèmes ). Et vous devriez vous attendre à ce que 1.0.0-rc.x ait aussi des bogues, mais l'API sera généralement stable.

Le moment de l » @ryanflorence Tweet est parfait.

Je m'excuse si j'ai offensé quelqu'un et / ou si je suis venu un peu fort.

Si vous savez que vous êtes un peu fort, ne vous excusez pas; repensez ce que vous voulez dire et comment vous voulez le dire. (Et peut-être jetez un coup d'œil à la valeur de l'open source par rapport à la contribution que vous avez apportée, et décidez si votre plainte a un poids.)

Mieux encore, si les solutions de contournement fournies dans la documentation ne sont pas suffisantes, restez fidèle au CSS et voyez si vous pouvez résoudre la limitation qui vous dérange.

@mbrookes

Merci d'avoir pris le temps de répondre.

Vous devriez certainement (voir: Problèmes). Et vous devriez vous attendre à ce que 1.0.0-rc.x ait aussi des bogues, mais l'API sera généralement stable.

Heureux d'entendre que l'API sera généralement stable. Comme pour tout projet, je suppose qu'il y aura divers problèmes non découverts.

Pourtant, pour le moment, les solutions de contournement pour ce problème ne fonctionnent pas et le problème lui-même est clos.
Selon votre message précédent, ce fork de flexboxgrid pourrait fournir une solution.
Je suppose que les commits à partir du 1er août sont ceux où l'on devrait chercher un correctif.

Si les solutions de contournement documentées ne fonctionnent plus (je suis actuellement sur mobile, donc je ne peux pas tester), ce problème doit être rouvert.

Merci d'avoir cherché un correctif.

Je n'ai pas le problème btw, et ma solution était de faire manuellement spacing={0} dans chaque composant <Grid container /> ou <Grid item container /> de mon code.

@kmlx J'ai testé avec succès les solutions de contournement suggérées avec beta.22. N'hésitez pas à faire un rapport si vous trouvez une solution permanente.

J'ai ajouté spacing={0} mais je voulais en fait un espacement, j'ai donc ajouté un remplissage et je l'ai fait ajouter uniquement le remplissage au-dessus du point d'arrêt moyen où il montrait deux colonnes:

const styles = theme => ({
  dividerRight: {
    [theme.breakpoints.up('md')]: {
      paddingRight: theme.spacing.unit * 0.5
    }
  },
  dividerLeft: {
    [theme.breakpoints.up('md')]: {
      paddingLeft: theme.spacing.unit * 0.5
    }
  },
});

Ensuite, j'ai ajouté className={classes.dividerRight} à la colonne de gauche (puisque le diviseur est à droite) et className={classes.dividerLeft} à la colonne de droite

J'ai juste eu ce problème. Résolu le problème en ajoutant le css suivant au conteneur de la grille et ça a l'air bien

.grid-container {
  width: 100% !important;
  margin: 0 !important;
}

@martjoao Pour moi, cela a entraîné un rembourrage indésirable autour de l'extérieur de mon conteneur de grille (j'ai des éléments à l'intérieur qui devraient être alignés avec les bords).

Ma solution rapide et sale à cela était de simplement lancer overflow-x: hidden; sur l'élément body. Mais sur certains navigateurs (mobiles en particulier) lorsque vous faites défiler la barre de défilement horizontale clignote pendant une seconde, indiquant à l'utilisateur qu'il peut faire défiler vers la droite. Ce n'est toujours pas souhaitable pour moi.

ÉDITER:

Je viens de voir que l'approche du débordement a été mentionnée ci-dessus. Ma faute.

Je pense qu'il vaut la peine de noter que l'utilisation prévue de <Grid> est _pas_ application / mise en page principale (par exemple, barre d'application, barre latérale, zone de contenu, etc.). Il est vraiment destiné à distribuer des éléments de contenu dans une grille (par exemple une liste de profils). Dans cet esprit, espacer les éléments avec des marges afin que leur zone de contenu ne soit pas affectée - vous pouvez par exemple ajouter une couleur d'arrière-plan ou des bordures - a du sens.

Mais la documentation suggère que l'élément <Grid> devrait être utilisé pour la mise en page principale en ayant une section entière nommée "Mise en page" décrivant l'utilisation de <Grid> .

Une autre raison pour laquelle beaucoup de gens trouvent cela contre-intuitif est que tous les autres frameworks d'interface utilisateur fournissent un mécanisme pour faire la mise en page principale (ce qui serait considéré comme le cas à 80%, @oliviertassinari), et la mise en place d'une grille d'éléments de contenu est une préoccupation secondaire.

Mais la documentation suggère que leL'élément doit être utilisé pour la mise en page principale en ayant une section entière nommée "Mise en page" décrivant l'utilisation de.

@wmadden Pourquoi l'utilisation du libellé de mise en page vous fait-elle penser qu'il s'agit de l'application / de la mise en page principale?

Une autre raison pour laquelle beaucoup de gens trouvent cela contre-intuitif

Qu'est-ce qui est contre-intuitif?

qui serait considéré comme le cas à 80%

Je suis d'accord, nous avons: # 10986 pour cela.

@wmadden Pourquoi l'utilisation du libellé de mise en page vous fait-elle penser qu'il s'agit de l'application / de la mise en page principale?

C'est dans une section de premier niveau appelée "mise en page", plutôt qu'une simple démonstration de composant. Et une formulation comme celle-ci:

La grille crée une cohérence visuelle entre les mises en page tout en permettant une flexibilité dans une grande variété de conceptions. L'interface utilisateur réactive de Material Design est basée sur une disposition en grille de 12 colonnes.

m'a fait supposer qu'il était approprié de l'utiliser pour présenter ma demande - où la limitation de la marge négative devient rapidement un problème.

Une autre raison pour laquelle beaucoup de gens trouvent cela contre-intuitif

Je voulais dire que les gens trouvent qu'il est contre-intuitif que le composant Grid ne soit pas utilisé pour la mise en page principale, car les frameworks d'interface utilisateur fournissent généralement une solution de mise en page à cet effet - et c'est généralement dans un sujet de documentation de haut niveau appelé «mise en page».

C'est une hypothèse courante dans React que les enfants seront contenus par leur parent. La marge négative de <Grid> rompt cette hypothèse en s'étendant au-delà des limites de son parent, ce qui fait que son comportement ressemble à un bogue pour quiconque ne sait pas que c'est par conception.

@ vedant1811 La marge négative n'est plus le comportement par défaut. Vous devriez pouvoir utiliser la grille sans elle pour la disposition de votre application.

@oliviertassinari Y a-t-il eu une mise à jour qui a changé cela? Je me demande simplement si je dois mettre à jour ma version du package. J'utilisais le overflow: hidden; sur la solution de contournement de l'élément parent avant.

@saricden Oui, en ne fournissant pas spacing propriété

Je viens de tomber sur ça. Ce qui semble être une autre solution de contournement hacky mais correcte est de mettre une largeur: 'calc (100% - 16px)' sur le conteneur de la grille ... au moins pour ma situation sur de petites tailles d'écran.

Jouer avec des largeurs différentes pour différents points d'arrêt peut améliorer cela, mais le problème est beaucoup moins perceptible lorsque l'écran donne un conteneur plus large.

J'ai toujours le même problème, mais résolu en ajoutant xs = {12}.
<Grid container spacing={3} xs={12}>

Ce problème persiste. L'ajout de spacing={...} provoque un défilement horizontal. L'ajout de xs={12} ne le résout pas.

_Pour ce que ça vaut: _
Je rencontre ce problème avec Material-UI 4.5.0. Pour une raison quelconque, je viens de le remarquer et j'utilise Material-UI depuis plus d'un an.

J'ai essayé la suggestion xs={12} ci-dessus en plus d'un style de marge (car je voyais une marge supplémentaire sur le côté droit), et ce qui suit produit visuellement l'effet souhaité:

const useStyles = makeStyles(theme => ({
  grid: { margin: theme.spacing(0) }
}));
...
<Grid container spacing={2} xs={12} className={classes.grid}>

_Cependant ..._ je reçois un avertissement dans la console:

Avertissement: échec du type de prop: Le prop xs de Grid doit être utilisé sur item .

Donc, au lieu d'utiliser xs={12} sur le conteneur, j'ai copié les styles qu'il ajoutait à makeStyles() . Ce qui suit semble faire l'affaire pour moi jusqu'à présent:

const useStyles = makeStyles(theme => ({
  grid: {
    margin: theme.spacing(0),
    flexGrow: 0,
    maxWidth: `100%`,
    flexBasis: `100%`
  }
}));
...
<Grid container spacing={2} className={classes.grid}>

Ce n'est que maxWidth: 100% , qui a fait ce travail. cependant, la largeur est maintenant étirée au maximum. cela ne fonctionnera pas si je définis une valeur maxWidth spécifique.

J'ai corrigé cela en utilisant des composants stylisés afin de définir la marge du conteneur Grid sur zéro.

Conteneur de grille stylisée:

const GridContainer = styled(Grid)`
  margin: 0;
`;

Maintenant, GridContainer est utilisé, au lieu du composant Grid qui générait la largeur supplémentaire.

      <GridContainer
        container
        direction="column"
        justify="center"
        alignItems="center"
        xs={12}
        spacing={2}
      >

J'ai utilisé lecomposant à l'intérieur d'un wrapper 100% largeur et hauteur, mais j'ai rencontré ce problème où le conteneur étire la page au-delà de 100vw et provoque un débordement horizontal. Je ne comprends pas pourquoi une marge négative est utilisée pour cela? J'ai dû remplacer les styles par défaut pour ramener la page dans les limites:

const NormalizedGridContainer = withStyles(theme => ({
  root: {
    width: '100%',
    margin: '0px',
    padding: `${(spacing/2) * 8}px`
  }
}))(Grid);

OMI, il devrait être un peu plus évident que les conteneurs Grid ne sont pas destinés à être utilisés comme wrapper d'une application.

Dans la taille du bureau, j'ai des images qui s'étendent tout sur le côté et qui se fixent avec xs = {12} font étrangement apparaître un rembourrage. Dans mon cas, le correctif ressemble à la solution de @martjoao mais uniquement à la largeur mobile:
gridSpacingFix: { '<strong i="7">@media</strong> (max-width:600px)': { width: '100% !important', margin: '0 !important', }, },

J'ai rencontré un problème similaire, et résolu par:

body { margin: 0; padding: 0; }

J'ai fini par faire ci-dessous:

const theme = createMuiTheme({
  overrides: {
    MuiGrid: {
      container: {
        width: "100% !important",
        margin: "0 !important"
      }
    },
  }
});

Cela résout le problème.

était juste confronté à ce problème et en regardant les problèmes liés au montant, je me demandais s'il était logique de résoudre ce problème dans material-ui.

Ne pourrions-nous pas faire essentiellement la même chose qu'ici: https://github.com/evgenyrodionov/flexboxgrid2/commit/37e02fec7674495782098fb8e9a2c6d20a2786e1#diff -4b62e0ae269a54df45ab5eab9cb7821b?

Ran dans le même problème, trouvé un semi-correctif en faisant

<Container maxWidth={false}>
  <Grid container spacing={3}>
    <Grid item />
  </Grid>
</Container>

J'ai toujours le même problème, mais résolu en ajoutant xs = {12}.
<Grid container spacing={3} xs={12}>

Cela m'a corrigé ... merci!

J'ai toujours le même problème, mais résolu en ajoutant xs = {12}.
<Grid container spacing={3} xs={12}>

Cela m'a corrigé ... merci!

Solution géniale! Cela l'a corrigé pour nous aussi. Nous avons dû ajouter container item pour éviter un avertissement container + xs.

problème résolu après l'ajout de overflow-x: hidden ; sur le parent, comme à l'intérieur de Container ont mui-datatable, donc ajouté overflowX: 'hidden' au container

J'ai fini par faire ci-dessous:

const theme = createMuiTheme({
  overrides: {
    MuiGrid: {
      container: {
        width: "100% !important",
        margin: "0 !important"
      }
    },
  }
});

Cela résout le problème.

Merci, c'était la seule solution qui fonctionnait pour moi.

_Semble_ travailler pour moi d'omettre le margin 0 !important

const theme = createMuiTheme({
  overrides: {
    MuiGrid: {
      container: {
        width: "100% !important",
        // margin: "0 !important"
      }
    },
  }
});

Cela me déroute, ce framework d'interface utilisateur a tellement de bogues. Votre

@SomnathKadam

problème résolu après l'ajout de overflow-x: hidden ; sur le parent, comme à l'intérieur de Container ont mui-datatable, donc ajouté overflowX: 'hidden' au container

Le problème avec ceci est que vous pouvez toujours faire défiler. overflow-x: hidden n'est pas une bonne solution

MuiGrid: {
récipient: {
largeur: "100%! important",
marge: "0! important"
}
},
@ rag4214
Ceci modifie de force la structure de l'ensemble du framework et n'est pas recommandé. Vous pouvez le réparer à un endroit, le casser à un autre.

@ manualva7 https://material-ui.com/components/grid/#negative -margin

Je suis choqué, j'utilise MUI depuis peut-être 2 ans et je n'ai jamais vu cela auparavant. Je n'ai toujours pas compris pourquoi c'est arrivé.

J'ai fini par faire ci-dessous:

const theme = createMuiTheme({
  overrides: {
    MuiGrid: {
      container: {
        width: "100% !important",
        margin: "0 !important"
      }
    },
  }
});

Cela résout le problème.

Cette solution fonctionne pour moi.

Cela dure depuis si longtemps que cela devrait faire partie de la documentation si un correctif n'est pas immédiatement possible.

Y a-t-il encore un correctif?
J'ai ce problème et je pense utiliser overflow-x: hidden , qu'en pensez-vous?

Le problème est toujours là. La solution overflow-x: propriété cachée sur le parent

Juste un autre hack pour cela, qui fonctionne pour moi;)

const useStyles = makeStyles((theme) => ({
 root: {
    '& .MuiGrid-root': {
      width: 'calc(100% - 2px)',
    },
  },
// [...]

ces 2px semblent être ajoutés quelque part en dessous de ma définition de grille, donc la valeur réelle pourrait être différente pour d'autres personnes ...