reactivecocoa / reactivecocoa Goto Github PK

When we talked about renaming RACSubscribable, @jspahrsummers also brought up that RACSubject, too, is terrible but we struggled to come up with a not-awful alternative.

But how about RACMutableSignal? They're mutable in the sense that users can change things about them after they're created, and they tend to be an implementation detail like NSMutableArray vs. NSArray.

The downside is that RACReplayMutableSignal / RACMutableReplaySignal is a pretty ridiculous name.

Has anyone had an app accepted in the iOS or Mac App Stores that uses ReactiveCocoa? I only ask because of it's use of method swizzling (seems to only be an issue when swizzling base methods on Apple's classes). Just looking for confirmation that at least one person has gotten approval before I start using this all over the place.

I'm having issues with RACAbleSelf and RACAbleSelfWithStart, whereby my class has a public NSURL property urlToLoad:

@property(nonatomic, strong) NSURL *urlToLoad;

However when I call the following (as shown in all the samples):

[[RACAbleSelfWithStart(self.urlToLoad) distinctUntilChanged] subscribeNext:^(NSURL * newURL) {…}];

I get the following error:

*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<MyViewController 0x8bb33a0> valueForUndefinedKey:]: this class is not key value coding-compliant for the key self.urlToLoad.'

I've tried changing it to just:

[[RACAbleSelfWithStart(urlToLoad) distinctUntilChanged] subscribeNext:^(NSURL * newURL) {…}];

This works, but my app complains about observation info being leaked whenever the view controller is deallocated. Breaking on NSKVODeallocateBreak doesn't yield anything useful, but I assume that the NSURL instance is somehow outliving the view controller. Here's the error

An instance 0xf47de20 of class MyViewController was deallocated while key value observers were still registered with it. Observation info was leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info:
<NSKeyValueObservationInfo 0x13e6a190> (
<NSKeyValueObservance 0x13e6a150: Observer: 0x13e6a0c0, Key path: urlToLoad, Options: <New: NO, Old: NO, Prior: NO> Context: 0x19e6a0, Property: 0x13e6a1d0>
)

Hi there,

I checked out latest commit (c8a9a90), made a git submodule update --recursive --init and opened GHAPIDemo.
Typing into the username textfield gives every char in double, so typing a test shows tteesstt in the text field. Theres also a lot of output in the console, starting with

