Independent Transitions about react-move

[tannerlinsley]

My bad. I'll add it back in on both components

…

On Fri, May 26, 2017 at 1:22 PM Graham Mendick ***@***.***> wrote: Any reason you're not calling onRest in Transition component anymore? I was relying on it being called 😞 — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCTs0L8EV_r85gymSX0I3G7f1FDlJks5r9yZqgaJpZM4NaVYG> .

[tannerlinsley]

That seems more like react-motion's API and you are right, Items should act independently from one another. The changes would be or tremendous, but If you would like to sketch it out, I would be happy to work on it with you.

[tannerlinsley]

Technically speaking, I believe that an items progress should only reset when it's destination data changes via update. Does that sound right?

[grahammendick]

Yes, that sounds spot on! It would be nice if an item's duration and easing only reset on data changes. too.

[tannerlinsley]

Yeah. Basically if the items destination changes, reset and recalibrate everything pertaining to that item

…

On Sun, May 21, 2017 at 1:02 PM Graham Mendick ***@***.***> wrote: Yes, that sounds spot on! It would be nice if an item's duration and easing only reset on data changes. too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCQWj0uRQTiCSBGoHgIZnHDnYE6Qcks5r8IpQgaJpZM4NaVYG> .

[grahammendick]

Yep, that ticks all the boxes 👍

[tannerlinsley]

Okay. 👌 do you feel comfortable drafting those changes? I will be pretty straight forward until staggering. Even I get stuck there pretty easily.

…

On Sun, May 21, 2017 at 1:21 PM Graham Mendick ***@***.***> wrote: Yep, that ticks all the boxes 👍 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCTbGLHk4KpL33NldpMAtoFgUu4Vvks5r8I6igaJpZM4NaVYG> .

[grahammendick]

I’ve got my own navigation project that kinda takes up all my time - thanks for asking though. I’m in the process of swapping out React Motion for React Move in the React Native plugin.

[tannerlinsley]

Okay. I will get to it when I have some free time. Currently working a lot of react-table and react-charts.

[tannerlinsley]

Implemented in #16

[tannerlinsley]

This turned out to be a bit of a challenge, but I figured it out. Each item now maintains its own progress and invalidation. So now, if you interrupt a Transition with new updates, only items that need to change their destination will update, leaving any remaining items to finish their previous transition with their original timing.

[grahammendick]

Thanks but I think it’s only halfway there. It fixed the first of my codepen examples but it’s broken the second one. Have a look at the weird behaviour of the second example to see what I mean

[tannerlinsley]

I'll look into it

…

On Tue, May 23, 2017 at 12:31 PM Graham Mendick ***@***.***> wrote: Thanks but I think it’s only halfway there. It fixed the first of my codepen examples but it’s broken the second one. Have a look at the weird behaviour of the second example <https://codepen.io/anon/pen/dWexMp?editors=0010> to see what I mean — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCRME5AiQo2pj3v5Cvh8d2gcxyQL8ks5r8yYOgaJpZM4NaVYG> .

[tannerlinsley]

@grahammendick Its now fixed in 1.3.1 :) https://codepen.io/anon/pen/dWexMp?editors=0110

[grahammendick]

Great work! Don't you need to do the same for the easing?

[tannerlinsley]

…. yeah haha.

[tannerlinsley]

Fixed. Along with some cool enhancements. You'll probably want to look at the newly created props getDuration and getEasing ;)

[grahammendick]

Very classy! Thanks for doing such a great job.
I'll get back in touch when I release Navigation with React Move.

[tannerlinsley]

What is the primary difference between your Navigation component and React Router v4?

…

On Thu, May 25, 2017 at 12:05 PM Graham Mendick ***@***.***> wrote: Very classy! Thanks for doing such a great job. I'll get back in touch when I release Navigation with React Move. <http://grahammendick.github.io/navigation/index.html> — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCfDallrK0H9t7s_xJtxQ4Jr-YaE0ks5r9cLDgaJpZM4NaVYG> .

[grahammendick]

Navigation is the data-first router. You concentrate on what data you want to pass and don’t worry about your routes until the end. Take a look at this counter example. There’s no URLs in sight, right? Just typed data - the count is passed as a number, not a string.

Once your app’s up and running you can change the URLs to be whatever you want without changing any code. In the counter example, you can change the count parameter from the query string to the route without touching the component (just set the route on line 18 to route: '{count?}').

The Navigation router gets out of your way. It doesn’t get involved in rendering. It’s almost the exact opposite of the React Router. The React Router is really just a rendering pattern and it provides almost no help with data-passing.

[grahammendick]

Any reason you're not calling onRest in Transition component anymore? I was relying on it being called 😞

[tannerlinsley]

@grahammendick It's back now. Available for both Animate and Transition and finally documented :) Animate.onRest is simply a callback, but Transition.onRest will give you the item and its key that came to rest.

[grahammendick]

Hmmm....onRest in Transition component is incorrectly called all the time now. It used to be behind a wasAnimating check so that it was only called when it really came to rest.

I think each item should have a wasAnimating flag on it, much like each one now has a duration and easing?

[tannerlinsley]

Yeah

…

On Sat, May 27, 2017 at 2:10 AM Graham Mendick ***@***.***> wrote: Hmmm....onRest in Transition component is incorrectly called all the time now. It used to be behind a wasAnimating check so that it was only called when it really came to rest. I think each item should have a wasAnimating flag on it, much like each one now has a duration and easing? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCT5MX8O9yyRu23wqdvlle1qrydqOks5r99qHgaJpZM4NaVYG> .

[grahammendick]

Hey @tannerlinsley, just checking this onRest issue is still on your radar

[tannerlinsley]

Its released! Check the documentation.

…

On Sat, Jun 3, 2017 at 6:32 AM Graham Mendick ***@***.***> wrote: Hey @tannerlinsley <https://github.com/tannerlinsley>, just checking this onRest issue is still on your radar — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCUUzQeUjz1SmjKy6LQ4ONgni_D5pks5sAVJCgaJpZM4NaVYG> .

[grahammendick]

Sorry, been away for a while. I've added an onRest with a console.log to the second example. It should only log twice, but it logs v many times instead.