Add nullability annotation for kotlin interop.

[jaychang0917]

Currently the oldState will be interpreted as nullable in Kotlin like:

class TestAction: Action<String> {
  override fun newState(oldState: String?): String {
     // ...
  }
}

This PR adds nullability annotation for better nullability interpretion in Kotlin.

[codecov-io]

Codecov Report

Merging #45 into master will not change coverage. The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #45   +/-   ##
=======================================
  Coverage   94.59%   94.59%           
=======================================
  Files           5        5           
  Lines          74       74           
  Branches        5        5           
=======================================
  Hits           70       70           
  Misses          3        3           
  Partials        1        1

Impacted Files	Coverage Δ
...rox-core/src/main/java/com/groupon/grox/Store.java	100% <100%> (ø)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 330a0ad...72d6c94. Read the comment docs.

[chenthorne]

Is this actually true though? In Java land, why couldn't you have a null state?

If we want to enforce a non-null state need to update annotations for the appropriate Store classes too.

[jaychang0917]

In UI world, null state doesn’t make sense.

On Tue, 18 Dec 2018 at 9:39 AM, Cody Henthorne [email protected] wrote:

Is this actually true though? In Java land, why couldn't you have a null state?

If we want to enforce a non-null state need to update annotations for the appropriate Store classes too.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/groupon/grox/pull/45#issuecomment-448064467, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGYzyBZdY1_V2Guq0sqdXck4jIweTMGks5u6EdbgaJpZM4ZUvAa .

[chenthorne]

Don't get me wrong, I'm for the change as I have the same problem in kotlin too but I could understand that a null-state could be a thing.

Grox isn't UI specific just helpful for it, it's just state management.

[chenthorne]

If you're up for more annotations, I'd support adding them to the Rx classes as well :)

[stephanenicolas]

It looks like we're all on the same page.

I agree with you Cody, it could have made sense to have a null state. But I see that it's more a technical constraint to remove this possibility. Anyway, it looks like with Kotlin being introduced, we're just starting to wonder all the time why we would support something null.. :)

Le mer. 19 déc. 2018 à 03:08, Cody Henthorne [email protected] a écrit :

If you're up for more annotations, I'd support adding them to the Rx classes as well :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/groupon/grox/pull/45#issuecomment-448443416, or mute the thread https://github.com/notifications/unsubscribe-auth/ABv33Z8rrkhTzlfSKvc-ArwiIAqpRyfCks5u6Z-ngaJpZM4ZUvAa .

[alin-turcu]

Looks good on my side also. I don't think a null state would make much sense. I would rather have a "empty state" than a null one.