Closed glung closed 8 years ago
This is some great looking code 😛, however I think the API and main implementation should definitely be in Java. This way Kotlin isn't a required dependency. Kotlin code ought to be in a separate module and should only contain extension functions to aide those using Kotlin.
A good example of the module separation I'm talking about can be seen here: https://github.com/JakeWharton/RxBinding
Here's my translation of the Kotlin APIs to Java https://gist.github.com/pardom/12548b1a4dab4723fb433a0eb629831e.
Because Redux has a functional approach using high order functions (enhancers) and simple lambdas, it is not that easy to make it work on a non functional language. (I learnt that the hard way).
This is for that reason, that I thought Java 8+ and Kotlin were the best candidates. I started with Kotlin because it is the language used by all stores I found (but redux-java) so it kind of meets the point of providing a single API.
But from a more structural perspective; your point makes a lot of sense, tho : better maintain only one API than duplicated APIs. Would that work for you if we were to have a java8 API with eventually a Kotlin extension lib ?
Can I get contributor access? 😄 I'm trying to push a branch to PR.
Would that work for you if we were to have a java8 API with eventually a Kotlin extension lib ?
Unfortunately, we can't use Java 8 on Android. I think we can do this easily on Java 6/7. The only place I'm using a "functional" function is for the dispatcher linking/chaining.
I already I need invited you. You should be a contributor already.
It is a bit late Berlin's time, so I'll check tomorrow in case it does not work.
Am 13.10.2016 00:05 schrieb "Michael Pardo" notifications@github.com:
Would that work for you if we were to have a java8 API with eventually a Kotlin extension lib ?
Unfortunately, we can't use Java 8 on Android. I think we can do this easily on Java 6/7. The only place I'm using a "functional" function is for the dispatcher linking/chaining.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jvm-redux/jvm-redux-api/pull/1#issuecomment-253353580, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhkcb5I_S_Py4pxOz36b8aQJ5Gmd7IXks5qzVmRgaJpZM4KVNPD .
closing in favor of #2
Scope
Verbatim port of the Redux API for Kotlin.
The API aims to meet the following criteria :
Redux-Kotlin's API by @pardom is really good to that regards (and many others). For that reason, it made no sense to me to redo it, that's why I forked it and change only a few things (I hope you won't mind Michael 🙏 ). The changes are highlighted in the comments.
Details
I was able to demonstrate this API is compatible with the following store implementations :
Here is an example of a middleware implemented on the top of this API : jvm-redux-devtools-instrument