I'm a web developer and consultant, web GDE, and author of open source libraries. I co-founded 500Tech, a company that specializes in frontend technologies. I love coding, and love speaking about code
you record heights of 50 rows, you change the width to compress the rows, depending on contents, some of the rows increase in their height, your stored heights are now invalid
I'm a web developer and consultant, web GDE, and author of open source libraries. I co-founded 500Tech, a company that specializes in frontend technologies. I love coding, and love speaking about code
I think this kind of situation is problematic for a virtual scroll of this sort, since the heights are returned per row, and usually not calculated based on measuring DOM nodes' dimensions.
So I would limit the "shrink factor" of the tree view and prevent the rows from wrapping and increasing in height.
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.
Why should the width affect the calculations? I'm not following
you record heights of 50 rows, you change the width to compress the rows, depending on contents, some of the rows increase in their height, your stored heights are now invalid
I think this kind of situation is problematic for a virtual scroll of this sort, since the heights are returned per row, and usually not calculated based on measuring DOM nodes' dimensions.
So I would limit the "shrink factor" of the tree view and prevent the rows from wrapping and increasing in height.