{"id":83,"date":"2018-05-01T12:41:13","date_gmt":"2018-05-01T12:41:13","guid":{"rendered":"http:\/\/www.bullcrane.com\/angular\/?p=83"},"modified":"2018-05-02T01:18:16","modified_gmt":"2018-05-02T01:18:16","slug":"flex-layout-performance-problem","status":"publish","type":"post","link":"http:\/\/www.bullcrane.com\/angular\/2018\/05\/01\/flex-layout-performance-problem\/","title":{"rendered":"Flex-layout performance problem"},"content":{"rendered":"

When I was first developing Shufflizer, I resisted making it break into pages for large playlists.\u00a0 Scrolling a 2000 item list really isn’t that big of a deal.\u00a0 Spotify’s native Windows app doesn’t bother with paging, why should I?<\/p>\n

I get album art images, however, and eventually I admitted to myself that this was slowing down the initial load for large playlists.\u00a0 Since I really wanted album art images, but without unusually long load times, I was faced with the choice of either lazy loading images or putting in paging.\u00a0 I tried a lazy loading solution and did not like it.\u00a0 Plus I realized that the first and last songs would be the most commonly accessed, given the way the app was shaping up, and that paging would not hinder this use pattern much if I put in first<\/em> and last<\/em> buttons.\u00a0 So I opted for paging.<\/p>\n

I am using Angular Material, so I proceeded with its data table paging component.<\/p>\n

\"\"<\/p>\n

This all worked rather well.<\/p>\n

If the user opted for a large page size with a big playlist, it took a few moments to render but there was some sense of the cause – having just picked a large page size.\u00a0 Then after the initial render time, the app performed amazingly well.\u00a0 In the old days before Angular I would have to code my own optimized “surgical” manipulation of the DOM in order to get the kind of performance Angular was giving me automatically.<\/p>\n

If the user left the page size setting unchanged, then initial load time was good and the most common use case still worked fine.<\/p>\n

Then I introduced the flex-layout responsive API and performance really took a hit.<\/h6>\n

I got excited when I discovered the special responsive features<\/a> of the flex-layout module.\u00a0 Now I could make adjustments to the layout based on the screensize.\u00a0 These are not flex css directives, but are delivered along with the flex-layout package as additional tools for adjusting “specific, non-flexbox styles when a specific mediaQuery has activated.”\u00a0 Standard break-points are provided for screen widths:<\/p>\n\n\n\n\n\n\n\n
xs (extra-small)<\/td>\n<600 px<\/td>\n<\/tr>\n
sm (small)<\/td>\n600 to 959 px<\/td>\n<\/tr>\n
md (medium)<\/td>\n\u00a0960 to 1279 px<\/td>\n<\/tr>\n
lg (large)<\/td>\n\u00a01280 to 1919 px<\/td>\n<\/tr>\n
xl (extra-large)<\/td>\n\u00a01920 to 5000 px<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

I laced the HTML with the markup. Here is an example.\u00a0 The default is this button does not show (fxHide), but if the screen width is greater than small, then the button renders (fxShow.gt-sm):<\/p>\n

<button mat-button fxHide=\"true\" fxShow.gt-sm=\"true\" ...<\/pre>\n
I liked the resulting phone, tablet, and HD layouts I came up with, but was only working with my default 100 item pages while developing.\u00a0 It was a bit slower but not bad.\u00a0 Then I finally tried the next notch up – 500 items per page.\u00a0 The app ground to a halt.<\/p>\n
I think it is doing what some people call “layout thrashing.”<\/p>\n
I am going to play around with the mediaquery directives and see if I can improve this.<\/p>\n","protected":false},"excerpt":{"rendered":"
When I was first developing Shufflizer, I resisted making it break into pages for large playlists.\u00a0 Scrolling a 2000 item list really isn’t that big of a deal.\u00a0 Spotify’s native Windows app doesn’t bother with paging, why should I? I get album art images, however, and eventually I admitted to myself that this was slowing … <\/p>\n
Continue reading “Flex-layout performance problem”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[],"_links":{"self":[{"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/posts\/83"}],"collection":[{"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/comments?post=83"}],"version-history":[{"count":14,"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/posts\/83\/revisions"}],"predecessor-version":[{"id":96,"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/posts\/83\/revisions\/96"}],"wp:attachment":[{"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/media?parent=83"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/categories?post=83"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.bullcrane.com\/angular\/wp-json\/wp\/v2\/tags?post=83"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}