add allowStateChangesInsideComputed to allow changes inside a computed value

[xaviergonz]

in order to fix MST mobxjs/mobx-state-tree#967

[coveralls]

Coverage increased (+0.02%) to 93.957% when pulling 1c55f6e on allow-state-changes-inside-computed into c86ba97 on master.

[xaviergonz]

I changed the implementation so it only allows it for the current computed level, this is

computed -> changes state inside allowStateChangeInsideAction - ok
computed -> changes state inside allowStateChangeInsideAction -> computed -> changes state without allowStateChangeInsideAction - error

That way it is a bit better contained.

[mweststrate]

@xaviergonz I just pushed an alternative solution, not sure whether I do like it better (I do like it better from api perspective, but not sure I like it better from the constraint that is being given up)

[xaviergonz]

@mweststrate Thanks for taking a look!
TBH I'd rather not give up on the checks (that are useful for all users) altogether just for this feature (that's an internal one most probably only to be used by MST) TBH

[xaviergonz]

@mweststrate should it go back to the original solution (the one that doesn't give up the constraint) in order to fix mobx-state-tree afterCreate?

[mweststrate]

Sorry, yeah that is anyway better than the current one. Still don't really like it, nasty side effects of laziness... 😋. Op ma 24 sep. 2018 19:14 schreef Javier Gonzalez <notifications@github.com>:

…

@mweststrate <https://github.com/mweststrate> should it go back to the original solution (the one that doesn't give up the constraint) in order to fix mobx-state-tree afterCreate? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1706 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhF4pdNNNar3ivy2hvM6ADD5U711dks5ueRMRgaJpZM4WUT6r> .

[xaviergonz]

Well, it is only to fix that very particular use case :) Don't think people will (or even should) use it too much.
Reverted

[xaviergonz]

Improved the unit test to show that:
computed -> afterCreate (change) will be ok
computed -> afterCreate (change) -> computed (other change) will throw

[xaviergonz]

@mweststrate I was wondering, does this need to be retrofit to mobx 4 master as well?

[mweststrate]

@xaviergonz yes, but no worries, already on it :)

[xaviergonz]

ah thanks!

[mattruby]

Thanks for keeping on this one!

[mweststrate]

Hope to cut a release tomorrow Op di 25 sep. 2018 om 17:21 schreef Matt Ruby <notifications@github.com>:

…

Thanks for keeping on this one! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1706 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhI_zrKAa_rb2DXqSBYq7KJbiKjwNks5uekn3gaJpZM4WUT6r> .