Clusterize.js icon indicating copy to clipboard operation
Clusterize.js copied to clipboard

Using DOM Nodes instead of strings

Open STRd6 opened this issue 8 years ago • 8 comments

I'm making a spreadsheet app and rendering input elements inside table rows. The input values and event listeners were getting clobbered by being converted to strings and back.

In this PR I'm caching the real nodes and inserting/removing them. It works great for my purposes and may be of use to others but I understand if there may be reasons why the strings approach was taken.

It seems to work well in my limited test, but there's still an issue with the change on line 174 where we compute the height... I'm assuming the first three rows exist.

Anyway, thought I'd put up these changes in case you found them of interest!

STRd6 avatar Sep 03 '16 16:09 STRd6

I had also felt the need of storing actual dom nodes. however I'm also curious to understand why string approach has taken. @STRd6 Can you check how much memory your browser tab is consuming?

bharatpatil avatar Sep 03 '16 17:09 bharatpatil

Hello

Thanks! This may be convenient for someone. I remember someone had already requested such feature. Yep, @bharatpatil, the problem is in memory allocation.

Compare this two tabs in chrome's task manager strings, nodes I see almost 5x difference: 72K vs 348K

Because of that I can't replace main library with your implementation @STRd6, but we definitely can move it to separate branch and maintain there. I am guessing there are may be very specific situations when speed is more important than concerns about the memory

p.s. I like how easily you went through sources. changes with minimal interference :+1:

regarding height this.html([rows[0], rows[1], rows[2]]); single row should be enough this.html([rows[0], rows[0], rows[0]]);

NeXTs avatar Sep 03 '16 19:09 NeXTs

Using the same node rows[0] will only insert it once rather than three copies, another fix would be to check if (rows.length < 3) return; or however many is needed to accurately guess the sizes.

STRd6 avatar Sep 03 '16 21:09 STRd6

@NeXTs

I think this would be nice to merge with the main branch. Would there be a reason why we couldn't support both Strings and actual Dom nodes?

dkwin avatar Feb 14 '17 17:02 dkwin

yeah, there is a reason, read previous comments

NeXTs avatar Feb 14 '17 20:02 NeXTs

Hey @STRd6 sounds like we're working on similar apps (here's the one I'm working on). I was hoping to do the same thing, as I'm using choo/bel/yo-yo, which creates dom elements. Curious that it's 5x slower though.

timwis avatar Apr 16 '17 15:04 timwis

@timwis did you manage to make it faster actually?

dumblob avatar Oct 24 '21 15:10 dumblob

I'm afraid I have absolutely no memory of this. Sorry!

timwis avatar Oct 25 '21 09:10 timwis