DOM Manipulation: My Way for Paging

I got my first smartphone 3 years back, I was very excited of everything about it. I was more productive and connected to world in real time.

I had a Nokia S40 phone before that. Android has a huge offerings in regards of everything. As being a developer, its most important to me, we like to have more controls, more customization and more in everything else. I could literally change everything on my phone. I played a lot with my Yureka, I tried 300+ of apps, launchers, custom roms, and then went to change firmware also to try new custom roms and get VoLTE on it unofficially. Woh, that was a lot of fun.

I was amused with camera a little bit more in hardware side. I signed up on EyeEm, a platform for photographers, just after getting the phone. I hated Insta then, for being too-celeb and glamorous instead of just being a decnet photographer’s platform. But yeah, I too started doing Insta because of networking mostly. It has easier reach to people, lot more options to play with and they offer dashboard too, awesome!

Soon I was a power user on Insta. I had a hunger of posts from others to see what and how they are doing in Photography, I used to scroll till infinity until my phone starts hanging and stop responding.

What ? Hanging ? Instagram ?

Yeah! That’s the point of this blog today. Although, now it doesn’t happen on my OnePlus, but it was common on the mid-ranger Yureka.

I knew its memory management that time. But, few months back, I came to know the more reasons behind this slowness precisely. If you are familiar with HTML and JS, you will really relate to this post.

Its DOM manipulation, the heaviest operation for a code to manage rendering and re-rendering when we update the DOM. DOM is document object model. Please Google it in case you are not sure.

I will explain Insta case first,
I kept seeing posts suppose 100 in numbers, which are in memory now, and DOM length is 100 too. So when I scroll it more, it fetches more posts and tries to fit in the DOM to show to me. Here DOM puts new posts to the existing DOM. While doing this, it has to do more things, like re-calculation of edges and blocks to re-render UI blocks properly for all 100+ posts and have to do all pre-process.
Its really a huge operation and comes very heavy on processor and count of posts killing memory too. Result, your phone is not able to respond now!

This sounds common and I have seen a lot of like this, except WhatsApp, It’s (y) rendering was always flawless at any time.
I don’t know what awesomeness WhatsApp has done, but I have idea to rescue from this bad bad problem, if you also happen to have this from a developer perspective.

To make it short, I will only talk about rendering fix. For memory management, you can simply keep what you are showing in view. Rest is not necessary and can be fetched on demand.

There is one catch here,following flow fits better for horizontal navigation. But you can simulate scroll gesture with it too.
By now you would have been aware of lazy loading and all, so lets try to come to point as faster as possible without telling other things. 

I will take one example, suppose I need to show 36 items to in page.
First I should not show all 36 at once, 36 is just an example number here, think of 36000 in your mind.
So, I will show n items, suppose 10 at a shot in a page. Now user taps to see next items from navigation bar.
I fetch 11-20 to show next 10 items . I wont add it to the current DOM or recreate DOMs. Instead, I use the same existing 10 DOM blocks node values to show these new items in view.

Node value ? <span>yeah</span>, ‘yeah’ is the value of span node here.

So, you wont create or update any DOM, you will simply change its value. Very light operation and you will never feel lighter than this.

I am lazy to put image to illustrate this. Think of a container, having 10 dices at any time. And when people want to see more, you change the number written on dices, instead of replacing it with next dices or adding next dices into the container.

Okay, what about 1-10 now, that’s gone from DOM. You will be showing it again, using same DOM behavior, when user wants Previous items.
So, at any time you will have only 10 DOM data in memory and processor will be happy, you are not putting pressure on that guy :p

That’s it, problem is gone. You will never realize the slowness, even after being in 10000 pages, because, only 10 static DOM block is in memory and there is no heavy DOM manipulation involved.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *