Exactly, checking all the boxes is the purpose of this project: making the redux pattern usable for real applications on Android. Yes I have used it for large apps. About performance: it is mainly an issue on how you design the redux state. With time I have learnt how to do it efficiently. Unfortunately I did not update yet the examples in the documentation. with what I have learnt.

Selectors are definitely very useful. The diffing logger is cool, but honestly after writing the code, I have not used very much, because a well designed redux state and reducer have a very predictable behavior and it is very easily testable, so you don't really need this capability, at least in my experience. But is nice to have.

Interesting. I'm just starting with redux and exploring it as an option on Android. It would make an excellent fit for MPP. I've got the core module into a MPP and working fine with all tests passing. I will probably keep as a fork for know as there are many changes with the directory/module structure. I'll post the repo here when it is up.

What do you think about time travel and state visualization? Would that really be helpful? It sounds great, but wonder how useful it would be really be

Nice! I will happy to contribute to your repo and put a link on it in reduks repo. About time travel and state visualization: for me the android studio debugger is good enough. There is a basic implementation in reduks in the module reduks-devtools if you want to take a look. Also if you are really interested in this subject I will suggest to take a look at https://github.com/kittinunf/remote-redux-devtools-android by @kittinunf. It should be still compatible with reduks

Oh nice! Biggest change needed for MPP is handling the sychronized block of code in the store. Sychronized is not supported on other platforms, so looking at alternatives. Perhaps use of coroutines & channels

I suppose the sychronization is there to ensure the order of processing actions? Is that a safe guard for async middleware dispatching actions from another thread? (or thunk or saga?) Seems like imposing a rule of dispatching should only be done from main thread is reasonable, but the async action creators are possible valiators. Perhaps coroutines can help by always having the dispatch action done from the same CoroutineContext. Still learning coroutines and how this would be implemented.

MPP fork is here: https://github.com/patjackson52/Reduks Simple sample app for iOS & Android. iOS setup is a bit tricky and may not work out of the box right now. Also a few updates to the core code. The single method interfaces can now be replaced with type aliases and I’ve started that migration.

nice! I will take a look in the next few next days. I can help with the synchronize block. It can be substituted with coroutine channels. I do it in other parts of the code. If you want I can submit a pull request. In any case the recommended version of the store if you work with multiple threads interacting with the store, is the async-store, not the simplestore. So I guess it is safe to simply leave out the sync block completely for now.

Hi!! @patjackson52 wanna chip in here that my project has been refactored to be agnostic to any Redux implementation flavors! what it is actually needed is the replaceReducer function

I think Reduks has a replaceReducer function so it should be compatible! 🙂

Hi @kittinunf. That is a great choice and looks like could be a helpful tool. I will take a look at it soon.

@yasyd Is there a reason for

nextDispatcher

in this fun in SimpleStore? Not used at all. https://github.com/beyondeye/Reduks/blob/4.x_kotlin_1_3/reduks/src/main/kotlin/com/beyondeye/reduks/SimpleStore.kt#L24-L43

Yes it is needed, what your are seeing is the code of the main dispatcher, that is the last of the chain of dispatchers. If you add a middleware, then you basically replace this dispatcher with a new one that execute the middleware and then call next one in the chain.

the way the middleware do it is invoking nextDispatcher

@yasyd noticed that the 4.x branch is gone now. Is that just not ready for the world?

Yeah, actually there was nothing there new. it was actually misleading to have it there It was a preparation for things to come. Sorry if this create problems to you (but it shouldn't) https://github.com/beyondeye/Reduks/tree/3.x_kotlin_1_3

the main branch with all development up to now is

just switch to the 3.x_kotlin_1_3 branch

@yasyd fyi, been using a fork of your lib in a multiplatfrom project and is working well. also any plans to update master? People how are interested may be turned away by the out of date master branch.

Great. I will be probably have some spare time next week. Perhaps I will manage to finally update master then

@yasyd what is the purpose of the ReduksContext and ReduksContext typed?

They are part of support for reduks modules, it is possible with reduks to define a state as a combination of multiple substates, Each substate is associated with a "tag" for identifying it between other substates. this tag is the ReduksContext. Each substate has its associated reducer function. So when an action is dispatched to the parent reduks store, the parent reducer use the reduks context for deciding to which substate reducer function to dispatch the action. Why this is useful? Lets say that you created some UI module, driven by a reduks state, lets say associated to a fragment. and want to reuse this UI module in another activity, or perhaps have multiple instances of the same UI module displayed. Reduks modules make it easy to do it. ReduksContextTyped is simular to ReduksContext, but contains also information on the type of the Action, so that the master reducer, when deciding to which substate reducer to send the action can potentially take into consideration the action type not only the module "tag". RedukcContextTyped is not currently in use, so it is possible that for the sake of simplicity I will remove it in the future

By the way I have finally started working on the new documentation

For an example of usage of ReduksContext you can look at tests, in here https://github.com/beyondeye/Reduks/tree/3.x_kotlin_1_3/reduks-core-modules/src/test/kotlin/com/beyondeye/reduks/modules

Reduks modules are also useful for the sake of performance in updating the reduks state and notifying subscribers of changes in the state. For very complex reduks state, updating substate, means creating a new substate and updating the reference to it in the main state. This is cheaper than creating a copy of the full main state. And also you can have subscribers to changes of only a single substate.

@yasyd I'm hoping to get some collaboration started around a standard redux library for kotlin which will support multiplatform. I have a first take of the core lib here and would be great to get your thoughts. I think your lib could likely use the types defined in it without many changes. So many different redux implementations, it would be great to get an ecosystem going similar to JS redux https://github.com/reduxkotlin

Good. I will take a look in the next days and I will give some feedback

@Patrick Jackson OK, so I took a look. First of all, about code quality in general, it looks very good. Now the negative points from my point of view. I will be very frank, please don't take it personally! It is not the first time that I was proposed to contribute to a standard redux implementation, so I have some experience with this. The main problem I see is that defining a standard seems to me much more difficult than simply grouping together useful modules from all the various redux implementation in Kotlin. What I am trying to say is that I am not sure I am going to change the code of my implementation to adhere to the interfaces and standard in redux-kotlin. But I am willing to help porting some reduks modules to work with it. Also I am against a reference implementation that is not used in real world application, but it is only built to be clean or to be as close as possible to the original reduxjs. Now about "pain points" with current redux implementations for kotlin: what is really missing, I think is what for redux.js is the link between redux.js and react.js, or in other words, integration between a library that handle changes to the state of the application and the actual rendering of the application state in the UI. What I am thinking about is integration with SwiftUI on iOS and Compose on Android

Cool, thanks for the feedback, it is welcome. I'll keep you in the loop as things evolve. I too am interested in how redux, or any state management in general, will work with Compose and SwiftUi. There will likely be some interesting patterns come and redux may play a role.