react-native-windows
react-native-windows copied to clipboard
microsoft
Share timer implementation
We have two implementations of the TimingModule in the repo. One that we use in Office and one used in XAML apps. With this change we will move to the implementation that does not depend on XAML functions, which also makes it easier for people hooking RNW to run against a different UI platforms, to no longer need to provide a custom Timer module.
Since its likely that replacing the TimingModule could have weird affects on apps, I've provided a quirk setting to revert back to the old implementation until we get confirmation that the new one doesn't cause undue regressions.
Microsoft Reviewers: Open in CodeFlow
Since its likely that replacing the TimingModule could have weird affects on apps, I've provided a quirk setting to revert back to the old implementation until we get confirmation that the new one doesn't cause undue regressions.
I think we would want the quirk to work the other way by default, if it's not set, we should default to what already works for UWP apps, until we have confirmation it doesn't break anything
I dont think we'll get much in app test coverage with it off by default. Most apps are not going to go through and do the extra work to enable it.
IIRC the Office timer doesn't have correct semantics to support requestAnimationFrame() as polyfilled by react-native. https://github.com/facebook/react-native/blob/1af2beaaa34ac01f04b14035acdfe0a5ecb329d8/Libraries/Core/Timers/JSTimers.js#L259
See https://github.com/microsoft/react-native-windows/issues/6032 and Eric's fix for some more context.
+1 @NickGerleman. I'm all for ridding the implementation of DispatcherTimer, but all other platforms fire RAF callbacks on frame boundaries, so I'd be concerned that this would break JS -driven Animated xplat consistency. Given the bugs in NativeAnimated, we should ensure those work properly.
