-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
🆕 Update width only if it isn't exactly the previous value #2870
base: main
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2870 +/- ##
==========================================
- Coverage 96.22% 96.15% -0.07%
==========================================
Files 37 37
Lines 1244 1248 +4
Branches 392 393 +1
==========================================
+ Hits 1197 1200 +3
- Misses 47 48 +1
|
What if for example I have this situation:
Won't this change make the grid use 80% of its actual width? |
I think in these cases there should be more resize events emitted than just the two? I tried some resizing options and it always worked for me. Do you think it would make more sense to keep a longer frame in the array? I think it is important to detect the looping pattern and break it if it occurs. |
What if we also keep in a variable the last date of the change so that we allow resize if it happened N seconds ago. The twitching I am seeing happens with a frequency <1s, so if we allow all resizes above that time, it should work. |
I made an experiment with toggling the width between 50% and 100% and it seems like it still works. I am still confident the resizer detects more than just one event in case of resize. Code:
PS. This using our fork with the commit in this PR - https://www.npmjs.com/package/react-data-grid-planyard |
Could you check if this fixes it on your end? -setGridWidth(clientWidth - (devicePixelRatio % 1 === 0 ? 0 : 1));
+setGridWidth(clientWidth - (devicePixelRatio === 1 ? 0 : 1)); or -setGridWidth(clientWidth - (devicePixelRatio % 1 === 0 ? 0 : 1));
+setGridWidth(clientWidth - (devicePixelRatio === 1 ? 0 : 2)); |
I could potentially also think of add an additional condition:
SOME_FIXED_SCROLLBAR_SIZE can be for example something like 20-50px. This means these larger resizes should also work and the small twitching resizes would be excluded. |
I don't think so. When I log out the variables in the hook, I get the following size changes - the clientWidth drastically changes and it isn't just a single pixel change.
|
Please do try my suggestion.
This is because a single pixel change will toggle the display of the scrollbar. |
This seems to resolve my issue on a devicePixelRatio=2 screen, but I can't reproduce it anyway on a devicePixelRatio=1 screen at the moment tbh. |
Let's go ahead with this fix instead then. |
@ekeuus Do you want to update this PR to use |
We now released our version to our users, but I can test your solution tomorrow and let you know what I find out. |
625fad5 |
🆕 Add isMouseClick flag to editable cell to know why the editor i…
ERROR in ./website/root.tsx Module build failed (from ./node_modules/@linaria/webpack5-loader/lib/index.js): Error: Cannot find module '@babel/plugin-proposal-nullish-coalescing-operator' Require stack: ......... - Did you mean "@babel/plugin-transform-nullish-coalescing-operator"? Make sure that all the Babel plugins and presets you are using are defined as dependencies or devDependencies in your package.json file. It's possible that the missing plugin is loaded by a preset you are using that forgot to add the plugin to its dependencies: you can workaround this problem by explicitly adding the missing package to your top-level package.json.
BUG: fix scroll to column
We are having issues with the width sidebar jumping back and forth in some specific cases. The useGridDimensions keeps re-rendering and updating the width in a loop. This PR makes sure that the previous value is also kept in the state so that if there is a state pattern like this:
Then it just doesn't set the width of 100 in step 3 again, preventing the infinite rendering loop. If you resize your screen as a user or snap it via the OS, the table resizing still works fine since there are more events being triggered in that case, compared to the sidebar appearing and disappearing.
WITH TWITCHING BEFORE THIS FIX:
https://user-images.githubusercontent.com/10929022/161064356-d2053799-beac-41fb-a8a2-17b1ba855806.mp4
WITHOUT TWITCHING AFTER THIS FIX:
https://user-images.githubusercontent.com/10929022/161064370-ad11a323-3850-44b9-82dc-b93998acd342.mp4