Support "dynamic" options

[delebedev]

Use case:

1. There is a option called "Custom endpoint"
2. Switching it to on uncovers one more option below: "URL"

I have some ideas how implement that in a nice way, now I have a flag in my viewController:

        if (self.flag) {
            [section addCell:[BODateTableViewCell cellWithTitle:@"url" key:@"url" handler:nil]];
        }

rebuilding list is done by:

[self setup];
[self.tableView reloadData];

I have some ideas how to do it in more declarative way, and ready to discuss them if you think it's worthy to have this feature.

[davdroman]

Yeah this has been an idea I've had from the beginning. I'd like to discuss with you what the best approach would be.

Let's start off by discussing a simple problem: should "optional" cells depend only on boolean setting values (BOSwitchTableViewCell)? That'd simplify a lot of work, but I'm not sure about the limitations that such decision could impose.

[delebedev]

Generally speaking, I've seen only bool-dependent examples in real life. However, I can imagine a case where UI should be updated when you select one of enum options in child settings view controller: returning to my example with endpoints, if you select development endpoint from list of options, the settings should show more switches/settings.

[delebedev]

my original idea was to add optional block as a parameter to cell constructor, like

cell = [BOTableViewCell key:"foo" ....  visibleIf: ^ (Settings *settings) {
     \\query settings object if they meet particular condition
    return settings["endpoint"] == "development";
}]

and also some kind of property to each cell, like forcesReload (NO by default), so changing cell with this property set to YES is going to reload whole table and reevaluate visibleIf condition

[davdroman]

@garnett that sounds super clever. I'm definitely into that method 👍

We could make it even more magical if we found a way to automatically determine if reloading is necessary or not depending on which setting each cell depends on. I'll think about a way to achieve that.

[davdroman]

I can think of a visibilityKey property along with a visibilityBlock property passed to the right cell when its visibilityKey changes. That way, if there's a value change for that visibilityKey, we would immediately know we need to reload the table.

Also, as in most cases a cell won't need dynamic visibility, I wouldn't put anything related to it in the init method, but rather let the developer change it in the handler block.

[delebedev]

Sounds good!

[davdroman]

Hey there! I finally got some time to implement this feature and I think it's turned out pretty well. Check it out!

[delebedev]

@davdroman looks exactly how I imagined it, 👍

[davdroman]

Terrific! I'll adjust a couple little things and it'll be ready for release!