Need help to make the code look more coherent using Parse-RACExtensions about parse-racextensions

[kastiglione]

Let's see, here's a few thoughts:

1. You don't need the top level +createSignal: in -saveTagListSignal:. You can simply return a signal composition based off -rac_findObjects.
2. Instead of chaining with -doNext:, try writing this with -flattenMap: and compare the two approaches.
3. Why are you using -deliverOn:?
4. I noticed you're logging completion, have a look at -logCompleted, and friends -logAll, -logNext, and -logError.
5. Instead of iterating over each tag name, and creating a single tag in -saveTagList: using -rac_save, you could batch the tag objects into an array and call +[PFObject rac_saveAll:].

Hope that helps, feel free to follow up with more questions.

[bangedorrunt]

Hi @kastiglione, your pointer is excelent. Here is my feedback:

1. I did notice that and removed those lines
2. -doNext: means only inject side effect after there is a subscription to signal, -flattenMap: convert existing signal into new signal of signals and flatten it into a single new signal, am I correct?
3. -deliverOn: makes me confused. I thought I will use it whenever I want my tasks done in background just as same as I use with dispatchasync??? I assume you question mark it because -saveInBackground: already run my task in background, so there is no need to use -deliverOn:. Am I correct?
4. I have no idea about those until now, I will learn them asap bcoz it would help me trace back my signal process???
5. You're absolutely right on the money. I just read over your header files and realized Parse also has the corressponding methods.

Here is my new line of codes. Look pretty much cleaner now, please give me your view on it :)

- (RACSignal *)saveTagListSignal:(NSArray *)listOfTagArray {
    // Perform scanning tag database, if new tag is matched with query data, skip that tag
    PFQuery *tagQuery = [PFQuery queryWithClassName:@"Tag"];
    [tagQuery selectKeys:@[@"tagName"]];
    return [[tagQuery rac_findObjects] flattenMap:^ (NSArray *objects) {
        __block NSArray *pfTagObjects = objects;
        __block NSArray *filteredTagList;

        // Filter the existing tag list, only pick the tag that doesn't exist in the database.
        if ([pfTagObjects count] > 0) { // If there is tags existing in the database
            filteredTagList = _.array(listOfTagArray)
            .reject(^ BOOL (id tagArrayElement){
                return _.array(pfTagObjects).any(^ BOOL (id pfTagObject){
                    return [[pfTagObject objectForKey:@"tagName"] isEqualToString:tagArrayElement];
                });
            }).unwrap;

            // Save filtered tag list to the server first
            filteredTagList = _.array(filteredTagList).map(^(NSString *tag){
                return [self saveTagList:tag];
            }).unwrap;
            return [PFObject rac_saveAll:filteredTagList];
        } else { //  If there is no tag in database

            // Fix the case that duplicated tags are allowed to created if there is no tag in database
            filteredTagList = _.uniq(listOfTagArray);
            // Save new tag list to server
            filteredTagList = _.array(filteredTagList).map(^(NSString *tag){
                return [self saveTagList:tag];
            }).unwrap;
            return [PFObject rac_saveAll:filteredTagList];
        };
    }];
}
- (PFObject *)saveTagList:(NSString *)tag {
    PFObject *newTag = [PFObject objectWithClassName:@"Tag"];
    [newTag setObject:tag forKey:@"tagName"];
    [newTag setObject:[PFUser currentUser] forKey:@"creator"];
    return newTag;
}

[kastiglione]

2. -doNext: means only inject side effect after there is a subscription to signal, -flattenMap: convert existing signal into new signal of signals and flatten it into a single new signal, am I correct?

Close, -doNext: is for side effects on each value sent, not once per subscription. And yes, that's correct about -flattenMap:.

3. -deliverOn: makes me confused. I thought I will use it whenever I want my tasks done in background just as same as I use with dispatchasync??? I assume you question mark it because -saveInBackground: already run my task in background, so there is no need to use -deliverOn:. Am I correct?

Correct. Parse-RACExtensions uses Parse's InBackground methods, and so the work already happens off the main thread. You would want to use deliverOn:RACScheduler.mainThreadScheduler in the case where you were making UI changes.

4. I have no idea about those until now, I will learn them asap bcoz it would help me trace back my signal process???

Yep, they log the even, the signal name, and potentially other information. They can be more helpful than adding manual log statements, and they're quick and easy to add to the code.

[kastiglione]

Further to number 2., if you find yourself using a -subscribe: inside of a signal chain/composition, you should consider whether you really want one of the signal of signals operators, like -flatten, -concat, or -switchToLatest.

[kastiglione]

As for the code, I think there's some redundant code that can be pulled out of the if/else block:

// Save new tag list to server
filteredTagList = _.array(filteredTagList).map(^(NSString *tag){
    return [self saveTagList:tag];
}).unwrap;
return [PFObject rac_saveAll:filteredTagList];

The if/else block could simply build the filteredTagList.

[bangedorrunt]

Thanks heaps @kastiglione 🌟 for helping me point out my problem. I'm so satisfied with your answer. I will close this issue now and another question is coming soon 👍

[kastiglione]

😎