Properly assigning styles by deep copy #722
Conversation
Siemienik
commented
Jan 14, 2019
- var to const/let refactoring
+ var to const/let refactoring
| @@ -367,6 +367,6 @@ Row.prototype = { | |||
| this.hidden = value.hidden; | |||
| this.outlineLevel = value.outlineLevel || 0; | |||
|
|
|||
| this.style = value.style || {}; | |||
| this.style = value.style && JSON.parse(JSON.stringify(value.style)) || {}; | |||
There was a problem hiding this comment.
I'm not a big fan of this, since there's a couple of subtle ways this can fail or lose things depending on the shape of the object. do we know what values each key of value.style can hold? is it just a flat object of "some string": "another string" or can it also hold numbers, arrays, functions or other objects?
There was a problem hiding this comment.
it is only object that keep configuration of styles
there aren't any functions or getters/setters
There was a problem hiding this comment.
gotcha. Can you help me understand the performance impact here?
JSON.parse(JSON.stringify()) is quite slow and it would suck if this actually runs for all (or most) rows. Also, it increases the memory overhead a bit. How many rows will have this property?
There was a problem hiding this comment.
personally I think it's much better to write style cloning function in utils ;)
There was a problem hiding this comment.
Using JSON is indeed pretty slow to copy things. You could use e.g., https://github.com/davidmarkclements/rfdc for now (I would normally just recommend to use object spread but that's not available in versions below 8 and slow before v.10 or v.11 😄).
@alubbe the current API does not seem to have performance in mind. If the user changes any input that should be registered in a clean way so all internals can work side effect free. This does not seem to be possible without the penalty here. Using getters and setters might reduce the overhead by only copying values that have to be changed but as far as I see it that would probably be pretty brittle with the current code.
There was a problem hiding this comment.
I agree - let's merge it and then actually benchmark why this library is slow and fix those, as opposed to pre-optimizing a bugfix
|
Let's do these refactorings as a separate PR - as a matter of fact, this is better done by an automated tool like |
|
@guyonroche any chance to get write access to merge PRs like this? |
|
@alubbe I really dislike do changes in all files in one time, it will make a lot of conflicts |
|
on the contrary, doing it one file at a time makes for a really messy git log (making git blame useless) and introducing a highly inconsistent code basis. you are right with regards to the conflicts, so I suggest we merge what we can in the next 14 days - afterwards we merge the big style pr and I update every open PR by hand. how does that sound? |
| @@ -76,9 +76,9 @@ describe('WorkbookReader', function() { | |||
| }); | |||
|
|
|||
| describe('edit styles in existing file', function(){ | |||
| beforeEach(async function(){ | |||
| beforeEach(function(){ | |||
There was a problem hiding this comment.
why? I quite like moving things to async/await. the test suite runs on node, so there's no transpiling here
There was a problem hiding this comment.
we currently support node v6 :(
https://travis-ci.org/exceljs/exceljs/builds/479501545?utm_source=github_status&utm_medium=notification
|
@Siemienik could you help understand if the object cloning is happening on the hot path for each row? how often do rows have this style property? |
|
Let's merge it then - I still don't have access to do it though :( |