Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
feat: more flexible WireUpControls implementation #1250
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
For example, when you have a
What is the new behavior (if this is a feature change)?
When using implicit, it'll default to the way
When using explicit opt-in, you should use the
When using explicit opt-out, it introduces the behaviour of #1217 with the added bonus of opting out certain properties with the
Does this PR introduce a breaking change?
Please check if the PR fulfills these requirements
referenced this pull request
Jan 29, 2017
At first sorry, for the late response. Unfortunately I am quite busy this week...
Thank you for pointing out the issue with the Toolbar. I haven't thought about that but you are totally right. The current solution does not fit this cases properly. It seems like we identified two separate issues with the current implementation
Please correct me if I am missing some other point.
I really like the idea of having the possibility to define which properties should be included or excluded. It is definitely an advantage compared to the current behavior. I was thinking about a similar solution but without using attributes for it. Something like the following pseudo code:
This solution would have the advantage to be able to include or exclude properties from base types which are defined in third part libraries where I cannot add any attribute (e. g. Activity, Fragment, etc.). It would also provide the flexibility to exclude a property just in a given scenario. I am not an RxUI expert but I have a slight feeling that it would better fit to the remaining API because I would not expect the need to use Attributes with RxUI. But this is a highly personal impression.
What do you think about this? Do you think it is worth the overhead on work? It would be great if you could give me some feedback. If there is some interest I could give it a shot. But as I already mentioned your solution is totally an improvement and I am also fine with it.
Thank you for your insights!
The idea you've come up with is actually quite compelling, I agree it fits better in a Rx context. However I don't think I would apply it much to my use cases. Having to exclude certain Views every time (like
Having the possibility to use attributes keeps such housekeeping rules from my code which I prefer personally, but I'd really like to hear other people's opinions about this.
I'm going to rename
We're a week down the road and I've pushed two improvements;
Besides that, I've renamed
Is there anyone in @reactiveui/reviewers-android group that wants to share their opinion?
I've been using this in two separate projects with different resolve strategies now without any problems.