2014-09-04 16 views
8

Kiedy rozpocząłem pracę nad moim bieżącym projektem, otrzymałem dość żmudne zadanie - zbudować coś, co w istocie ma zastąpić duży arkusz kalkulacyjny, którego ludzie używają wewnętrznie w mojej firmie.Najlepsza sieć open-source z płynnym, nieskończonym przewijaniem

Dlatego uważam, że stół podzielony na strony nigdy nie będzie działał i całkiem szczerze myślę, że paginacja jest głupia. Wyświetlanie dynamicznie zmieniających się danych na tabelach stronicowanych jest kiepskie. Powiedz element na stronie # 2, a następna aktualizacja danych może wylądować na stronie.

Tak więc potrzebowaliśmy zbudować siatkę z niezłym nieskończonym przewijaniem. Nie zrozumcie mnie źle, próbowałem wielu różnych rozwiązań. Najpierw zbudowałem wanilię i powtórzę i spróbowałem użyć ng-infinite-scroll, a następnie ng-scroll from UI.Utils. To szybko doprowadziło mnie do punktu, w którym przewijanie stało się boleśnie powolne, a nawet nie używałem żadnych szalonych rzeczy, takich jak skomplikowane szablony komórek, czy filtry. Bardzo szybko wystąpił mój największy ból. Kiedy zacząłem dodawać takie elementy jak zmienne kolumny i niestandardowe szablony komórek, żadna przeglądarka nie może już obsłużyć wszystkich tych powiązań.

Potem próbowałem ng-grid, a na początku bardzo mi się podobało - łatwe w użyciu, ma kilka fajnych funkcji, których potrzebowałem, ale wkrótce zdałem sobie sprawę - ng-grid jest okropny. Obecna wersja nadziewana błędami, wszyscy współpracownicy przestali ją naprawiać i przełączyli się do pracy nad kolejną wersją. I tylko Bóg wie, kiedy to będzie gotowe do użycia. Ng-grid okazał się znacznie gorszy niż nawet waniliowe powtórzenie.

Próbowałem znaleźć coś lepszego. trNgGrid wyglądał dobrze, ale zdecydowanie zbyt uproszczony i nie oferuje funkcji, których szukałem po wyjęciu z pudełka.

ng-table nie wyglądał zbyt różnie od ng-grid, prawdopodobnie spowodowałby mi takie same problemy z wydajnością.

I oczywiście musiałem znaleźć sposób na zoptymalizowanie wiązań. Wypróbowany bind-once - nie był usatysfakcjonowany, sieć była nadal niepewna. (aktualizacja: kątowa 1.3 oferuje składnię {{::foo}} do jednorazowego wiązania)

Potem próbowałem React. Początkowy eksperyment wyglądał obiecująco, ale aby zbudować coś bardziej skomplikowanego, muszę nauczyć się specyfiki reakcji, poza tym, że czuje się trochę nieanglenowo, i kto wie, jak testować dyrektywy zbudowane z pomocą kąta + reakcji. Nie udało mi się znaleźć sposobu, aby React i PhanthomJS się polubiły (co jest prawdopodobnie większym problemem Phantoma, czy jest tam lepsza przeglądarka bez nagłówków) React również nie rozwiązuje "dołączania" do DOM "problem - kiedy wciskasz nowe elementy do tablicy danych, przez kilka milisekund przeglądarka blokuje wątek UI. To oczywiście zupełnie inny rodzaj problemu.

Mój kolega (który pracuje po stronie serwera) po obejrzeniu moich zmagań, narzekał na mnie, że już za dużo wydałem, próbując rozwiązać problemy z wydajnością. Zmusił mnie do wypróbowania SlickGrid, opowiadania mi o tym, jak to jest dziwaczny najlepszy widget sieci. Szczerze go wypróbowałem i szybko chciałem nagrać mój komputer. To zależy całkowicie od jQuery i pęczka wtyczek jQueryUI, a ja odmawiam nagle upaść na średniowieczne czasy tworzenia stron internetowych i stracić całą kanciastą dobroć. Nie, dziękuję.

Potem przyszedł ux-angularjs-datagrid, i naprawdę, naprawdę, naprawdę się podobało. Używa jakiegoś inteligentnego algorytmu "zepsutego tyłka", aby zachować dobrą reakcję. Projekt jest młody, ale wygląda bardzo obiecująco. Byłem w stanie zbudować podstawową siatkę z mnóstwem rzędów (mam na myśli ogromną liczbę rzędów) bez zbaczania zbytnio z drogi kątowego zenu i przewijanie wciąż gładkie.Niestety, nie jest to kompletne rozwiązanie widgetu siatki - nie będzie można zmieniać rozmiaru kolumn i innych elementów po wyjęciu z pudełka, brakuje dokumentacji itp.

