-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
prepostredraw #806
Comments
Conversation that spawned this: https://groups.google.com/d/msgid/dc-js-user-group/744A7AF6-ED55-4821-B028-413F6D932D1E%40woodhull.com?utm_medium=email&utm_source=footer But this has come up a million times before, it is the top gripe about renderlets. |
+1 to having a postRedrawBeforeTransitionStart and keeping the current as postRedrawAfterTransitionsEnd for backwards compat. |
+1 On December 31, 2014 11:48:10 AM CST, Jasmine Hegman [email protected] wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
#833 should help move this along - renderlet is just like any event now. |
How about "pretransition"? |
+1 for "pretransition", very succinct! |
Releasing this in 2.0.0 beta 11 since it shouldn't interfere with any existing functionality. Please try it out! P.S. To add a transition on any added elements that runs along with the transitions on built-in elements, add it like this:
|
Most of the time when people resort to a renderlet, they want something that fires immediately, not after the transitions. But the post* events and the renderlets deliberately fire after all transitions
dc.js/src/base-mixin.js
Line 475 in a701c49
Without breaking any existing code, we could maybe add more events that really trigger directly after render/redraw, with no delay, and then ppl could modify the DOM before anything hits the screen, even if they have transitions enabled.
The text was updated successfully, but these errors were encountered: