When developing apps, it\u2019s fair to expect that a large list of data will be needed. Until now, if you were developing a hybrid app and wanted to show the user a list of 100+ items, that was just too bad. The phone\u2019s browser would laugh at you as you scrolled through your list at ten frames per second. <\/p>\n
After trying to fix this with every trick you knew, your frustration would slowly mount until you sighed and acknowledged that the web was just too limited for realistic apps. Then you would be forced to learn Objective-C or Java and start building a native app.<\/p>\n
Fortunately, developers no longer need to face such dramatic scenarios, because Ionic has a solution.<\/p>\n
<\/p>\n
Native apps render huge lists quite seamlessly. A contacts app, for example, can display thousands of items with no problem at all. Achieving this is actually very simple: Native APIs are only rendering the specific items that should be currently visible, relative to the user’s scroll position. <\/p>\n
This means if 10 items can fit in the screen\u2019s viewport, and the user has scrolled halfway down a list of 100 items, only items 50-60 should be rendered.<\/p>\n
This is<\/em> possible to do with web technologies, we just have to game the system a little bit…<\/p>\n We know our end goal: Limit the rendering of items in a large list. So how do we get there?<\/p>\n When figuring this out for Ionic, we were heavily inspired by iOS\u2019s UICollectionView. In our implementation, there are three main components:<\/p>\n The The The biggest piece of the puzzle is how to performantly render new elements as the user scrolls through the list.<\/p>\n While scrolling down, elements that were just at the top of the screen are no longer visible. What should be done with these elements? Our first thought was to remove these from the DOM.<\/p>\n The solution we found to be the most performant, though, is to hide these no longer visible elements and mark them as \u201cavailable for rendering.\u201d If we were to remove no-longer-visible elements, we would have to append them to the DOM again later, as the user scrolled down. And appending new elements to the DOM while the user scrolls causes noticeable jankiness.<\/p>\n Later, the Manager asks the DataSource, \u201cGive me an element matching data at index 16, so I can render it.\u201d The DataSource then finds an element that\u2019s already in the DOM and marked as available. It assigns item 16\u2019s data to that element\u2019s scope and gives the element to the Manager. <\/p>\n The Manager then transforms the element into its proper position in the view, using the width and height given by the developer at the start to calculate its position. We use Javascript to transform the elements into their proper positions–again, so that we don\u2019t have to worry about ordering elements in the DOM as the user scrolls. The actual order of elements in the list doesn\u2019t matter: They are transformed into the proper position to look like they\u2019re in the proper order, and the end user can\u2019t tell the difference. <\/p>\nThe Basic Concept<\/h3>\n
\n
collection-repeat<\/code> directive: The developer adds this directive to the element he or she wants to repeat, supplies an array of data, and gives the size (width and height) of each element in that array using a simple expression.<\/p>\n<\/li>\nCollectionRepeatManager<\/code>: This takes the size of the scroll view containing the list, the current scroll value, and the size of each item to figure out exactly which items need to be rendered. <\/p>\n<\/li>\nCollectionDataSource<\/code>: The Manager will ask the DataSource for an item at a certain index, and the DataSource will give the Manager a complete DOM element representing that item.<\/p>\n<\/li>\n<\/ol>\nThe Secret Sauce<\/h3>\n
Problem Solved. Now What?<\/h3>\n