Prevent double-rendering on initialization

[supasate]

Based on #208, this PR adds isFirstRendering flag to indicate the first LOCATION_CHANGE action on initialization. So, the reducer can ignore it to prevent double-rendering. This should fix #193.

[supasate]

I just notice that this test by @AnnaTsu already passes before this fix. Actually, it should render twice before this fix. (It renders twice in the example app, but, not in the test suite.)

Anyone understands what's wrong in the test setup? cc. @jakewies @SergeyPoluektov

p.s. By the way, I'm going out for holidays without my laptop. I'll merge it first and release the fixed version. So, it can unblock other people while I'm away.

[jakewies]

Hey @supasate I see what you are saying here.

The expected behavior is that, prior to your fix, the "only renders one time when mounted" test should fail. Why? Because ConnectedRouter would render 2 times on mount due to the LOCATION_CHANGE action being dispatched, causing a store update.

I believe @AnnaTsu was struggling with this as well, and it led to a discussion about the merits of these tests and whether or not they are effective.

@SergeyPoluektov created a gist to show an example of how the tests don't take into account store updates by non-related actions (separate issue), and in that gist there is a test named "render once on initiation". It may be worth exploring the differences between the current test and the one in the gist to see what the differences are, and whether or not the test in the gist is better.

As of right now the test that exists in this project to check how many times ConnectedRouter renders on init is creating a false positive.

EDIT:

I can confirm that v6.1.0 has resolved the following issues that led me here:

• ConnectedRouter re-rendering on unrelated redux store updates
• ConnectedRouter double rendering on init

However this test doesn't seem to be providing much value to the project, as it was green even before this PR was merged into the project to prevent double rendering on init.

I will look into this further tonight when I have some time. Should I open an issue regarding this test since this conversation is being had in an already-merged PR @supasate ?

[supasate]

@jakewies Yes, feel free to open a new issue regarding this false positive test case.