Könntest du mal einen Blick auf den Fix werfen? Ist das so besser für dich?
@Terdious Ich habe dir eine Review gemacht:
Ich habe dir auf deine Fragen zum PR geantwortet.
Ich habe die Änderungen vorgenommen, um mich vom Overkill-Teil zu trennen, aber ich komme zum gleichen Punkt zurück, an dem ich nicht verstehe, warum ich ein falsches Ergebnis habe:
Bei einigen meiner Dashboards (ich habe das Gefühl, dass es passiert, wenn viele Elemente vorhanden sind, ist die beim Laden der Seite abgerufene Höhe falsch. Anschließend übernimmt componentDidUpdate und der Wert wird wieder korrekt. Ich denke also, dass die Höhe abgerufen wird, während die Seite noch nicht vollständig geladen ist… Aber ich finde nicht die richtige Funktionalität. ‹ resizeObserver › und ‹ mutationObserver › funktionierten, ich war zufrieden. Und ich habe auf Stackoverflow gesehen, dass es veraltet ist, aber auch, dass es sehr schnell ist.
Zum Beispiel gibt mir hier das console.log 2371, obwohl die tatsächliche Höhe 3385 beträgt. Sobald ein Update erfolgt, erhalte ich den richtigen Wert.
Zögere nicht, mich auf bessere Spuren zu lenken, wenn du im Kopf hast, wie man die Position ‹ sticky › in diesem Fall besser verwalten kann.
Ich habe die Änderungen gepusht.
Nachdem ich es getestet habe, muss ich zugeben, dass ich nicht unbedingt einen Nutzen im Kleben sehe. Wenn man unten auf dem Bildschirm ist, ist es sogar etwas verwirrend für den Nutzer:
Man klickt, aber es passiert nichts visuell.
Deshalb hinterfrage ich am Ende seinen Nutzen ^^
Was denkst du?
Das passt mir gut ^^
Lass das einfach weg, behalte nur den Button oben, das reicht mir und ich finde, es funktioniert besser 
Erledigt und gepusht!! Du hast recht, ich mochte es ja, aber am Ende ist es so gar nicht so schlecht^^
Danke für deine Analyse!!
Ich habe auf deinen Kommentar geantwortet:
Hmmm ^^ Du stellst mir da eine Frage ^^ Eigentlich war das gut, um den Boden dynamisch vorzubereiten!! Ich dachte, wenn du eines Tages die Anzeigegröße vergrößerst (das wäre toll ^^), dann könnte man leicht auf 4 oder 5 Spalten umstellen ^^
Aber stimmt schon, wenn wir bei drei Spalten bleiben, funktioniert das gut!!
Oder warum nicht einfach ein klassisches Flexbox-Layout?
Das ist wirklich damit verbunden, so viel Platz wie möglich für die auszufüllenden Spalten zu behalten. Ich bin auf Prozent umgestiegen:
const columnStyle = {
'--column-width': boxesLength === maxBoxes ? `calc(100% / ${maxBoxes})` : `calc(93% / ${boxesLength})`
};
const addButtonStyle = {
'--add-button-width': boxesLength < maxBoxes ? 'calc(7%)' : '0'
};
Aber ansonsten, egal, man kann bei 2 oder weniger Spalten bei ‹ col-lg-10 › / ‹ col-lg-2 › bleiben. Das Problem stellt sich nur bei 2 Spalten, wo ich kein ‹ col-lg-(11/2) › machen kann ^^
Oui oui, ich hinterfrage nicht die Funktionsweise ^^
Aber warum CSS-Flexbox nicht verwenden, um das zu machen?
Du hast eine feste Spalte: die letzte Spalte mit dem Button
Und 1, 2 oder 3 Spalten, die eine dynamische Größe haben müssen, die einfach der verbleibende Platz geteilt durch die Anzahl der Spalten ist (und das ist automatisch, nichts zu codieren, das ist CSS).
Ich möchte gerne meinen kleinen Beitrag leisten und unterstütze die Idee, die Möglichkeit zu haben, 1 bis N Spalten zu erstellen. Das hilft dabei, eine Richtung vorzugeben, wie die Spalten verwaltet werden sollen, insbesondere bei immer hochauflösenderen Bildschirmen. Auf großen Bildschirmen nehmen die 3 Spalten 50% der Seitenbreite ein.
Soweit ich verstanden habe, basiert das auf Bootstrap. Ein kleiner col-xl-N, der von der Anzahl der Spalten abhängt, wäre denkbar, auch wenn man von 1 bis 4 Spalten erlauben könnte, um ein Vielfaches von 12 zu behalten. Aber meiner Meinung nach sind 3 Spalten auf großen Bildschirmen etwas zu wenig. Das Problem bei 5 Spalten ist die Verwaltung dieses Vielfachen unter Bootstrap, viele Probleme für wenig Nutzen. Aber 4 Spalten erscheinen mir ein guter Kompromiss.
Ein weiterer Rückmeldung, nicht direkt zur Spaltenfunktion, aber es wäre interessant, ein Ausklapp-Panel im Bearbeitungsbereich für die Karten in den Spalten zu haben. Zum Beispiel für große Karten wie Grafiken, wenn man 3/4 davon hat, wird es schnell schwierig, die Karten zu verschieben. Man könnte einfach einen Button links neben dem Verschiebe-Button hinzufügen, der ‹ Zusammenklappen › heißt. Nur eine Idee
Letztlich schlägtst du vor, den Umorganisationsmodus („Neu anordnen“) beizubehalten, der für mobile Geräte (oder kleine Bildschirme) von @pierre-gilles initiiert wurde!!
Tatsächlich finde ich, dass das Sinn ergibt, umso mehr, wie du sagst, wenn es bereits viele große Blöcke gibt.
Ah, ausgezeichnet, ich habe es gerade mit 80% getestet, es ist wirklich toll.
Hast du eine Dockerfile erstellt, in der du das Docker-Gladys-Image verwendest und jedes Mal die CSS-Datei änderst? 
Hallo @pierre-gilles,
Danke für deine Hilfe und entschuldige bitte das anfängliche Missverständnis. Die Korrekturen sind erledigt, alles in CSS und es funktioniert bei mir sehr gut. Ich habe sogar noch 4 ESLint-Warnungen mitgenommen.
Ich lasse dich die PR überprüfen (und schauen, ob es das ist, was du im Sinn hattest) und dir dann Bescheid geben.
Ich gehe jetzt zur Überprüfung der Binärdateien ^^
Danke @Terdious für die Korrekturen, es ist viel besser so
Es ist viel sauberer, wir sind von einem riesigen PR in Bezug auf Code zu fast nichts übergegangen, es ist perfekt 
Weniger Code = weniger Bugs!
Ich habe einen kleinen Kommentar zu einer sehr kleinen Sache, aber der Rest ist für mich in Ordnung:
Hallo @Terdious Ich melde mich wegen meiner letzten Nachricht.
Es wäre cool, wenn das schnell in Gladys umgesetzt wird, das ist wirklich eine super Funktion!