brianegan / bansa Goto Github PK

Hi! Interesting implementation, but how can I use it with ScalaJS?

Follow the advice in the readme and update the docs to include a more step-by-step guide

You've forgotten to add maven { url "https://jitpack.io" } to "How to install".

Is this up on Maven? I can't seem to find it. I'm guessing I have to download and link to the project manually for now?

Redux has some really cool dev tools! It would be great to provide a dev tool experience similar to this one: https://github.com/gaearon/redux-devtools

I'm working on fairly complexe application, and I'm splitting my AppState into multiple substate, so I have multiple reducers and states. It works fine, but is there a way to subscribe to change only happening to a specific part of my state?

To get you an idea here is my AppState

class AppState {
    var userState = UserState()
}

and my UserState

class UserState {
    var currentUser: String? = null
    var users = mutableMapOf<String, User>()
}

and my AppReducer

class AppReducer: Reducer<AppState> {
    val userReducer = UserReducer()

    override fun reduce(state: AppState, action: Action?): AppState {
        userReducer.reduce(state.userState, action)
        return state
    }
}

So when I subscribe, I would want to do something like this:

store.subscribe { state.userState ->
  Log.d("State change", state.userState.currentUser)
}

is that something possible or planned?

Thanks!

Hi,

I am currently learning to implement a small Android app with this library, but I am unsure where you would put the Store. Should there really be an application wide store Singleton and how would I handle orientation changes or the Android system killing the process and saving/restoring the state? Or is it better to put the store inside the ViewModel of the Android Architecture Components?

Thanks for your input!

Spek was experimental, but I don't find it's as powerful or useful as reliable ol' jUnit. Let's remove it in favor of jUnit tests for all examples.

Thank you for creating this useful library !

bansaDevToolsUi contains a res folder with an layout file
for the resource merger to work shouldn't this library be an aar bundle instead of an jar bundle ?

Hi,

I just wanted to try your Bansa counter example (by the way, I have to chuckle every time I misread this as "Bansa counterexample") and it crashed with the following exception:

java.lang.RuntimeException: Unable to instantiate application com.brianegan.bansa.counter.Application: uy.kohesive.injekt.api.InjektionException: No registered instance or factory for type com.brianegan.bansa.Store<com.brianegan.bansa.counter.ApplicationState, com.brianegan.bansa.Action>
    at android.app.LoadedApk.makeApplication(LoadedApk.java:526)
    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4390)
    at android.app.ActivityThread.access$1500(ActivityThread.java:139)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1260)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loop(Looper.java:136)
    at android.app.ActivityThread.main(ActivityThread.java:5105)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:515)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:792)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:608)
    at dalvik.system.NativeStart.main(Native Method)
Caused by: uy.kohesive.injekt.api.InjektionException: No registered instance or factory for type com.brianegan.bansa.Store<com.brianegan.bansa.counter.ApplicationState, com.brianegan.bansa.Action>
    at uy.kohesive.injekt.registry.default.DefaultRegistrar.getInstance(DefaultRegistrar.kt:99)
    at uy.kohesive.injekt.api.InjektScope.getInstance(Scope.kt)
    at com.brianegan.bansa.counter.Application.<init>(Application.kt:30)
    at java.lang.Class.newInstanceImpl(Native Method)
    at java.lang.Class.newInstance(Class.java:1208)
    at android.app.Instrumentation.newApplication(Instrumentation.java:990)
    at android.app.Instrumentation.newApplication(Instrumentation.java:975)
    at android.app.LoadedApk.makeApplication(LoadedApk.java:521)
    ... 11 more

I haven't done much Kotlin and haven't used Injekt at all - could you tell me what I am doing wrong?

Hi Brian,

I keep running into situations where my first impulse would be to dispatch a new Action to my store from within my Reducer. But since I don't even have a reference to the store there and since dispatching from the reducer is very much discouraged in Redux I suppose that's not the way to go in Bansa either. Still I can't figure out what to do instead.

For example: I try to load a list of images from my API but the request fails because I am not logged in and so the login form is displayed instead. The login request succeeds and LOGIN_SUCCESS is dispatched. Since I have also stored (something like) retryImageListRequest = true in my state I could now dispatch another LOAD_IMAGE_LIST and load the images in the appropriate Middleware. Except that would mean I would dispatch an Action from within my Reducer.

Unfortunately, I am not only new to Bansa but to similar frameworks as well (I've only done some Elm, and that was only with synchronous computations), so I can't make much sense of articles like this one:

Now you know that this is frowned on. You know that if you have enough information to dispatch an action after the reducer does its thing, then it is a mathematical certainty that you can do what you want without dispatching another action.

I would be very grateful for any suggestions!

This is awesome. Wondering if this is still maintained? It would be a shame if not. There's no other redux implementation in java as good as this.

Hello, thank you for introducing Redux to Android world.

I'm using bansa with Anvil and I think they are a very good match. But I noticed one thing, if we call BaseStore.dispatch() from multiple thread, it's possible to get inconsistent state within one dispatch cycle, since we can't pass the new state to Anvil.render(). We could only use BaseStore.getState() in each view.

I noticed that you use locks in this line and getState(). But they both lock on different objects. synchronized(this) locks on Middleware instance while public synchronized S getState() locks on BaseStore instance.

But I think although we use locks, there is still a chance for inconsistent state since dispatch and getState will not be called in one block.

Do you think we should only call dispatch in one thread? Maybe using a single background thread to do it?

I'll be grateful to hear your thoughts about this. Thank you very much.

Goals:

• Pass data down from one component to the next (Unidirectional data flow, ala React)
• Components have access to the activity lifecycle (ActivityLightCycle from LightCycle as a possible interface)
• Components have the concept of a render type of function. view Might make more sense as it means we could use the Anvil renderable interface.
• Usable with / in? Adapters
• Render function that takes in a Props model
• Local ViewModel state that is updated by render, which combines local state and passed in props
• "Mount" component

Thank you so much for your work on this. It is really nice library. I am a big fan of Redux.

1. Can you share why you decide to move implementation away from Kotlin -> Java?
2. Do you have any support for StoreEnhancer ?