Yet another stylistic/preferential question--forgive me for having so many of these but once they're firmly answered I'll move forward without causing any trouble!
We've recently had some discussions about naming subjects that track user interactions appropriately such as (addFeatureClicks) etc. Most of these currently (or will) live in viewmodels as subjects. However, I think it may be more appropriate to track interactions (clicks, etc) in the fragment, granting the view models some level of independence.
This is already the case in some sense, but we currently often mix RX methods and approaches with more traditional direct VM method calls etc. Instead, we can stick to RX as much as possible, creating observables/subjects to track fragment interactions and capturing responses to view model data as transformations on these interactions.
see 4491816 experimental/scolsen/observable-views for an example using this approach.
For reference, here's a relevant snippet from the previously mentioned commit:
First, we specify the appropriate fragment reaction in the onCreate method and subscribe to the stream:
@Override
public void onCreate(@androidx.annotation.Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
saveClicks = PublishSubject.create();
singleSelectDialogFactory = new SingleSelectDialogFactory(getContext());
multiSelectDialogFactory = new MultiSelectDialogFactory(getContext());
viewModel = getViewModel(EditRecordViewModel.class);
Observable<Boolean> saveClickReactions =
saveClicks
.map(__ -> viewModel.onSaveClick())
.doOnNext(
result -> {
if (!result) {
EphemeralPopups.showFyi(getContext(), R.string.no_changes_to_save);
navigator.navigateUp();
}
});
saveClickReactions.subscribe();Second, when a user clicks, drags, w/e, we emit:
@OnClick(R.id.save_record_btn)
void onSaveClick() {
saveClicks.onNext(new Object());
}Note that this is mostly a stylistic difference and it may be totally unnecessary if we're able to switch every fragment/VM data coupling to LiveData bindings. This approach does grant us some additional flexibility in that it's now fairly straightforward to accumulate further transformations/interactions on the initial stream, and it eliminates the need to track any state for dependent reactions (if any exist, we can simply model them as transformations, merges, etc.).
It also frees up
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent