Closed aradomski closed 1 year ago
You are right, this architectural pattern does come with a lot of boilerplate code and lack of documentation makes it a bit more difficult to understand. I chose this pattern because it was more challenging than plain MVVM. It helped me to learn many new things.
If you like this pattern and chose to implement it in a production app, you can do many optimisations to improve performance and save time.
To begin with, if your State
and RenderState
are largely the same, you can choose to eliminate RenderState
from the equation and observe State
in the UI. As you can see in BaseViewModel
code, RenderState
is an optional parameter.
In addition to that, eliminating RenderState
will also eliminate the need of StateMapper
, which is also an optional parameter in BaseViewModel
.
If you pull the latest commit, you will see that I have merged many pairs of Action
and its corresponding SideEffects
. Implementing multiple interfaces on a single data class helped to reduce the number of class in the store.
I agree that there are more ways to reduce the boilerplate code and I will have some thought on doing so.
However, if you’re working on a production application, I will suggest you to keep the architecture simple. The reason why MVVM is so popular is its simplicity and adaptability.
Regarding the database doubt, it is difficult to suggest a solution without knowing the use and source of the ID. I will share some ideas on local database.
Realm returns the latest version of data in the write transaction.
a) If you want to use the ID in the UI, you can use this transaction to create a flow and return that flow to the processor. Processor
will wrap the flow inside an Action
and return it to the Updater
. Updater
will forward the flow to the State
, which you can observe in the UI.
b) If you want to launch another SideEffect
with the ID, a network call for example, You can return the ID from repository to Processor
. Processor
will wrap the ID in an Action
and return it to the Updater
. Now updater will launch the SideEffect
for network call.
Thanks for reply!
It looks like I was a bit too much attached to the entity where most of the field were not nullable and that caused problems while filling the form. Now I'm sending the object as seperate values once form is submited, and then I'm returning whole object (with id given by DB).
Also I was a bit confused by the idea of State
and RenderState
but I got it now.
Thanks for inspiration!
Hi! First of all I want to thanks for this project I find it very usefull to learn KMM.
I'm doing a project that includes form witch should be validated. At this point I think it is very laborious to event add single field to the form. For that I need to add two fileds to both
*RenderState
and*State
data classes - one for field value, second for error message. Then update*SateMapper
, add new data class for this field as implementation of*Action
and then handle it inonNewAction
function in*Updater
where new field value is validated and then properly handled. It works, but it is also very laborious to do. Do you have any idea how to implement it in a smart way?Another problem that I'm facing is how to handle data that is not know at the moment? For example database ID, which will be known only after form saves its conent into DB.