Die kurze Antwort: Laut dem vom Pagy-Autor veröffentlichten Paginierungs-Benchmark ist Pagy mit großem Abstand das leichteste der drei gängigen Ruby-on-Rails-Gems. Beim Rendern derselben Navigation über dieselben Datensätze belegt es 184 Objekte , während will_paginate etwa 3.200 und Kaminari etwa 6.400belegt. Bei einer Anwendung, die Tausende gleichzeitige Nutzer bedient, wirkt sich dieser Unterschied direkt auf die Speicherauslastung pro Instanz aus – und damit auf die Anzahl der Instanzen, für die Sie bezahlen.
Zuerst ein Punkt zur Klarstellung, da viele der noch kursierenden Artikel veraltet sind: Pagy ist längst kein kleiner Newcomer mehr. Es erschien erstmals im Februar 2018 und ist heute eine ausgereifte und weit verbreitete Bibliothek. Was sich geändert hat, ist die API. Pagy 43 war eine komplette Neuentwicklung von Grund auf, daher zeigen die meisten Tutorials, die Sie finden (einschließlich unserer bisherigen), Aufrufe, die es nicht mehr gibt. Ich entwickle Rails-Anwendungen seit Version 0.8 und habe alle drei Gems in der Produktion eingesetzt; dieser Artikel wurde für die aktuelle Version komplett neu geschrieben.
Vor dem Benchmark ein Blick auf die Wartungssituation, denn wenn man sich für Jahre auf eine Codebasis festlegt, ist die Frage „Was ist am schnellsten?“ weniger wichtig als „Was wird noch gepflegt?“.
| Gem | Aktuelle Version | Neuestes Release | Wartungssignal |
|---|---|---|---|
| Pagy | 43.x | 2026 | Aktiv entwickelt; häufige Releases; vollständiges Redesign in v43 |
| Kaminari | 1.2.2 | Dezember 2021 | Bei weitem immer noch am häufigsten installiert, aber seit über einem Jahr kein Release mehr |
| will_paginate | 4.0.1 | Juni 2024 | Offiziell im Wartungsmodus: keine neuen Funktionen, und die README weist Benutzer selbst auf Alternativen hin |
Aus dieser Tabelle lassen sich einige Schlüsse ziehen.
will_paginate ist nicht tot, aber der Maintainer hat einen Schlussstrich gezogen. Es erhielt mit Version 4.0 Unterstützung für Rails 7 und bekam 2024 einen Patch. Die Aussage „letzter Commit war 2017“, die man in älteren Beiträgen (auch unseren) findet, ist also schlicht falsch. Der richtige Grund, es bei neuen Projekten zu meiden, ist nicht mangelnde Pflege. Es ist die Tatsache, dass der Maintainer es explizit in den Wartungsmodus versetzt und die Weiterentwicklung eingestellt hat. Eine faire Entscheidungsgrundlage – aber eine falsche, wenn man sich auf ein Commit-Datum von 2017 beruft.
Kaminari ist der Platzhirsch, und das hat nach wie vor Gewicht. Es hat mit großem Abstand die größte installierte Basis der drei, eine umfangreiche Dokumentation, View-Templates, die man generieren und anpassen kann, sowie eine modellbasierte Konfiguration. Aber das letzte Release war im Dezember 2021. Es funktioniert, es ist stabil, und bei einem Admin-Panel mit wenig Traffic werden Sie von der unten diskutierten Performance nichts merken. Die Dynamik liegt jedoch eindeutig woanders.
Pagy ist das Projekt, in dem die aktive Entwicklungsenergie steckt. Neben der reinen Geschwindigkeit bietet es mittlerweile verschiedene Paginierungs- techniken in einem einzigen Gem (Offset, Countless, Keyset, Keynav, Calendar und Search), dazu serverseitiges oder clientseitiges Rendering sowie interaktive Entwickler-Tools. Diese Vielfalt – nicht nur der Speicherverbrauch – ist ein wesentlicher Grund, warum sich heute viele dafür entscheiden.
Die Anzahl der jährlich veröffentlichten RubyGems stieg Anfang der 2010er Jahre stetig an, erreichte um 2015 ihren Höhepunkt und ist seitdem rückläufig. Das bedeutet jedoch nicht, dass es keine beachtenswerten Neuerungen mehr gibt. Es bedeutet lediglich, dass wirklich nützliche Neuentwicklungen heute seltener und leichter zu übersehen sind. Pagy war 2018 eine solche Ausnahme; der Sinn eines Updates wie diesem ist, dass „selten und leicht zu übersehen“ auch die Veränderungen an einer guten Bibliothek beschreibt, sobald die Community aufgehört hat, darüber zu schreiben.
2010 bis 2026
Verifizierte Zahlen: 2014 (~27.000) und 2018 (~10.600 / ~29 pro Tag), aus den RubyGems-Analysen von Infinum.
Wer bereits mit Rails gearbeitet hat, hat wahrscheinlich schon einmal will_paginate oder Kaminari verwendet, um Index-Seiten einer Anwendung zu paginieren. Paginierung bedeutet, eine lange Liste von Datensätzen in nummerierte Seiten aufzuteilen und die entsprechenden Links dazwischen anzuzeigen. Falls Sie neu bei Rails sind, werden Sie schon bald nach einer Lösung für die Paginierung suchen.
Pagy ist eine Paginierungs-Bibliothek, bei der die Performance an erster Stelle steht, ohne dass die Anwendung in neuen oder bestehenden Projekten kompliziert wird. Sie ist Framework-agnostisch: Sie funktioniert mit Rails sowie mit schlankeren Ruby-Frameworks wie Sinatra und Padrino und paginiert sowohl Active-Record-Relationen als auch einfache Arrays und andere Sammlungen.
Dass man 2018 gegenüber einem weiteren Paginierungs-Gem skeptisch war, ist verständlich. Fragmentierung ist nicht gut für Open Source, und einige der Verbesserungen, die Pagy einführte, wurden ursprünglich für Kaminari vorgeschlagen und dort abgelehnt, da sie grundlegende Änderungen am Kern des Gems erfordert hätten. Diese Ablehnung ist einer der Hauptgründe für die Entstehung von Pagy. Acht Jahre später hat sich die Skepsis weitgehend gelegt: Die Download- und Star-Zahlen machen Pagy mittlerweile zu einer festen Größe im Mainstream und nicht mehr zu einer Randerscheinung.
Stellen Sie sich jedes Gem auf einem Request-Pfad wie Gepäck vor. Sie tragen es auf jeder Reise mit sich, egal ob Sie es öffnen oder nicht. Paginierung ist die Tasche, die auf fast jeder Listenseite Ihres Produkts dabei ist. Eine schwere Tasche ist auf einer Reise kein Problem. Sie wird zum Problem, wenn Sie zehntausend Reisen pro Stunde unternehmen.
Die folgenden Zahlen stammen aus der Benchmark-Suite, die vom Autor von Pagy veröffentlicht wurde, welche dieselbe Bootstrap-Paginierung für dieselben Datensätze mit jedem Gem nacheinander rendert.
Die Suite erfasst zwei Werte pro Gem: den für die Arbeit zugewiesenen Speicher und die Anzahl der zugewiesenen Ruby-Objekte. Sie misst nicht die Datenbankabfrage hinter der Seite, die unabhängig vom verwendeten Gem gleich bleibt. Sie misst auch nicht die Seitenladezeit für den Endbenutzer, die maßgeblich von der Abfrage, der View und dem Netzwerk bestimmt wird. Da sie vom Autor eines der drei Gems veröffentlicht wurde, sollte sie als direkter Vergleich des Paginierungs-Overheads und nicht als unabhängige Studie betrachtet werden.
Zwei ehrliche Anmerkungen zu den unten stehenden Zahlen. Erstens benchmarkt die veröffentlichte Suite noch die Legacy- Versionen (Pagy v3, will_paginate 3.1.7, Kaminari 1.1.1); betrachten Sie diese also als den Overhead der klassischen Implementierung jedes Gems. Zweitens beansprucht Pagys aktuelle Version v43 weitere Verbesserungen gegenüber der eigenen v3-Basislinie. Wenn überhaupt, ist die moderne Lücke also eher größer als kleiner. Die Zahlen stellen den Overhead dar, sonst nichts.
| Gem (getestete Version) | Allokierte Objekte | Gesamter allokierter Speicher | Speicherwachstum, 2 bis 20 Seiten |
|---|---|---|---|
| Pagy (v3.0.0) | 184 | ~19 KB | Flach (kein messbarer Anstieg) |
| will_paginate (3.1.7) | ~3.198 | ~341 KB | ~2x |
| Kaminari (1.1.1) | ~6.445 | ~704 KB | ~4x |
Bei der Objektzuweisung ist der Unterschied am deutlichsten. Kaminari erstellt etwa 6.400 Objekte, um die Navigation zu rendern; will_paginate etwa 3.200. Beide sind für diese Aufgabe zu schwerfällig. Pagy erledigt das mit 184.
Die Wachstumskurve ist genauso wichtig wie die Gesamtzahlen. Wenn Sie die Paginierungsleiste von 2 auf 20 Links erweitern, bleibt der Speicherverbrauch von Pagy nahezu konstant, während er sich bei will_paginate etwa verdoppelt und bei Kaminari etwa vervierfacht. Auf einer stark frequentierten Übersichtsseite mit einer breiten Paginierungsleiste schlägt sich dieser Anstieg bei jeder Anfrage nieder.
Hinter der Speicherproblematik verbirgt sich auch eine Frage des Codeumfangs. Um das identische Ergebnis zu erzielen, benötigt Pagy etwa 4 Dateien und ca. 140 Zeilen; Kaminari umfasst ca. 36 Dateien, will_paginate ca. 23. Weniger Code für dieselbe Aufgabe bedeutet in der Regel weniger Speicherbelegung und weniger Komplexität, was sich hier direkt im Profil widerspiegelt.
Gleiche Navigation, gleiche Datensätze. Niedriger ist besser.
Allokierte Ruby-Objekte zum Rendern derselben Paginierungsausgabe. Quelle: Benchmark-Suite des Pagy-Autors (ddnexus/pagination-comparison), Ältere Gem-Versionen. Pagy 43 verspricht weitere Leistungssteigerungen gegenüber der hier gezeigten v3-Referenz.
Jedes zugewiesene Objekt belegt Speicher, der anschließend durch die Garbage Collection (den Hintergrundprozess von Ruby zur Freigabe nicht mehr benötigten Speichers) wieder freigegeben werden muss. All dies geschieht bei fast jedem Seitenaufruf im Produkt. Die Reduzierung der Speicherbelegung pro Anfrage um eine Größenordnung macht eine einzelne Seite nicht spürbar schneller. Sie erhöht jedoch die Anzahl der gleichzeitigen Anfragen, die eine Instanz verarbeiten kann, bevor eine weitere hinzugefügt werden muss. Bei einer Infrastrukturrechnung, die sich nach der Anzahl der Instanzen richtet, genau dort liegen die Einsparungen – und die Migration, die dies ermöglicht, ist eher in Stunden als in Sprints zu bemessen.
Wir beobachten dieses Muster auch bei unserer eigenen Arbeit. Als wir FlippedNormals, einen Marktplatz für Computergrafik, neu aufgebaut haben, konnte die alte WordPress-Plattform mit dem Traffic nicht mehr Schritt halten. Wir migrierten sie daher auf eine maßgeschneiderte Ruby-on-Rails-Anwendung und verlagerten sie auf AWS, um eine besser skalierbare Infrastruktur zu erhalten. Die gesamte Migration dauerte zwei Monate und führte nach dem Relaunch zu einem Anstieg des Traffics um 4 %. Dies ist ein nützliches Fallbeispiel für unsere Diskussion, gerade wegen seiner Struktur: Ein Katalog mit mehr als 28.000 Produkten bedeutet, dass Listen-, Such- und Übersichtsseiten kritische Pfade darstellen, die bei nahezu jeder Anfrage aufgerufen werden. Genau das sind die Seiten, auf denen sich die Kosten eines Paginierungs-Gems pro Anfrage mit dem Traffic vervielfachen und auf denen eine früh getroffene Entscheidung später stillschweigend die Obergrenze für die Ressourcen festlegt.
Dies bietet einen entscheidenden Vorteil: Der Code ist ausgesprochen gut lesbar, was es dem Autor ermöglicht hat, ihn Zeile für Zeile zu optimieren.
Pagination ist nur ein Beispiel für ein breiteres Muster, und genau nach diesem Muster suchen wir, wenn wir einen Rails-Stack überprüfen. Wir nennen es ein Gem-Ressourcen-Audit. Drei Schritte.
1. Inventarisieren Sie, was bei jedem Request ausgeführt wird. Nicht das gesamte Gemfile, sondern nur die Gems, die auf den Seiten aufgerufen werden, die tatsächlich Traffic erhalten: Index- und Listenseiten, Suchergebnisse, Dashboards. Pagination, Serialisierung, Autorisierungsprüfungen und View-Helper landen meist auf dieser Liste. Ein Gem, das einmal täglich in einem Hintergrund-Job verwendet wird, ist keine Messung wert.
2. Messen Sie die Speicherallokation, nicht die Laufzeit. Die Objektallokation pro Request ist der Wert, der vorhersagt, wie sich eine Anwendung unter Last verhält, und er ist stabil genug, um zwei Implementierungen miteinander zu vergleichen. memory_profiler und benchmark-ips liefern Ihnen sowohl die Allokationsdaten als auch die Zeitmessung für eine einzelne Aktion. Der Unterschied zwischen zwei Gems bei derselben Aktion ist meist schon beim ersten Durchlauf offensichtlich.
3. Modellieren Sie das Ergebnis in Instanzen, nicht in Megabyte. Eine Einsparung wird erst dann zu einem schlagkräftigen Argument, wenn sie als Kapazitätsgewinn ausgedrückt wird: wie viele zusätzliche parallele Requests eine Instanz bewältigen kann und wie viele Instanzen somit für das gleiche Traffic-Aufkommen benötigt werden. Das ist die Kennzahl, mit der ein technischer Entscheider arbeiten kann und die den Migrationsaufwand rechtfertigt.
Die meisten Rails-Anwendungen schleppen zwei oder drei solcher Altlasten mit sich herum. Pagination finden wir am häufigsten, da sie früh gewählt, nie wieder hinterfragt wird und genau auf den Seiten liegt, die den meisten Traffic erhalten.
Hier führen Sie ältere Anleitungen in die Irre: Pagy::Backend / Pagy::Frontend Includes, das items: Keyword und der pagy_nav Helper stammen alle aus der Zeit vor v43. Hier ist das aktuelle Setup, das dem offiziellen Quick-Start-Guidefolgt.
1. Fügen Sie das Gem hinzu und fixieren Sie es auf die Minor-Version (v43 verwendet eine Sprung-Versionsnummer, daher schützt Sie eine Fixierung auf die Minor-Version vor Breaking Changes):
# Gemfile
gem 'pagy', '~> 43.6'Pagy 43 erfordert Ruby 3.3 oder neuer.
2. Binden Sie das einzelne Einstiegsmodul ein in Ihrem Application Controller:
# app/controllers/application_controller.rb
include Pagy::MethodDieses eine Include ersetzt die alten zwei Module (Backend plus Frontend) Einrichtung. Methoden werden nur bei Verwendung automatisch geladen.
3. Paginierung in der Controller-Aktion. Wählen Sie einen Paginator: :offset ist das klassische Verhalten, :keyset ist am schnellsten für große, sortierte Sammlungen:
# Offset pagination (the familiar page-number behaviour)
@pagy, @records = pagy(:offset, Product.all, limit: 20)
# Keyset pagination (fastest for large, ordered datasets)
@pagy, @records = pagy(:keyset, Product.order(:id).all, limit: 20)Hinweis limit:, das das alte items: Schlüsselwort ersetzt hat.
4. Navigation in der View rendern. Die Hilfsmethoden sind jetzt Methoden des @pagy Objekts:
<%# Server-side navigation bar %>
<%== @pagy.series_nav %>
<%# Or a client-side, responsive variant, styled for Bootstrap or Bulma %>
<%== @pagy.series_nav_js(:bootstrap) %>
<%== @pagy.input_nav_js(:bulma) %>
<%# A "showing 476-500 of 1000" style summary %>
<%== @pagy.info_tag %>Das war der gesamte Schnelleinstieg. Wenn Sie das Design Ihrer App interaktiv anpassen oder der integrierten KI von Pagy direkt aus Ihrer App heraus eine Frage stellen möchten, aktiviert eine einzige Zeile in Ihrem Layout head die Entwicklertools:
<%== Pagy.dev_tools %>Die Umstellung erfolgt im Controller und im View (der Datei, die die Anfrage verarbeitet, und dem Template, das die Seite rendert). Der offizielle Migrationsleitfaden unterteilt dies in wenige technische Schritte, die in der Praxis fast eins zu eins übernommen werden können.
Controller. Alte Aufrufe lassen sich direkt übersetzen:
# will_paginate
# @records = Product.some_scope.paginate(page: params[:page], per_page: 15)
# Kaminari
# @records = Product.some_scope.page(params[:page]).per(15)
# Pagy
@pagy, @records = pagy(:offset, Product.some_scope, limit: 15)View. Tauschen Sie den Helper aus:
<%# will_paginate: <%= will_paginate @records %> %>
<%# Kaminari: <%= paginate @records %> %>
<%== @pagy.series_nav %>Globale Konfiguration. Durchsuchen Sie Ihre Codebasis nach dem Klassennamen des alten Gems (WillPaginate, Kaminari) und entfernen Sie dessen Initializer sowie jegliches Monkey-Patching. Ein globaler per_page -Wert wird zu Pagy::OPTIONS[:limit] in einem Pagy-Initializer oder einem limit:-Parameter pro Aufruf. Wenn Sie sich auf Kaminaris .page Scope innerhalb von Modellmethoden, entfernen Sie ihn dort und wenden Sie den Paginator stattdessen im Controller an.
Führen Sie anschließend Ihre Tests aus oder klicken Sie sich durch die Seiten. Verbliebener Legacy-Code wird Fehler verursachen; entfernen Sie diesen daher und versuchen Sie es erneut, bis die App sauber gerendert wird. Falls Sie Paginierungsstile von Bootstrap oder Bulma verwendet haben, funktioniert das vorhandene CSS mit den series_nav -Helfern von Pagy.
Pagy ist kein direkter Ersatz: Sie können das Gem nicht einfach austauschen, ohne Ihren Code anzupassen. Die Namen der Helfer unterscheiden sich, daher muss jede paginierte Ansicht überarbeitet werden. Zudem wird die Collection nicht mehr wie bei Kaminari mit Seiten-Methoden für Active-Record-Relationen erweitert. Jeder Code, der auf diese Methoden zugreift, muss geändert werden. Die Helfer von Pagy geben reinen HTML-Code zurück, was genau der Grund für ihre hohe Geschwindigkeit ist.
Bei einer Anwendung mit einer Handvoll Index-Seiten ist das an einem Nachmittag erledigt. Bei einer Anwendung mit fünfzig Seiten sollten Sie dies als abgegrenztes Arbeitspaket planen und wie jede andere Änderung behandeln, die bei jedem Request ausgeführt wird: mit einem Review und einer Überprüfung der Seiten. Wenn Sie diese Aufgabe lieber abgeben möchten, ist dies genau die Art von Arbeit, die unsere Ruby on Rails-Entwicklungsdienstleistungen abdecken.
Eine ehrliche Empfehlung braucht auch ein „Wann besser nicht“.
Bleiben Sie bei Kaminari, wenn die Anwendung bereits tief darauf ausgerichtet ist (Sie verlassen sich auf die generierten View-Templates und die modellbasierte Konfiguration) oder wenn die paginierten Seiten so wenig Traffic haben, dass sich der Speicherunterschied niemals auf Ihrer Rechnung bemerkbar machen wird. Kaminari ist ausgereift, umfassend dokumentiert und nach wie vor das am häufigsten installierte der drei Pakete. Das Argument für Pagy ist ein Ressourcen- Argument, und es ist am stärksten, wenn die Paginierung einen kritischen Pfad darstellt.
will_paginate ist für neue Projekte schwer zu empfehlen, da der Maintainer keine neuen Funktionen mehr aufnimmt. Wenn Sie jedoch eine stabile Anwendung haben, die es bereits verwendet, und keinen Leistungsdruck verspüren, bedeutet „im Wartungsmodus“ nicht gleich „defekt“. Es besteht keine Dringlichkeit, nur um des Wechsels willen umzusteigen.
Das Ressourcen-Argument für Pagy ist stichhaltig, aber es ist eine Option, kein Gebot. Passen Sie es an Ihr Traffic-Aufkommen an.
Ich habe mit will_paginate angefangen, weil es damals das beste Tool war. Ein paar Monate nach dem Start von Kaminari bin ich umgestiegen und blieb dort, bis Pagy erschien.
Was mich später überraschte, war, dass ich von will_paginate zu Kaminari gewechselt war, ohne die Performance überhaupt zu berücksichtigen – und laut veröffentlichtem Benchmark ist Kaminari das schwerfälligere der beiden. Ich hatte selbst keinen Benchmark durchgeführt. Es war reine Gewohnheit.
Das wirft eine berechtigte Frage für den Rest des Stacks auf: Wie viele Gems schleppen wir mit uns herum, die unsere Anwendungen schleichend ausbremsen, weil sie auf die gleiche Weise ausgewählt und nie wieder überprüft wurden? Genau darum geht es bei dem oben genannten Audit. In unserer eigenen Arbeit ist das mittlerweile ein fester Bestandteil und kein nachträglicher Gedanke mehr, denn die Kosten, wenn man diese Frage zu spät stellt, sind eine Infrastrukturrechnung, die niemand erklären kann. Diese Logik gilt weit über Paginierung und Rails hinaus. Das Framework, für das man sich entscheidet, bildet das Fundament. Die Bibliotheken, die man hinzufügt, bestimmen die Obergrenze. Der gleiche Zielkonflikt zeigt sich bei der Wahl des Frameworks selbst, wie in unserem Vergleich von Ruby vs. Python für die Webentwicklung.
Ein Hinweis vorab: Die oben genannten Performance-Werte stammen aus der Benchmark-Suite des Pagy-Autors (ddnexus/pagination-comparison), ausgeführt mit den Legacy-Versionen der jeweiligen Gems.
Ja, sehr verbreitet. Es hat sich vom Newcomer zu einer der gängigsten Paginierungslösungen für Rails entwickelt, mit zig Millionen Downloads, Tausenden von GitHub-Stars und regelmäßigen Releases bis ins Jahr 2026. Die aktive Weiterentwicklung in diesem Bereich findet bei Pagy statt; Kaminari hat zwar die größere installierte Basis, hat aber seit 2021 kein Release mehr veröffentlicht.
Laut den Benchmarks des Autors ja, und zwar mit großem Vorsprung beim Ressourcenverbrauch: Pagy alloziert etwa 184 Objekte gegenüber ca. 6.400 bei Kaminari und verbraucht insgesamt deutlich weniger Arbeitsspeicher. Der für den Nutzer sichtbare Unterschied bei einem einzelnen Seitenaufruf ist gering. Der Unterschied zeigt sich jedoch darin, wie viele gleichzeitige Anfragen eine Instanz verarbeiten kann.
Fügen Sie gem 'pagy', '~> 43.6'hinzu, fügen Sie include Pagy::Method zu Ihrem ApplicationControllerhinzu, ersetzen Sie jeden .paginate(...) / .page(...).per(...) Aufruf durch @pagy, @records = pagy(:offset, scope, limit: N)und ersetzen Sie den View-Helper durch <%== @pagy.series_nav %>Es ist kein direkter Austausch, und jede paginierte Ansicht muss einzeln angepasst werden, aber die Änderung ist überschaubar und lässt sich leicht rückgängig machen.
Ja. Die Berechnungen basieren auf Ganzzahlen statt auf Ruby-Objekten, daher wächst der Ressourcenverbrauch nicht mit der Größe der Sammlung. Bei sehr großen, sortierten Tabellen vermeidet der :keyset Paginator von Pagy den aufwendigenOFFSET -Scan vollständig. Die Grenze, auf die man letztlich stößt, ist die Count-Abfrage der Datenbank, nicht das Paginierungs-Gem – das gilt für alle drei Varianten.
Pagy ist framework-unabhängig. Es funktioniert mit Rails sowie mit schlankeren Frameworks wie Sinatra und Padrino und paginiert Active-Record-Relationen ebenso wie einfache Arrays und andere Sammlungen. Ein ORM (Object-Relational Mapper) ist die Schicht, die Datenbankzeilen in Objekte umwandelt; Active Record ist das in Rails integrierte ORM, und Pagy arbeitet parallel dazu, anstatt sich direkt an Ihre Modelle zu binden.
Es war eine komplette Neugestaltung. Das Setup wurde auf ein einziges include Pagy::Methodreduziert, die Konfiguration wurde drastisch vereinfacht und die Hilfsmethoden wurden auf das @pagy -Objekt verschoben (@pagy.series_nav anstelle des alten pagy_nav(@pagy)). Zudem wurden neue Paginatoren (countish, keyset, keynav, calendar und search), clientseitiges Rendering sowie interaktive Entwicklungstools hinzugefügt. Wenn Sie einem älteren Tutorial folgen, werden die Methodennamen abweichen.
Bei Imaginary Cloud arbeiten wir mit einem breiten Tech-Stack, einschließlich Ruby on Rails. Wenn Paginierung in Ihrer Anwendung ein kritischer Pfad ist oder Sie vermuten, dass andere Gems mehr Ressourcen verbrauchen als nötig, führen wir das oben beschriebene Gem-Ressourcen-Audit für Ihren Stack durch und zeigen Ihnen genau, wo die Kosten entstehen. Kontaktieren Sie uns und wir schauen uns das gemeinsam an.
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
.webp)