2012-11-12 10:34:20.258 GHAPIDemo[10448:303] *** Enabling asynchronous backtraces
2012-11-12 10:34:20.409 GHAPIDemo[10448:303] Active requests: 0
2012-11-12 10:34:27.310 GHAPIDemo[10448:303] -[__NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff7ab73930
2012-11-12 10:34:27.310 GHAPIDemo[10448:303] An uncaught exception was raised
2012-11-12 10:34:27.311 GHAPIDemo[10448:303] -[__NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff7ab73930
2012-11-12 10:34:27.314 GHAPIDemo[10448:303] (

If a subscribable sends nil, then switch fails it's assert:

NSAssert2([x conformsToProtocol:@protocol(RACSubscribable)], @"-switch requires that the source subscribable (%@) send subscribables. Instead we got: %@", self, x);

From a cursory glance at the code there doesn't seem to be any practical reason why nil wouldn't be a valid value.
Is requiring a non-nil subscribable a design choice or just something that never came up?

Installation on the Mac is rather straightforward, but on iOS it's a little bit more prone to error due to the additional linker flag needed. A section in the readme would be fantastic so people just getting started won't be frustrated with runtime errors. 🤘

Hey everyone,

I added ReactiveCocoa to my iOS project but Im having issues.

Attempting to test with a canonical example:

    [RACAble(self.someProperty) subscribeNext:^(id x) {
        NSLog(@"%@",x);
    }];

2012-11-05 15:04:09.988 ASDF[77632:c07] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[ACRootViewController rac_subscribableForKeyPath:onObject:]: unrecognized selector sent to instance 0x817a2d0'

It'd be totally possible to add a do syntax for the <RACStream> monad, though it'd have to work a bit more like Clojure's domonad than Haskell's do statement.

But I'm wondering whether this would even be useful. How often would people be repeatedly binding in a way that this would be valuable?

Regardless of scheduler and subjects' serialization issues, methods that subscribe to multiple signals have serialization issues if the signals they subscribe to send from different threads.
+combineLatest:reduce: and -flatten: are affected for sure, +zip:reduce: doesn't seem to have issues since it synchronizes all subscriptions.

When trying to compile RACiOSDemo/RACiOSDemo.xcodeproj on a version of Xcode that doesn't target iOS 5.1 as the default (REDACTED, for example), the target iOS target for the demo is set to iOS 5.1, and it builds correctly, but the Framework is only built for the default version, so when the Demo runs, the Framework won't load because it has the wrong target.

This leads to immediate crash with runtime error:

dyld: lazy symbol binding failed: Symbol not found: _objc_setProperty_nonatomic_copy

And I figured I'd save someone else the trouble of figuring out what the Hell Xcode meant by that.

I’ve recently added ReactiveCocoa to the CocoaPods package manager repo.

CocoaPods is a tool for managing dependencies for OSX and iOS Xcode projects and provides a central repository for iOS/OSX libraries. This makes adding libraries to a project and updating them extremely easy and it will help users to resolve dependencies of the libraries they use.

However, ReactiveCocoa doesn't have any version tags. I’ve added the current HEAD as version 0.0.1, but a version tag will make dependency resolution much easier.

Semantic version tags (instead of plain commit hashes/revisions) allow for resolution of cross-dependencies.

I use RAC in my ios project, but I find that there is something problem about subscribe disposition.

that is,
in a view controller A, I write

        __unsafe_unretained id weakSelf = self;
        [[RACSubscribable combineLatest:[NSArray arrayWithObjects:RACAbleSelf(self.name), RACAbleSelf(self.desc), RACAbleSelf(self.avatar), RACAbleSelf(self.state), RACAbleSelf(self.city), nil] reduce:^id(RACTuple *xs) {
            return [NSNumber numberWithBool: ![[xs objectAtIndex:0] isEqualToString:user.nickName]
                    || ![[xs objectAtIndex:1] isEqualToString:user.desc]
                    || ![[xs objectAtIndex:2] isEqualToString:user.avatar]
                    || ![[xs objectAtIndex:3] isEqualToString:user.birthState]
                    || ![[xs objectAtIndex:4] isEqualToString:user.birthCity]];
        }] subscribeNext:^(NSNumber *needUpdate) {
            PersonalSettingController *this = (PersonalSettingController *)weakSelf;
            if ([needUpdate boolValue]) {
                this.navigationItem.rightBarButtonItem = [UIBarButtonItem barButtonWithText:NSLocalizedString(@"保存", nil) target:this action:@selector(__saveUserInfo)];
            }else {
                this.navigationItem.rightBarButtonItem = nil;
            }
        }];

       __unsafe_unretained id weakSelf = self;
        [[[[RACSubscribable merge:[NSArray arrayWithObjects:
                                   RACAbleSelf(self.allowSearch),
                                   RACAbleSelf(self.name),
                                   RACAbleSelf(self.call),
                                   RACAbleSelf(self.isDefault),
                                   nil]] distinctUntilChanged] take:1] subscribeNext:^(id _) {
            FamilyMemberEditController *this = (FamilyMemberEditController *)weakSelf;
            this.navigationItem.rightBarButtonItem = [UIBarButtonItem barButtonWithText:NSLocalizedString(@"保存", nil) target:this action:@selector(__saveFamilyMember)];
        }];

Steps to reproduce:

1. Create a new git repo git init
2. Add ReactiveCocoa as a submodule git submodule add git://github.com/github/ReactiveCocoa.git Dependencies/ReactiveCocoa
3. Pull in ReactiveCocoa's dependencies with git submodule update --init --recursive
4. Create a new Xcode iPhone project in the repo.
5. Drag the ReactiveCocoaFramework/ReactiveCocoa.xcodeproj project file into the new project's project navigator.
6. Add the ReactiveCocoa-iOS static library target as a dependency of the iPhone project's application target under Target Dependencies.
7. Link against the libReactiveCocoa-iOS.a library by adding it under the iPhone project's application target Link Binary With Libraries box.
8. Build

Behavior:

Following build errors are emitted:

Build target ReactiveCocoa-iOS

Check dependencies

The file "Debug.xcconfig" couldn’t be opened because its path couldn't be resolved.  It may be missing.
The file "iOS-StaticLibrary.xcconfig" couldn’t be opened because its path couldn't be resolved.  It may be missing.

[ . . . snip RACCommand.m compiler invocation . . . ]

/Users/bvanderveen/code/TestRAC/Dependencies/ReactiveCocoa/ReactiveCocoaFramework/ReactiveCocoa/RACCommand.m:47:12: error: __weak attribute cannot be specified on an automatic variable [-Werror]
        __weak id weakSelf = self;
              ^
1 error generated.

I'm having trouble with a scenario like this:

RACReplaySubject *subject = [RACReplaySubject subject];
[subject sendError:[[NSError alloc] init]];

[[[subject asMaybes] take:1] subscribeNext:^(id x) {
  // I loop 4evar
} completed:^{
  // I never complete
}];

RACAble(property) 
select:^id(id x) {
    return [[<a replay subject> asMaybe] take:1]; }
switch
subscribeNext:...

I'm starting to think +rac_subscribableFor:keyPath:onObject: should send the current value of the key path when it is first called. It already replays the last value, but it seems even better to ensure a subscribable for a property will always have the current value, even if it's nil.

This is causing problems with CocoaPods. CocoaPods/Specs#804

I propose that we unify next, error, and completed into a single stream of values, so that error and completed are no longer "out of band" communications. In effect:

• An NSError value is equivalent to sendError:.
• RACUnit.defaultUnit is equivalent to sendCompleted. Most of the framework's current uses of RACUnit could easily be replaced with something else, like nil or a dummy value.
• Anything else is equivalent to sendNext:.

This would provide a couple huge advantages:

• Subscribables could have useful head and tail implementations that don't require any translation of the "error" or "completed" concepts.
• Monadic bind could be applied to subscribables.

Among other things, this would facilitate interoperation with a concept of sequences like that described in #89.

Obviously, this would be a huge breaking change. However, subscriber-side APIs don't have to change that much – subscribeNext:, subscribeError:, subscribeCompleted, and most of the concrete methods in <RACSubscribable> could, for convenience, distinguish values as above. Errors and completion could still terminate subscriptions without violating the above semantics.

@xpaulbettsx @joshaber @jonsterling

A cough interesting preview of Xcode version-that-shall-not-be-named complains of RAC creating a block retain-cycle in RACSequence's bind: method. Upon return nextSequence() is captured strongly.

Maybe through a public -addDisposeBlock: method on RACDisposable.

For instance, I would like to retain the GCD semaphore in firstOrDefault:success:error:, and have it be released only when the subscribable is completely torn down.

I know that RACTupleNil was deliberately chosen over EXTNil at one point, but I don't remember/understand the motivation for it.

EXTNil interoperates with code that expects nil or NSNull, so is more "backwards compatible" in a certain sense. This same property also makes it nicer for things like RACBlockTrampoline, because EXTNil == nil for most intents and purposes.

I checked out the latest commit and tried to login with invalid account/password many times. The spinner hid the first time but remained unhidden since the second time. Looks like the subscription wasn't triggered.

Hello ladies and gentlemen,

I'm actually trying to implement the following example from the original blog post:

[[[[client 
    loginUser] 
    selectMany:^(id _) {
        return [client loadCachedMessages];
    }]
    selectMany:^(id _) {
        return [client fetchMessages];
    }]
    subscribeCompleted:^{
        NSLog(@"Fetched all messages.");
    }]

-(RACAsyncSubject*)loginUser
-(loadCachedMessages*)loginUser

Investigating some memory leaks in my application, I've found that whenever I use RACAbleSelf to subscribe for changes to a property on an object, that object is never freed. If I use a weak pointer inside the block, my object is freed, but about 60 KB of RAC infrastructure is retained somehow even though nothing is actively referencing it.

I've reproduced this with the following simple code:

//
//  main.m
//

#import <Foundation/Foundation.h>

#import <ReactiveCocoa/ReactiveCocoa.h>

@interface MyClass : NSObject

@property (nonatomic) NSString *value1;
@property (nonatomic) NSString *value2;

@end

@implementation MyClass

@synthesize value1, value2;

- (MyClass *)initWithWeak:(BOOL)isWeak
{
  self = [super init];
  if (self) {
    if (isWeak) {
      __weak __block id weakSelf = self;
      [[RACAbleSelf(value1) distinctUntilChanged] subscribeNext:^(id x) {
        NSLog(@"Using weak: subscribeNext called with x=%@", x);
        MyClass *strongSelf = weakSelf;
        strongSelf.value2 = strongSelf.value1;
      }];
    } else {
      [[RACAbleSelf(value1) distinctUntilChanged] subscribeNext:^(id x) {
        NSLog(@"Not using weak: subscribeNext called with x=%@", x);
        self.value2 = self.value1;
      }];
    }
  }
  return self;
}

@end

int main(int argc, const char * argv[])
{
  @autoreleasepool {
    // Pause for a while to give time to connect with Instruments.app
    [NSThread sleepForTimeInterval:30];

    MyClass* mc = [[MyClass alloc] initWithWeak:YES];
    mc.value2 = @"foo";
    mc.value1 = @"bar";
    mc.value1 = @"bar"; // Repeat a value to ensure distinctUntilChanged works
    mc.value1 = @"baz";

    NSLog(@"value1 = %@", mc.value1);
    NSLog(@"value2 = %@", mc.value2);

    mc = nil; // Should cause all allocated objects to be freed

    // Give time to mark another heap snapshot before exiting
    [NSThread sleepForTimeInterval:30];
  }

  return 0;
}

Hey guys, I can't do a clean checkout of RAC at the moment, as the expecta submodule appears to have come unhinged:

➜  ReactiveCocoa  git submodule update --init --recursive 
Submodule path 'external/expecta': checked out '4cee0c92acc4fad2c908a49bee910d408ed43199'
fatal: reference is not a tree: 58126ef0ee2d9dcc515bf1697ea4ac225bc57397
Unable to checkout '58126ef0ee2d9dcc515bf1697ea4ac225bc57397' in submodule path 'external/specta'

If two nexts, or a next and a completed, etc., get sent to a concurrent GCD or operation queue, they might be processed simultaneously. Most <RACSignal> and <RACStream> methods are not written to accommodate this.

<RACScheduler> should serialize scheduled blocks, even when ultimately delivering to a concurrent queue. The deferredScheduler is also extremely dangerous, because it seems like we can't make the same guarantees there.

Noted in #93:

RACReplaySubject *subject = [RACReplaySubject subject];
[subject sendNext:@(1)];
[subject sendCompleted];
[[[subject repeat] take:1] subscribeNext:^(id x) { ... }];

Sequences were originally suggested for Mantle in Mantle/Mantle#1, but after doing some work on a sequences branch there, I'm wondering if it makes more sense to provide this facility in ReactiveCocoa.

Conceptually, sequences and subscribables support many of the same kinds of operations (map, filter, concat, cons, etc.), and both represent streams of things.

There are a couple of major differences, though:

• Sequences can be lazy, and are inherently repeatable (i.e., not time-based). Subscribables are neither of those things.
• Subscribables model errors and completion, neither of which apply to a general-purpose sequence.

I think subscribables can be represented as sequences, but the opposite is not true – sending a sequence through a subscribable would require evaluating the entire thing.

@joshaber @xpaulbettsx @jonsterling Any thoughts on this?

This would easily allow us to consume ReactiveCocoa by adding the following code in our Podfile.

platform :ios
pod "ReactiveCocoa", :git => 'https://github.com/github/ReactiveCocoa.git', :tag => 'v0.8.0'

I'm sort of a newbie to Xcode, but it's not obvious how to include this library in your project. Some other libraries I have been able to drag and drop into the Frameworks section. This one seems like you have to install it as a subproject. When I followed these instructions, however, I got errors: http://yannickloriot.com/2011/04/how-to-install-zxing-in-xcode-4/. Some instructions in the README.md would be great.
Thanks.

Hi. I have a question about using RAC with CoreData, core data handle NSManagedObjects and dealloc swizzling not work as expected, so we have RACObjects leaked. Or I understand something wrong?

Hi Guys,

I'm getting the following error when doing a fresh clone/submodule update:

Submodule path 'GHAPIDemo/external/AFNetworking': checked out '553e1d7e6b7373e79d14ad71a4e67e6513d1b09a'
Submodule path 'external/expecta': checked out 'ed36c2a75c5b811837ee9dd0194066c8c53b6c76'
Submodule path 'external/jrswizzle': checked out '315b2f01688f828eec262ca80be5d853c4d00d03'
fatal: reference is not a tree: 948bfa115a0a422f1d254797e49bcc1468f03606
Submodule path 'external/xcconfigs': checked out '73f4162d29dcb6c8711248b43398f72d821bf917'
Unable to checkout '948bfa115a0a422f1d254797e49bcc1468f03606' in submodule path 'external/specta'

The README doesn't mention anywhere that submodules need to be cloned too. We should include information about recursive cloning or submodule initialization.

I'm looking at the NSObject(RACSubscribable) category, and it would seem that all of its methods assert conformance to <RACSubscribable> at runtime. Wouldn't this be better placed in the actual <RACSubscribable> protocol? It seems like that would be the safer and more hygienic approach.

Are there some use-cases that make the current approach necessary, or at least more optimal?

I've had success using the RACAble macro to create an observable/subscribable, but I keep getting the following exception some time after sending [RACSubject subject] on iOS simulator:

-[RACSubject rac_performBlock:afterDelay:]: unrecognized selector sent to instance 0x812d3f0

I'd assume I'd just be able to create a subject outright, but somewhere down the line something blows up. Not sure if I've got a something configured incorrectly in my project, or if I'm just using the API incorrectly.

As pointed out by @Coneko in #136, sending next, error, or completed to a RACSubscriber or RACSubject from multiple threads might result in them being processed simultaneously, and most <RACSignal> and <RACStream> methods aren't built to handle it.

Subjects and subscribers should serialize their messages onto a private queue so that stream methods don't have to worry about synchronization.

The rac_toSubscribable method is pretty similar to the rac_sequence functionality provided on the built-in collection classes. Arguably, the laziness of rac_sequence also leads to a better API.

If RACSequence supported indexing and had first, second, etc. convenience methods like RACTuple, we could effectively get rid of the latter and be left with much more flexible tuples.

One of the consequences of Apple's unfortunate (and usually unnecessary) use of informal protocols is that under UIKit, the NSObject(UIResponderStandardEditActions) category pollutes nearly the entire object namespace with methods like -select:.

The result is that the compiler can't resolve the static type of a -select: message: is it (id → id) → RACSubscribable* or is it id → void? So we get a compiler warning.

This can be solved by renaming RAC's -select: method; with my background, I'd of course suggest -map:, but that would be somewhat non-conformant with the LINQ-inspired scheme you guys have going (as well as the Smalltalk heritage of Objective-C)...

I've found when doing reactive UI stuff, I end up using -rac_deriveProperty:from: a lot. It's awesome for the most part, but it doesn't read very naturally. What I really want to write and read is something like:

self.titleLabel.textColor = someSubscribable;

I've come up with two different ways to write something more like that, both with tradeoffs, so I'd like to get some feedback.

Keyed subscripting:

rac(self.titleLabel.textColor) = someSubscribable;

That abuses keyed subscripting. It works for both object and non-object properties. The downside is that the class has to implement -setObject:forKeyedSubscript:. We can create a macro that does it for them, but it's an extra step users have to remember per-class.

Proxy bounce

self.titleLabel.rac.textColor = (id) someSubscribable;

// ooooh also:
[self.createButton.rac setTitleColor:(id) someSubscribable forState:UIControlStateNormal];

For blocks given to RACSignal+Operations methods that don't themselves return a signal, it's difficult – if not outright impossible – to indicate error cases. RAC could catch exceptions thrown by those blocks (since it invokes them directly) and translate those into errors.

It's not clear what advantage RACAsyncSubject offers over RACReplaySubject. It seems like the latter has a strict superset of the former's behavior. It also seems like a safer default to replay the whole subscribable stream, rather than just the last thing sent.

It's a little weird that RAC even provides this category, but I could see an argument for it.

In any case, it should be prefixed like every other category.

NB: This has been discussed to some extent on Twitter, but I think it's worth tracking as an issue.

While it's possible to subscribe to NSUserDefaults values using the following syntax:

[[[NSUserDefaults standardUserDefaults] rac_subscribableForKeyPath:kDWKUserDefaultRequirePasscodeToUnlockKey onObject:self] subscribeNext:^(NSNumber *newValue) {
    ...
}]];

rac_select:, rac_where:, and rac_any: duplicate functionality provided in Mantle, and can also be expressed using <RACStream> (through NSArray.rac_sequence).

I just ran into a situation where I needed this.

Like +combineLatest:reduce: except it should only reduce to a new value when it's received a new value from each subscribable since it was last reduced. Would also be useful for sequences.

I've been reading the Rx Design Guidelines, and it occurred to me that RAC doesn't have any equivalent documentation about how to use and extend it.
Normally the method and class documentation fulfills this, but there are some edge cases, #138 for example, that aren't covered.

A general framework-level design guideline rather than a class-level explanation of specific behaviors would be clearer and easier to consult in these cases.

Not necessarily a 30+ page document like the Rx one, but a couple of notes about how the various parts fit together and what they do and don't guarantee regarding thread safety, concurrency, memory management etc.

Possibly an interaction between repeat and asMaybes operations when the subject has error set?

Cancelable signals were created out of need but I don't think they're the best way to address the problem.

They're conceptually weird. What does it mean to cancel a signal? Does it complete? Does it error?

We should re-think this.

Then they're not typed id, but still work with subclasses.

The implementation of whenAll::

+ (RACSubscribable *)whenAll:(NSArray *)subscribables {
    return [self combineLatest:subscribables reduce:^(RACTuple *xs) { return [RACUnit defaultUnit]; }];
}

[subscriber sendNext:reduceBlock([RACTuple tupleWithObjectsFromArray:orderedValues])];

+ (RACSubscribable *)whenAll:(NSArray *)subscribables {
    return [self combineLatest:subscribables reduce:^(RACTuple *xs) { return xs; }];
}