setState sanity checking

[AmaranthineCodices]

This fixes #17. It throws an error when setState is called in the following locations:

• the init function of a component
• the render function of a component
• any point after the component begins unmounting, including within willUnmount

The error message:

State cannot be set at this point: are you setting state from an init, render, or willUnmount function?

Tests are included, yay!

This will probably have a merge conflict with #21; I'll fix it when it happens. This required an edit to Reconciler to set the flag to false just before unmounting the component.

[coveralls]

Coverage increased (+0.2%) to 85.928% when pulling 4683cb5 on AmaranthineCodices:setState-sanity-check into f0a9981 on Roblox:master.

[LPGhatguy]

I think we can break this one into two tests, just like how willUnmount is a separate test

[LPGhatguy]

Ah, there are spaces for indentation here!

[LPGhatguy]

It might be a little clearer to say are you calling setState from instead of are you setting state from, since you can you set state from init as long as you don't call setState itself!

[LPGhatguy]

Thanks!

[LPGhatguy]

Oops, I should've asked you to add an entry to the changelog!

I'll go ahead and do that for both of these PRs.

[LPGhatguy]

I know we've already merged this, but are there any other places where it might be inappropriate to call setState?

I reviewed some code today where setState was being called from willUpdate, which seems like a mistake (rendering shouldn't be re-entrant!)

[AmaranthineCodices]

One place that immediately comes to mind is shouldUpdate. There is absolutely no reason to call setState from there.

wilUpdate and didUpdate are almost certainly bugs. I can think of some contrived situations where calling them wouldn't cause re-entrancy issues, but they're contrived and they're probably not worth allowing.