ww-tech / roxie Goto Github PK

Sometimes it makes sense not to log details of an Action or a State (for instance when they contain sensitive user info if we log in production). Enable easy overriding of toString() in those cases.

Could you extend sample with dagger implementation?

Hey there, I've been reading the wiki to figure out if this library is right for me. I like the idea of mapping actions into changes and having the UI respond to state changes but I feel like the use case might be a bit narrow.

Quite often a change occurs as a result of something other than user interaction, as an example let's say my app is polling a server for live sports results, normally these changes would come through the backend of the app and update a property in the ViewModel/Presenter which the UI is observing.

Is it possible (or even necessary) to represent external events as actions and treat them the same as user interaction, especially if they aren't coming from the UI layer?

As I understand, under the hood is used RXJava, are you planning to add the ability to use coroutines?

The image link as Data Flow with Roxie in home is broken. It seems to omit the raw=true.

Roxie is pretty lightweight, but I'm also lazy so having to create different files each time I start up a new screen sometimes becomes a bit of copy/paste work from other screens.

Not sure how to go about this (probably just some shell script), but most likely it would generate these initial files for us:

• Action
• Change
• State
• ViewModel
• ViewModelTest 👍 👍 👍

Possibly dagger related jazz too.

Hello,
jcenter is deprecated with the following message:

'jcenter' is deprecated
Builds will no longer be able to resolve artifacts from JCenter after February 1st, 2022
JCenter Maven repository is no longer receiving updates: newer library versions may be available elsewhere

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

It would be great to have Roxie on the Maven Central.

Roxie is built using RxJava2 and RxJava3 is in the works.

Things to think about:

• The operators that we currently use, are they still available? Do their behavior change?
  • If not available, what do we use instead?
  • If behavior change, does it break our implementation? What do we use instead?
• Should we provided an RxJava2 artifact? What Roxie is today.

https://github.com/ReactiveX/RxJava/releases/tag/v3.0.0-RC0

Hello,

Thanks for Roxie. We took inspiration from this library for coming up with our own architecture. The separation between Actions and Changes really makes the code clean.

I have a question about how you would go about reacting to external inputs? If I understand the concept correctly, Actions are always user-initiated. How about things like - say, internet connection lost/regained? How would these be modelled?

We are considering making the ViewModel or domain layers deal with such inputs and emit either an Action or a Change.

Making it an Action enables easy testing (since all you need is to create the ViewModel under test and dispatch the appropriate action). However, this Action is internal to the ViewModel and it should not be exposed to the Activity.

Making it a Change is cleaner but it makes testing more difficult.

Do you have any inputs? Beyond the practical aspects of testing, are there any philosophical aspects to think about?

Here is a scenario:

Your screen supports rotation. A particular Action can generate an error which should display a Snackbar.

How do we deal with it? Emit the error State initially but not after rotation to avoid displaying the Snackbar twice? What should the State be after rotation then?

Should we introduce a concept of Effects (single event type States)?

In the spirit of Roxie's lightweight way of doing things, it would be ideal to solve this with minimal code needed by the consumer apps.