ngx-virtual-scroller - npm Package Compare versions

Comparing version 1.0.10 to 1.0.11

CHANGELOG.md

@@ -0,1 +1,5 @@
+# v1.0.11
+
+* Fix issue #258
+
 # v1.0.10
@@ -2,0 +6,0 @@

dist/virtual-scroller.js

@@ -812,3 +812,3 @@ "use strict";
         var defaultScrollLengthPerWrapGroup = dimensions[this._childScrollDim];
-        var startingWrapGroupIndex = Math.ceil(arrayStartIndexWithBuffer / dimensions.itemsPerWrapGroup) || 0;
+        var startingWrapGroupIndex = Math.floor(arrayStartIndexWithBuffer / dimensions.itemsPerWrapGroup) || 0;
         if (!this.enableUnequalChildrenSizes) {
@@ -815,0 +815,0 @@ return defaultScrollLengthPerWrapGroup * startingWrapGroupIndex;

package.json

 {
   "name": "ngx-virtual-scroller",
-  "version": "1.0.10",
+  "version": "1.0.11",
   "description": "Angular 4+ module for virtual -infinite- list. Supports horizontal/vertical, variable heights, & multi-column",
@@ -5,0 +5,0 @@ "main": "dist/virtual-scroller.js",

README.md

@@ -200,42 +200,2 @@
 
-## Performance (and the executeRefreshOutsideAngularZone flag)
-
-Each component in Angular by default uses the ChangeDetectionStrategy.Default "CheckAlways" strategy. This means that Change Detection cycles will run frequently and will check *EVERY* data-binding expression on *EVERY* component to see if anything has changed. This makes it easier for programmers to code apps, but also makes apps slow. For simple apps it may not be noticed, but as apps become more complex it quickly becomes apparent. The correct way to fix this is to make cycles as fast as possible and to avoid unnecessary ChangeDetection cycles. Cycles will be faster if you avoid complex business logic in data-bindings. You can avoid unnecessary Cycles by converting your components to use ChangeDetectionStrategy.OnPush. When doing this, you have to explicitly tell Angular when you're modifying the value of a data-binding expression, because it will not be checked automatically. This topic can be researched online, there are a lot of detailed articles about it.
-
-virtual-scroller causes a full ChangeDetection cycle to run during every refresh (scrolling/etc). This is standard practice for all Angular components/libraries. If you have an app that is usually fast, but becomes slow while scrolling virtual-scroller, the correct solution is to convert all of your components to use ChangeDetectionStrategy.OnPush. However, this may not be easy. If you want a quick solution that masks the real problem, you can use the scrollThrottlingTime, scrollDebounceTime, or executeRefreshOutsideAngularZone APIs.
-
-The executeRefreshOutsideAngularZone is strongly discouraged because it disables Angular's automatic Change Detection from any code paths started by virtual-scroller. This essentially randomly converts some of your app's components to use ChangeDetectionStrategy.OnPush without you explicitly choosing to do so. Because this wasn't an intentional choice, you won't have code to tell Angular when those components need to re-bind their UI, which will cause the DOM to not update when it should. These UI bugs won't be consistent, because it'll depend on which code path caused your data-binding model to change. The list of potential code paths in virtual-scroller is too long to make an exhaustive list & which of your components are affected is completely dependent on what business logic you execute in response to those virtual-scroller code paths. If you choose to use this flag, it's your responsibility to do extensive testing in your app and to thoroughly read and understand the virtual-scroller source code. You probably should not make this choice unless you have a strong understanding of Angular's ChangeDetection internals.
-
-Although executeRefreshOutsideAngularZone is strongly discouraged, it is up to the consuming app's programmer to determine if it's the right decision for their application.
-
-If you're lucky, you can implement this flag as follows and get a free speed boost while scrolling:
-```ts
-//parent.component.ts
-constructor (public changeDetectorRef: ChangeDetectorRef) { }
-```
-
-```html
-<!-- parent.component.html -->
-<virtual-scroller #scroll [items]="items" [executeRefreshOutsideAngularZone]="true" (vsUpdate)="changeDetectorRef.detectChanges();">
-    <my-custom-component *ngFor="let item of scroll.viewPortItems">
-    </my-custom-component>
-</virtual-scroller>
-```
-
-If you're unlucky, this will cause a bunch of UI bugs because you've disabled Angular's change detection for any code path started by virtual-scroller. In these cases, you'll have to track down & fix each bug separately (usually by adding `changeDetectorRef.detectChanges()`). These bugs might continue to crop up in the future as you make minor code changes. In the end, you might decide to stop using the buggy flag & instead do the correct fix which is to switch all your components to using ChangeDetectionStrategy.OnPush.
-
-## Additional elements in scroll
-
-If you want to nest additional elements inside virtual scroll besides the list itself (e.g. search field), you need to wrap those elements in a tag with an angular selector name of #container.
-
-```html
-<virtual-scroller #scroll [items]="items">
-    <input type="search">
-    <div #container>
-        <my-custom-component *ngFor="let item of scroll.viewPortItems">
-        </my-custom-component>
-    </div>
-</virtual-scroller>
-```
-
 ## Use parent scrollbar
@@ -492,2 +452,42 @@
 
+## Additional elements in scroll
+
+If you want to nest additional elements inside virtual scroll besides the list itself (e.g. search field), you need to wrap those elements in a tag with an angular selector name of #container.
+
+```html
+<virtual-scroller #scroll [items]="items">
+    <input type="search">
+    <div #container>
+        <my-custom-component *ngFor="let item of scroll.viewPortItems">
+        </my-custom-component>
+    </div>
+</virtual-scroller>
+```
+
+## Performance (and the executeRefreshOutsideAngularZone flag)
+
+Each component in Angular by default uses the ChangeDetectionStrategy.Default "CheckAlways" strategy. This means that Change Detection cycles will run frequently and will check *EVERY* data-binding expression on *EVERY* component to see if anything has changed. This makes it easier for programmers to code apps, but also makes apps slow. For simple apps it may not be noticed, but as apps become more complex it quickly becomes apparent. The correct way to fix this is to make cycles as fast as possible and to avoid unnecessary ChangeDetection cycles. Cycles will be faster if you avoid complex business logic in data-bindings. You can avoid unnecessary Cycles by converting your components to use ChangeDetectionStrategy.OnPush. When doing this, you have to explicitly tell Angular when you're modifying the value of a data-binding expression, because it will not be checked automatically. This topic can be researched online, there are a lot of detailed articles about it.
+
+virtual-scroller causes a full ChangeDetection cycle to run during every refresh (scrolling/etc). This is standard practice for all Angular components/libraries. If you have an app that is usually fast, but becomes slow while scrolling virtual-scroller, the correct solution is to convert all of your components to use ChangeDetectionStrategy.OnPush. However, this may not be easy. If you want a quick solution that masks the real problem, you can use the scrollThrottlingTime, scrollDebounceTime, or executeRefreshOutsideAngularZone APIs.
+
+The executeRefreshOutsideAngularZone is strongly discouraged because it disables Angular's automatic Change Detection from any code paths started by virtual-scroller. This essentially randomly converts some of your app's components to use ChangeDetectionStrategy.OnPush without you explicitly choosing to do so. Because this wasn't an intentional choice, you won't have code to tell Angular when those components need to re-bind their UI, which will cause the DOM to not update when it should. These UI bugs won't be consistent, because it'll depend on which code path caused your data-binding model to change. The list of potential code paths in virtual-scroller is too long to make an exhaustive list & which of your components are affected is completely dependent on what business logic you execute in response to those virtual-scroller code paths. If you choose to use this flag, it's your responsibility to do extensive testing in your app and to thoroughly read and understand the virtual-scroller source code. You probably should not make this choice unless you have a strong understanding of Angular's ChangeDetection internals.
+
+Although use of the executeRefreshOutsideAngularZone flag is strongly discouraged, it is up to the consuming app's programmer to determine if it's the right decision for their application.
+
+If you're lucky, you can implement this flag as follows and get a free speed boost while scrolling:
+```ts
+//parent.component.ts
+constructor (public changeDetectorRef: ChangeDetectorRef) { }
+```
+
+```html
+<!-- parent.component.html -->
+<virtual-scroller #scroll [items]="items" [executeRefreshOutsideAngularZone]="true" (vsUpdate)="changeDetectorRef.detectChanges();">
+    <my-custom-component *ngFor="let item of scroll.viewPortItems">
+    </my-custom-component>
+</virtual-scroller>
+```
+
+If you're unlucky, this will cause a bunch of UI bugs because you've disabled Angular's change detection for any code path started by virtual-scroller. In these cases, you'll have to track down & fix each bug separately (usually by adding `changeDetectorRef.detectChanges()`). These bugs might continue to crop up in the future as you make minor code changes. In the end, you might decide to stop using the buggy flag & instead do the correct fix which is to switch all your components to using ChangeDetectionStrategy.OnPush (which requires you to also explicitly tell Angular any time you change your data-model so Angular knows to re-bind).
+
 ## scrollDebounceTime / scrollThrottlingTime (for performance reasons)
@@ -494,0 +494,0 @@

No alert changes

Improved metrics

Total package byte prevSize

13236478

No dependency changes