NgxUiScroll

Unlimited bidirectional scrolling over limited viewport. A directive for Angular framework. Built with angular-library-starter. Inspired by angular-ui-scroll (AngularJS, since 2013). Demo is available at dhilt.github.io/ngx-ui-scroll. Since v2.0.0, the core of the ngx-ui-scroll library lives and develops as a separate zero-dependency npm package vscroll.

_{can donate? go here 👉
make open-source world better}

• Motivation
• Features
• Getting
• Usage
• Settings
• Adapter API
• Development

Motivation

Scrolling large datasets may cause performance issues. Many DOM elements, many data-bindings, many event listeners... The common way to improve the performance is to render only a small portion of the dataset visible to a user. Other dataset elements that are not visible to a user are virtualized with upward and downward empty padding elements which should provide a consistent viewport with consistent scrollbar parameters.

The *uiScroll is a structural directive that works like *ngFor and renders a templated element once per item from a collection. By requesting the external Datasource (the implementation of which is a developer responsibility) the *uiScroll directive fetches necessary portion of the dataset and renders corresponded elements until the visible part of the viewport is filled out. It starts to retrieve new data to render new elements again if a user scrolls to the edge of visible element list. It dynamically destroys elements as they become invisible and recreates them if they become visible again.

Features

• unlimited bidirectional virtual scroll
• lots of virtualization settings
• super easy templating
• infinite mode, demo
• horizontal mode, demo
• entire window scrollable, demo
• items with non-constant heights, demo
• API Adapter object to manipulate and assess the Scroller, demos

Getting

The *uiScroll directive is a part of UiScrollModule which is available via npm –

npm install ngx-ui-scroll

The UiScrollModule has to be imported in the App/feature module where it is going to be used.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { UiScrollModule } from 'ngx-ui-scroll';
import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    UiScrollModule
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

Usage

Basic usage template may look like

<div class="viewport">
  <div *uiScroll="let item of datasource">
    <b>{{item.text}}</b>
  </div>
</div>

where the viewport is a scrollable area of finite height:

.viewport {
    height: 300px;
    overflow-y: auto;
}

If the height of the viewport is not constrained, it will pull the entire content of the datasource and no scrollbar will appear.

*uiScroll acts like *ngFor, but the datasource is an object of special type (IDatasource). It implements method get to be used by the *uiScroll directive to access the data by index and count parameters. The directive calls Datasource.get method each time a user scrolls to the edge of visible element list. That's the API provided by the *uiScroll directive.

import { IDatasource } from 'ngx-ui-scroll';

export class AppComponent {
  datasource: IDatasource = {
    get: (index, count, success) => {
      const data = [];
      for (let i = index; i <= index + count - 1; i++) {
        data.push({ text: 'item #' + i });
      }
      success(data);
    }
  };
}

Datasource.get method must provide an array of count data-items started from index position. If there are no items within given range [index; index + count - 1], an empty array has to be passed. Empty result (or result which length is less than count) is being treated as the edge of the dataset (eof/bof), and no further requests for preceding/tailing items will be issued.

Datasource.get has 3 signatures: callback based, Promise based and Observable based. So, if we want some remote API to be a source of our data, basically it may look like

  datasource: IDatasource = {
    get: (index, count) =>
      this.http.get(`${myApiUrl}?index=${index}&count=${count}`)
  };

More details could be found on the Datasource demo page.

Settings

Datasource implementation along with get method property may include settings object property:

  datasource: IDatasource = {
    get: ...,
    settings: {
      minIndex: 0,
      startIndex: 0,
      ...
    }
  };

Settings are being applied during the Scroller initialization and have an impact on how the Scroller behaves. Below is the list of available settings with descriptions, defaults, types and demos.

Adapter API

The Scroller has API to assess its parameters and provide some manipulations at runtime. This API is available via special Adapter object. The datasource needs to be instantiated via operator "new" for the Adapter object to be added to it:

import { Datasource } from 'ngx-ui-scroll';
...
  datasource = new Datasource({
    get: ... ,
    settings: { ... }
  });

Then this.datasource.adapter.packageInfo, this.datasource.adapter.reload() and other Adapter expressions become available. For better typing, it is recommended to specify the Adapter type as follows:

import { Datasource, IAdapter } from 'ngx-ui-scroll';
...
  datasource = new Datasource<IAdapter<MyItem>>({
    get: ... ,
    settings: { ... }
  });

MyItem should reflect the structure of items that the Datasource will deal with. It is "unknown" by default, and if not set, for example, this.datasource.adapter.firstVisible.data.id expression will produce typescript error: Object is of type 'unknown'. There are some Adapter props and methods dealing with MyItem, and if used, MyItem should be specified.

Below is the list of read-only properties of the Adapter API with descriptions and links to demos.

Below is the list of invocable methods of the Adapter API with description and links to demos.

Along with the documented API there are some undocumented features that can be treated as experimental. They are not tested enough and might change over time. Some of them can be found on the experimental tab of the demo app.

All of the Adapter methods are asynchronous, because they work with DOM and may take time to complete. For this purpose the Adapter methods return a Promise resolving at the moment when the Scroller terminates its internal processes triggered by the invocation of the correspondent Adapter method. It is called Adapter Return API. This promise has exactly the same nature as the promise of the relax method. Both "Relax" and "Return API" are the instruments of the App-Scroller processes normalization. It might be quite important to run some logic after the Scroller finishes its job and relaxes. Below is an example of how an explicit sequence of the Adapter methods can be safely implemented:

const { adapter } = this.datasource;
const predicate = ({ $index }) => $index === indexToReplace;
await adapter.relax();
await adapter.remove({ predicate });
await adapter.insert({ items: [itemToReplace], before: predicate });
console.log('Replacement done');

For more information, see Adapter demo page.

Development

There are some npm scripts available from package.json:

• npm start to run demo App on port 4200
• npm test to run Karma tests
• npm run build to build the ngx-ui-scroll module into the ./dist folder
• npm run pack:install to build tar-gzipped version of package and install it locally into ./node_modules
• npm run build-app to build demo App into the ./dist-app folder

Along with settings object the datasource implementation may include also devSettings object:

import { Datasource } from 'ngx-ui-scroll';
...
  datasource = new Datasource({
    get: ... ,
    settings: { ... },
    devSettings: {
      debug: true,
      immediateLog: true,
      ...
    }
  });

The development settings are not documented. Information about them can be obtained directly from the source code. The Scroller has "debug" mode with powerful logging which can be enabled via devSettings.debug = true. Also, with devSettings.immediateLog = false the console logging will be postponed until the undocumented Adapter method showLog is called (datasource.adapter.showLog()). This case could be important from the performance view: there might be too many logs and pushing them to the console output immediately could slow down the App.

Any participation is welcome, so feel free to submit new Issues and open Pull Requests.

2021 © dhilt, Hill30 Inc