vivid-money / elmslie Goto Github PK

All plugin versions older than v3.2.0 will stop working since Nov 30, 2022

More info here: https://blog.dipien.com/releases-hub-gradle-plugin-v4-0-0-32cfca1d0de1

@opengamer29 provide details

subj in title

maybe #207 will solve this issue too

Including migration

Since v1.2.0 store implicitly starts right after the first incoming event. If it's not an Init event for some reason, then later Init event will be ignored.

Add a way to subscribe to all store events. It may be some kind of listener or flow of store events (preferred)

Need add a kotlin-publishing.gradle config in elmslie-test and elmslie-test-rxjava3 gradle files

Update Gradle scripts to industry standards

Preconditions:
There are two ElmFragments which are only container for Composable functions. Subscribe to Flow(Effect) with effects extension inside Composable fun.

Steps to reproduce:

1. Open Fragment1 and navigate to Fragment2. Fragment1 subscribes via Actor to some data-holder.
2. Trigger an event in Fragment2 which perform some work and update the data-holder from previous step.
3. Reducer1 received event from Actor and produce effect, while Fragment1 is paused.
4. Fragment2 is closed and Fragment1 didn't get effect.

IMPORTANT NOTE
It's related only for Flow. Due to research, I found that ElmScreen always subscribes to effects when Fragment is resumed. Since we manually subscribes to effects, this behavior broke the logic.
CoroutineScope inside Composable starts later than Fragment is get resume state, so ElmScreen consume effects but it shouldn't.

If one day we'd switch to maven central instead of jitpack (🤞🏻 ) — we won't be able to prove owning money.vivid domain (which maven central will require to prove with current artifact coordinates of vivid.money.elmslie) — we need to change that to money.vivid.elmslie

More info inside this discussion

subj in title

Maybe we can make State to inherence from class ComposableState with field UiEffects. And allow storing Composable side-effects inside this new field. In this case inside reducer, we will have our usual handle effects field for system effects, and this UIEffect field of State for Composable Ui Effects

The main problem with this approach is duplicating Effects after process death. Effect will be saved in state and dispatched you ui the second time after store recreation since there's no mechanism to remove it from state after it was displayed

We discussed that it will be nice to have some kind of callback, that calls before the store is destroyed and allow the lib user to save part of the state to SavedStateHandle.

Return ElmStore from addChildStore inside ElmStore in order to support chaining addChildStore callse