Również znalazłem ten article i miałem mieszane uczucia na ten temat, ci faceci zastosował kilka nie udokumentowanych hacków do kątowych i najprawdopodobniej te łamałyby się z wersjami funkcji kątowej.

Oczywiście istnieje co najmniej kilka płatnych opcji, takich jak Wijmo i Kendo UI. Są one kompatybilne z kanciastą, jednak pokazane przykłady są dość prostymi tabelami podzielonymi na strony i nie jestem pewien, czy warto je wypróbować. Mogę skończyć mając takie same problemy z wydajnością. Ponadto nie możesz selektywnie płacić tylko za widżet siatki, musisz kupić cały pakiet - pełen gówna, którego prawdopodobnie nigdy nie użyję.

W końcu na moje pytanie - czy istnieje dobry, gwarantowany, mniej bolesny sposób na ładną siatkę z nieskończonym przewijaniem? Czy ktoś może wskazać dobre przykłady, projekty lub strony internetowe? Czy można bezpiecznie używać ux-angularjs-datagrid lub lepiej budować własne rzeczy za pomocą kątów i reagować? Ktoś kiedykolwiek próbował sieci Kendo lub Wijmo?

Proszę! Nie głosujcie na zamknięcie tego pytania, wiem, że istnieje wiele podobnych pytań na temat stackoverflow i przeczytałem prawie każdego z nich, ale pytanie pozostaje otwarte.

+0

to będzie bardzo uparty dialog, nie wspominając o niesamowitej ilości tekstu i referencji, więc myślę, że będzie zamknięty – Devin

+0

Po prostu nie mogę uwierzyć, że każdy pojedynczy widget siatki, zgodny z kątowym, cierpi z powodu słabej wydajności problemy. – Agzam

+0

Ile wierszy tu mówimy? – link64

Odpowiedz

4

Może problem tkwi nie w istniejących widżetach, ale bardziej w sposobie, w jaki go używasz. Musisz zrozumieć, że ponad 2000 wiązań skróconych cykli trawienia może zająć zbyt dużo czasu, aby interfejs mógł się płynnie wyświetlać. W tej samej koncepcji, im więcej węzłów HTML masz na swojej stronie, tym więcej pamięci będziesz używać i możesz osiągnąć pojemność przeglądarki, aby renderować tak wiele węzłów w gładki sposób. Jest to jeden z powodów, dla których ludzie używają tej "lame" paginacji.

Na koniec to, co musisz osiągnąć, aby uzyskać coś "gładkiego", to ograniczyć ilość wyświetlanych danych na stronie. Aby uczynić go przezroczystym, możesz zrobić podział na strony na przewijanie.

This plunker przedstawia pomysł, z smart-table. Podczas przewijania w dół ładowana jest następna strona (podczas przewijania musisz zaimplementować poprzednią stronę). I w każdej chwili maksymalna ilość wierszy jest 40.

function getData(tableState) { 

      //here you could create a query string from tableState 
      //fake ajax call 
      $scope.isLoading = true; 

      $timeout(function() { 

       //if we reset (like after a search or an order) 
       if (tableState.pagination.start === 0) { 
        $scope.rowCollection = getAPage(); 
       } else { 
        //we load more 
        $scope.rowCollection = $scope.rowCollection.concat(getAPage()); 

        //remove first nodes if needed 
        if (lastStart < tableState.pagination.start && $scope.rowCollection.length > maxNodes) { 
         //remove the first nodes 
         $scope.rowCollection.splice(0, 20); 
        } 
       } 

       lastStart = tableState.pagination.start; 

       $scope.isLoading = false; 
      }, 1000); 

     } 

Ta funkcja jest wywoływana, gdy użytkownik przewijania w dół i osiągnąć próg (z przepustnicą oczywiście ze względów wydajności)

ale ważne jest to, gdzie usuwa się pierwsze wpisy w modelu, jeśli załadowano więcej niż określoną ilość danych.

+0

I oczywiście zdajesz sobie sprawę, że twój pkunker jest właściwie dobrą demonstracją problemów, o których mówię. Interfejs użytkownika zostanie zablokowany, gdy kolekcja rowCollection zostanie zaktualizowana. Tak, to tylko kilka milisekund, ale jest to zauważalne i denerwujące. – Agzam

+0

Interfejs użytkownika jest rzeczywiście blokowany na 1000 ms w timeoutie, który ma naśladować wywołanie serwera, ale możesz być mądrzejszy załadować jedną lub dwie strony z góry, więc ładowanie czas staje się przezroczysty – laurent

2

Chciałbym zwrócić uwagę na Angular Grid. Miałem dokładnie te same problemy, co powiedziałeś, skończyło się więc pisaniem (i udostępnianiem) mojego własnego widgetu siatki. Może obsługiwać bardzo duże zbiory danych i ma doskonałe przewijanie.

Powiązane problemy