Race condition when data changes after routing. about iron-router

[cmather]

Thanks Tom. It would be helpful to see the route or controller definition to see where the reactivity is being set up. This situation should be accounted for when you run the new route it should invalidate the previous computation which would prevent the previous route from rendering again. Even if the data comes off the wire in the middle of the next route run, the invalidation wouldn't fire until the new route has completely run since its all synchronous. And at that point the previous computation will have been torn down. But you may have discovered a case I didn't test for. I have basically the same code above in evmind though and seems to work fine. I can trace in the debugger sometime today to make sure.

[tmeasday]

Hey Chris. Still up!

Let me make a repro before you think about it. I'll get into it tomorrow.

El 03/08/2013, a las 12:38 AM, Chris Mather [email protected] escribió:

Thanks Tom. It would be helpful to see the route or controller definition to see where the reactivity is being set up. This situation should be accounted for when you run the new route it should invalidate the previous computation which would prevent the previous route from rendering again. Even if the data comes off the wire in the middle of the next route run, the invalidation wouldn't fire until the new route has completely run since its all synchronous. And at that point the previous computation will have been torn down. But you may have discovered a case I didn't test for. I have basically the same code above in evmind though and seems to work fine. I can trace in the debugger sometime today to make sure.

—
Reply to this email directly or view it on GitHub.

[cmather]

Thanks @tmeasday. I just wrapped up for the day. Finally got EventedMind deployed! Plan is to take a little breather and then get to the router again this weekend. I'll look at this issue too, but interested if you discover any other symptoms around it.

[tmeasday]

Ok, created a reproduction, pretty simple and standard use case:

https://github.com/tmeasday/route-data-bug

To reproduce:

1. Start meteor server
2. In console, do Posts.insert({});
3. Click on the word 'one'.
4. You should be at /two but still see the one template.

I would expect at 4. to see the two template rendered.

I also tried to make a failing bug that suffered the same issue (https://github.com/tmeasday/meteor-iron-router/compare/EventedMind:add-templateName-to-partial...async-data-bug) but I couldn't figure out how to make it happen. I guess it's a question of exactly when the data callback is re-run due to the server returning data.

Will investigate more tomorrow and see if I can find out more.

[cmather]

Thanks Tom. Will investigate this morning.

[cmather]

I was able to reproduce this. It appears something unexpected is happening in the onRun method of ClientRouter. Will resume debugging tonight.

[cmather]

@tmeasday, that was a bit of a tricky one. Nice find. Also discovered another minor bug while I was in there that I fixed. See my commit message for a full explanation.

[tmeasday]

In this fix did you move the rendering of the new route into a separate Deps flush?

Because I'm seeing the transitioner's computation invalidate twice on routing -- firstly as the context (i.e. URL) changes and then secondly as the partial changes. Here's my workaround for now, but I think maybe this tight couple indicates I should follow an approach more like what you outlined tmeasday/iron-transitioner@b7de1aa