Store coordination (Conversation rules)

[diklimchuk]

What is it?

This merge request enables a new approach for defining communication between stores

Why is this needed?

The current implementation has some disadvantages:

• Limits communication possibilities
  Only event to event and effect to effect mappings
• Has strict contract
  Events are mapped without state and effects may access parent state
• Defines strict parent - child relationship
  Instead of making stores as indepent as possible
• Allows to access internal implementation details
  Events by nature contain a private store information. Internal events are named this way obviously to represent internal events
• There's no way to trigger an event in the parent from the child store
  There are other possibilities to workaround this, but it seems like the right time to make this change.
  The case which lead to this change:
  • Parent store along with parent fragment are immutable and kept in the common module
  • Child stores are plugins to the parent store and fragment
  • Child stores need to trigger some event in parent

Why is the new approach better?

It has some advantages:

• Allow to contruct any communication mechanism
  It has an api for defining communication contract
• Communication contract may access only public api defined in the Store interface
  Instead of accessing implementation details

Is this api backwards-compatible?

No, the old api is kept to allow postponing migration

How to migrate to the new api?

There's no way to migrate easily to the new api, because there's no way to map events to events and effects to effects

How to migrate?

Effect to effect

Consume child effects in the parent and send effects directly OR consume effects in the fragment (Api for using multiple stores in the fragment is planned in some distant future)

Event to event

Replace consumable child events with effects

The main questions

• Do you agree that this is an appropriate change?
• Will you be able to handle migration?
• Do you need more apis for easier migration?
• Are there any structural incompetibilities which can't be implemented with new apis?

[diklimchuk]

@sergei-lapin, @opengamer29, this is a major api change. Please, take look at this carefuly. I want to add this functionality in some way, since we heavily use child stores in Haier.

[sergei-lapin]

Great feature!

[sergei-lapin]

Since one of the issues addressed is an attempt to make "parent" and "child" more independent then maybe it's better to move away from this concepts in naming as well?
Smth like parent -> first, child -> second (FirstEvent, SecondEvent etc.) seems a bit more appropriate here and in other files

[diklimchuk]

I don't mind, let's see what @opengamer29 has to say

[opengamer29]

Yes First/Second make more sense for me.

[opengamer29]

Just an idea. Can it be helpful to save refs to contracts, that store involved to, inside stores to revoke contracts easily when a store is stopped?

[diklimchuk]

Contracts already have no effect when either of the stores stops and you suggest store code complication. No.

[opengamer29]

I'm pretty sure that @sergei-lapin told me about possible improvements in parent\child communications 2-3 weeks ago. And tadam... Did you discuss it before?

Also, it will be great to have it inside samples.

[diklimchuk]

I'm pretty sure that @sergei-lapin told me about possible improvements in parent\child communications 2-3 weeks ago. And tadam... Did you discuss it before?

Also, it will be great to have it inside samples.

Did you discuss it before

No, if I remember correctly.

Also, it will be great to have it inside samples.

Javadoc and test cases already have api examples.

[diklimchuk]

@sergei-lapin and @opengamer29

This is not something i would normally write but past months while writing a solution for this mr seemed too mysterious to me. This library is truly magical and I had a chance to withess this myself. I also had a bunch of strange coincidences. This is not a place to discuss such things, but one thing I will say. Last week's friday I oficially became an android teamlead at Haier. Yay.

I wonder, whether the only option for me was to become a teamlead since this was the only way to solve the inherent error introduced into the library at the date of creation by my own inability to see that it is brutally limiting or one-sided. I hope this explains how it turned out like that. I don't mention stores in futher text but always imply them. The old child-parent communication mechanism was built on the idea of complete child self-sufficiency. Without any ability for children to request anything from parents and them willingly delivering all possible information internally provided by free access to parent's internal events with the only purpuse - providing children with required independence. One the other side, parent had no knowledge of child's work and wasn't allowed to affect their behavior in any way, neither by sending events nor by sending state updates.

I've added a solution for the problems both of you desribed. Take a look and tell me if something could be improved. Another update. Now there are a lot more of api illustrations. I've expanded test cases with stories. Some of them are joyful. Some of them are nightmares. I'll add them with a separate mr to work a little bit longer on the details. Don't look if you don't want to know. Now there's the only one - look at the javadoc.

I've refined the original solution. Store contracts are replaced with store coordination. I like this new naming a lot more, because of the ability to unite more cases. Coordination not only implies equality, even means so. A better name for this is "Conversation Rules".

I hope new coordination mechanics will provide enough space for two-sided communications. Either way, the good old child-parent mechanic is still present. You both know where to look. If in any case you need me or there are some problems with the library functions, telegram and issues are always open For you. Choose your path. Wisely.

I will keep fixing bugs and hope add a lot more new features.
At least while one of you doesn't know who Elmslie is, the doors of this magic library will remain open.
Sometimes the only real way out is to walk all the way in.
See you on the other side. Salut. ✋