With version 2.0 for every resource we would access (via Reactor's fetch), it would be "loaded from" and "saved to" to the same place. This was due to how InDiskPersistence was created (with a persistencePath). Having a resource as input for the fetch, is wrong as well, because it implies that there is a different behaviour, depending on the resource, in terms of persistence. The correct way, would be to fix the resource when the Reactor is created.
Example
A ViewModel that accesses different sections: Sports, Fashion and World news. With 2.0 we would need a reactor for each section. With this new approach, we only need one instance.
Changes
From a code perspective:
The InDiskPersistenceHandler, doesn't have any property now. It could actually be converted to free functions.
The ReactorFlow is no longer responsible for deciding if persistence should be used or not.
The Reactor methods, now have the responsibility to decide if it should be persisted and if so, what input they should receive.
Intro
With version 2.0 for every resource we would access (via
Reactor'sfetch), it would be "loaded from" and "saved to" to the same place. This was due to howInDiskPersistencewas created (with apersistencePath). Having aresourceas input for thefetch, is wrong as well, because it implies that there is a different behaviour, depending on the resource, in terms of persistence. The correct way, would be to fix theresourcewhen theReactoris created.Example
A ViewModel that accesses different sections: Sports, Fashion and World news. With 2.0 we would need a reactor for each section. With this new approach, we only need one instance.
Changes
From a code perspective:
InDiskPersistenceHandler, doesn't have any property now. It could actually be converted to free functions.ReactorFlowis no longer responsible for deciding if persistence should be used or not.Reactormethods, now have the responsibility to decide if it should be persisted and if so, what input they should receive.