Feature/property documentation #101
Conversation
|
It seems natural to host them in ReactiveSwift. Perhaps we could turn them into links in ReactiveCocoa, hmm? |
Documentation/FrameworkOverview.md
Outdated
|
|
||
| The `<~` operator can be used to bind properties in different ways. Note that in | ||
| all cases, the target has to be a [`MutablePropertyType`][Property]. | ||
| all cases, the target has to be a [`BindingTarget`][BindingTarget], [`MutableProperty`][MutableProperty] is the only property that implements this. |
There was a problem hiding this comment.
BindingTarget is a concrete type. Maybe
binding target, represented by
BindingTargetProtocol
instead?
Moreover, MutableProperty is not the only property type that can be a target, since it inherits the capability from MutablePropertyProtocol. I'd prefer to say:
All mutable property types are inherently a binding target.
…n ReactiveCocoa, not in ReactiveSwift
I agree that the documentation for things implemented in ReactiveSwift should be hosted in ReactiveSwift. Still not sure if the Documentation in ReactiveCocoa should just link back to ReactiveSwift or be complete, maybe I'll just try both and see how it feels... |
Documentation/FrameworkOverview.md
Outdated
| so their changes should be observed through other mechanisms. | ||
| [`MutableProperty`][Property] should be preferred over dynamic properties | ||
| whenever possible! | ||
| [ReactiveCocoa][ReactiveCocoa] implements a number of extensions on AppKit and UIKit to allow observation of and binding to properties via the `.reactive` structure. |
There was a problem hiding this comment.
I think we can remove this mention of ReactiveCocoa.
| property.value = 2 | ||
| } | ||
|
|
||
| scopedExample("`skipRepeats`") { |
There was a problem hiding this comment.
This appears to be a duplication of the more-complete example below.
There was a problem hiding this comment.
Oh right, I created the more complex example for uniqueValues first and then decided to use the same sequence for skipRepeats as well to better illustrate the difference.
I'll clean up the simple example.
|
Thanks for the PR! I think we can focus on ReactiveSwift here, without mentions of ReactiveCocoa. ReactiveCocoa doesn't need to duplicate the information here, but could link to it. Adding a page to RAC that explains |
|
Alright, @mdiep I've addressed your comments |
|
Thanks @iv-mexx! This is great. ✨ |
|
Thanks! I'll probably look into the documentation some more soon |
3 participants
This resolves #6
I tried to stick to stick to the existing playground documentation for Signal and SignalProducer.
I've also updated the Properties part in
FrameworkOverview.md.This document is duplicated in ReactiveCocoa, either it should be updated there as well, or the documentation should be de-duplicated between ReactiveCocoa and ReactiveSwift?