Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: add CSP safe option for DataView filtering and adjusting inline css for CSP #908
fix: add CSP safe option for DataView filtering and adjusting inline css for CSP #908
Changes from 1 commit
990d17d
b9cd46c
b70eee8
9d37139
ad54e65
d7f2b4b
0fd72a4
113b613
7cae5a2
966c804
99f0443
22ad66a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as before I don't want to keep 2 implementations to support unless there's a big perf hit which I don't think there is from previous discussions. Have you tried the
autoHeight
grid yet?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting tried to add autoHeight: true with 50.000 rows
tho with nonce seems to be faster than the non nonce version, around 1/3 faster sometimes 1/2 faster
ex a search without nonce took 400ms where with nonce it took 200ms
Initial load took 1500 ms without nonce and 1000 ms with nonce (first execution)
second run took 1300 ms without nonce down to 900 with nonce (second execution)
not exactly sure why on initial load it gets called twice tho this might be a concern (not sure current prod does this, havent checked)
Edit:
Hmm interesting the dataView code even on prod requests renderRows twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I can see that the double doesn't make much difference 1 vs 2ms isn't a big deal I guess, but when you add them up in the
autoHeight
, 400ms is definitely noticeable. I'm not sure what to do at this point but I feel the worst case should always be considered before making a decision andautoHeight
is definitely the worst case usage I assume. If we can find a way to remove that double call ofrenderRows
then perhaps it might be more acceptable to go with the nonce (however that won't help theautoHeight
example since it doesn't the DataView in that demo). I'm not sure what to go with at this point... I feel we might have to keep both approach but I'm not too keen about itThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you might have misunderstood my text, new code is faster than the old version
first set of times is
without nonce so old code
and second time iswith nonce so new code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I got them reversed indeed, if that's the case then yeah let's keep only new code (with nonce) since that will help with CSP compliance. We can also merge my other PR #894 and I think we'll be close enough to be CSP compliant. So I assume you will push the new code change, it's not in the PR yet right?
I'm still curious to see if you can find why it does that, but I think that could, and probably should, be a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've commited the cleanup now and everything as far as i know should be in this PR