Paged Data Browsers

This library provides simple components to display filtered and paged data from some service.

There are currently two components, one for displaying a flat list of data, and another to display hierarchically structured data, combining a tree view with paging.

Also, there is a LRU cache service and a compact pager used in the paged tree component.

Paged List

Paged list support is provided by a single utility class, PagedListStore. This templated class provides logic for:

• a filter object of type F;
• a list element object of type E.

So you need:

• a filter class to represent your elements filter (for F).
• an element item class (for E).
• a service to fetch data, implementing interface PagedListStoreService<F, E>. In this shell, a local service provides mock data.

Paged Tree

Services

The core of the tree is a PagedTreeStore.

Tree nodes extend interface TreeNode, having:

• id
• parentId
• y and x
• label
• tag
• hasChildren

The corresponding node filter (TreeNodeFilter) has tags and parentId, both optional. Your filters will extend this one, just like your nodes extend TreeNode.

A paged tree node (PagedTreeNode<F> where F is TreeNodeFilter or any extension of it) extends a TreeNode by adding paging (PagingInfo: page number, count and total items), filtering, and expansion state. All the nodes entering the store are enriched with such data, thus becoming paged nodes.

The service which fetches nodes into the store is PagedTreeStoreService<F>. It provides a single method, getNodes(filter, pageNumber, pageSize, hasMockRoot?) to get the specified page of nodes.

The paged tree store (PagedTreeStore<E,F> where E=paged tree node and F=node filter) is the local store for tree nodes. Its ideal hierarchy is:

• radix: a single, static radix node (Y=0, X=1) including all the other nodes. This is like the ground where one or more trees can be planted. Each tree is identified by a node's tag.
  • roots: the direct children of the radix (Y=1, X=1-N).
    • other descendant nodes, each with a higher Y level.

The essential store data are:

• flat list of paged nodes (nodes$).
• list of tree tags (tags$).
• global filter (filter$). This gets combined with (overridden by) node-specific filters, when specified. You can set it with setFilter. To set the filter for the children of a specific node use setNodeFilter.
• page size (pageSize), get/set property.

To initialize the store, you call reset, which loads root nodes (via its service's getRootNodes) and their direct children. When getting the children for each root node, an internal cache is used to minimize server fetches (via getPageFromCacheOrServer). The nodes got from the service are enriched with data required as paged tree nodes (paging, filtering, expansion).

Methods related to the cache are clearCache() and hasCachedPage(pageNumber, filter).

Nodes are managed in the tree with:

• expand(id)
• expandAll(id)
• getChildren(id)
• getNodes()
• getRootNode()
• isEmtpy()
• collapse(id)
• collapseAll()
• changePage(parentId, pageNumber)
• setFilter(filter)
• setNodeFilter(id, filter)
• reset()

Component

The component for visualizing each single node of the paged tree is BrowserTreeNodeComponent. This wraps some HTML content providing a toggle button to expand/collapse the node, a paging control for the node's children, and a button to edit the node's filter. You should then provide the HTML content to display the node's data inside this component, e.g.:

 <pdb-browser-tree-node [node]="node">
   <your-node-view [node]="node" />
 <pdb-browser-tree-node>

This component API has:

• ➡️ node of type PagedTreeNode.
• ➡️ paging (PagingInfo) with optional data about children nodes paging.
• ➡️ debug (boolean) flag to toggle debug information in the view.
• ➡️ hideLabel (boolean) flag to hide the node's loc and label. This is useful if you want to provide your own view for the node, between the expansion toggle and the filter edit button. In this case, in your consumer template provide your own view as the content of this component. If instead you are fine with the default loc and label, and just want to add more data to the view, then you can just add your own content to this component's template, without setting this property to true.
• ➡️ hidePaging (boolean): true to hide the node's paging control unless hovered.
• 🔥 toggleExpandedRequest (PagedTreeNode): emitted when the user wants to toggle the expanded state of the node.
• 🔥 changePageRequest (PageChangeRequest): emitted when the user wants to change the page number of the node's children.
• 🔥 editNodeFilterRequest (PagedTreeNode): emitted when the user wants to edit the node's filter for its children.

You should provide your components for:

• the node's filters component. This is used both for global and node-specific filters (in the latter case as a popup).
• the tree browser component. This combines:
  • a filters component for global filters. This dummy component gets a filter$ and emits filterChange.
  • a tree view.

The tree browser component uses a nested instance of PagedTreeStore<N,F>, typically injected via a middleman service like the sample PagedTreeBrowserService, which provides a new instance of the store to the component. The component orchestrates:

• filter$ (observable of filters). This simply binds to the global filter of the nested store.
• nodes$ (observable of paged tree nodes). Each of these nodes is displayed via a BrowserTreeNodeComponent. This simply binds to the nodes from the nested store, so these are all the nodes present in it. They are displayed in a list with various amounts of indentation representing the tree's hierarchy.
• page change requests
• filter change requests
• expand/collapse requests
• reset requests

All the requests are accomplished by virtue of the nested store.