Receive state

[rowrowrowrow]

I think sticking to the previous -> next state convention makes reconciling the incoming easy to use.

[rowrowrowrow]

#108

[rowrowrowrow]

@aohua Hoping you can provide some feedback.

[rowrowrowrow]

@aohua Anything I can do to help get this change included? If we want to avoid breaking changes for people with the current order of arguments for example.

[aohua]

Hi @rowrowrowrow Thanks for your PR, but I think the init function is only supposed to be triggered once, storing the initial state may not be very useful in most of the use cases. I'm currently converting the entire project to TS and trying to improve the init process, I will consider this if there is a valid use case for it, and this is a breaking change I might include it together with other major updates.

[rowrowrowrow]

Hey @aohua, thanks for taking the time to consider the PR.

I think that adding a receiveState function is necessary as the prepareState function is currently used both for sending AND receiving state. The issue is when you receive state you may have existing state that shouldn't be overwritten by the incoming state for whatever reason. So without a receiveState function, which receives both the existing and incoming states as arguments, I don't think there is a way to reconcile the two.

e.g. this should also resolve #108

[rowrowrowrow]

I rebased the commit on master.

[rowrowrowrow]

@aohua Is there anything I can do to help with this?

[rowrowrowrow]

@aohua bump! Thanks

[aohua]

Thanks @rowrowrowrow merged and released with version 3.1.4

[aohua]

@rowrowrowrow Could you help to update the Readme file as well? Thanks