Hi, thanks for the code and taking the time to document it so well. It's really a high quality article.
I've made some changes that might be interesting:
added an interface scroll-item that replaces hero-message to make it reusable, scroll item has 2 values: measuredHeight and predictedHeight, the scrollStrategy uses this instead of hero-message and you can implement it onto your objects.
added a directive scroll-item.directive that only measures it's height in afterViewInit and updates the scrollItem that was passed along. So no need to recalculate or check again in the scrollStrategy updateHeightCache and also can do away with the data-hm-id because its not needed anymore.
ScrollStrategy will simply check if measuredHeight is available (set by directive in 2) and use that, else predictedHeight.
Thanks! Indeed, what you've proposed is the way to go, if you want a generic solution. I myself use almost the same approach with a scroll item directive on production since we need virtual scrolling in couple of places. Anyway, I intentionally wanted to go with a concrete example, as mentioned in the conclusion of the article, because it is easier to grasp the core concept this way rather than going generic. I believe/hope that the readers can conclude the rest themselves, as you did.
Few notes though:
using afterViewInit is definitely more inline with Angular compared to the DOM operations that I used. Have to keep in mind that the children of the scroll item might not be rendered at that time though. This might very well be valid for the direct DOM tree peek too, but it's probably harder to verify given you'll need to explore the internals of the virtual scroll viewport. The new afterRender hook might come handy here, I think.
There aren't recalculations since we are caching all results. As for checking already cached results – it's a O(1) complexity, so we are good.
Thanks for the input!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, thanks for the code and taking the time to document it so well. It's really a high quality article.
I've made some changes that might be interesting:
scroll-itemthat replaceshero-messageto make it reusable, scroll item has 2 values:measuredHeightandpredictedHeight, thescrollStrategyuses this instead ofhero-messageand you can implement it onto your objects.afterViewInitand updates the scrollItem that was passed along. So no need to recalculate or check again in the scrollStrategyupdateHeightCacheand also can do away with thedata-hm-idbecause its not needed anymore.measuredHeightis available (set by directive in 2) and use that, elsepredictedHeight.Cheers,
Elger
Thanks! Indeed, what you've proposed is the way to go, if you want a generic solution. I myself use almost the same approach with a scroll item directive on production since we need virtual scrolling in couple of places. Anyway, I intentionally wanted to go with a concrete example, as mentioned in the conclusion of the article, because it is easier to grasp the core concept this way rather than going generic. I believe/hope that the readers can conclude the rest themselves, as you did.
Few notes though:
afterViewInitis definitely more inline with Angular compared to the DOM operations that I used. Have to keep in mind that the children of the scroll item might not be rendered at that time though. This might very well be valid for the direct DOM tree peek too, but it's probably harder to verify given you'll need to explore the internals of the virtual scroll viewport. The newafterRenderhook might come handy here, I think.O(1)complexity, so we are good.Thanks for the input!