Same component transition

[khrizt]

Hi, I was looking for a library that supported transitions for react router and when I saw yours I thought it was great. And it works on a small react native project I have.

But now I'm trying to add this library to my company app and I've found that the Component that appears / disappears is the same one that the one appearing / dissapearing. In this project, that has a fairly large codebase, we use 2 switch levels to group common routes and do common actions on each case. But when I try to replace the first-level switch is when this behaviour appears.

Also when I try to replace the second-level switch with Stack, I lose the status bar and the bottom bar is placed at the top (this bottom bar is outside the second-level switch).

Do you know if this use case is possible with the library?

Thanks!

[Traviskn]

Hi @khrizt, I'm glad you've been able to use this in your projects! I'm not sure I quite understand the problem you're describing, is your use case to nest a Stack component in a Switch? Would you be able to create a small code sample that reproduces the issue you're seeing? I think that with the right styles and routes we should be able to support your use case.

[khrizt]

Hi,

I'm trying to create a sample project to reproduce this behaviour but so far it works OK, so I'm trying to find what I have to add to reproduce it, so I can discover if it's my own error or an extreme use case. Thanks for replying.

[khrizt]

Ok, sorry for the delay, the conclusion is, the last time I probably did something wrong because it works correctly now with both projects.

But the problem I have now in the big one is the performance. The lag when going from one component to the next is too big and makes the app almost unusable. But I don't if that's something that is created by my structure or coding or is a library problem.

The app uses "containers" to do all the fetching data (done in componentWillMount / componentDidMount) and components to render it, and containers and components communicate with render prop pattern. Do you think this structure could keep from a good performance of the library?

[Traviskn]

Hmm it's hard to tell without knowing what exactly is happening in the code. One possible strategy could be to comment out some of the data fetching calls and see if the performance changes. I would be surprised if an asynchronous data request was slowing down transitions though. I suspect that rendering and re-rendering lots of data could slow things down. I'd want to check and see if components are getting re-rendered unnecessarily, possibly look into using pure components or shouldComponentUpdate to try and prevent extra renders.