DataSource API consolidation proposal about ohana-ios HOT 6 CLOSED

additionally, the exposed readonly data providers and post processors have little value.
I'd like to remove these fields.

/**
 *  Ordered set of data providers that the data source was initialized with
 */
@property (nonatomic, readonly) NSOrderedSet<id<OHContactsDataProviderProtocol>> *dataProviders;

/**
 *  Ordered set of post processors that the data source was initialized with
 */
@property (nonatomic, readonly, nullable) NSOrderedSet<id<OHContactsPostProcessorProtocol>> *postProcessors;

from ohana-ios.

I disagree on the second post here, having access to the data providers is needed, post processors not so much

from ohana-ios.

I also propose making the onContactsDataSourceReadySignal actually fire a list of of contacts.

Sounds great to me!

from ohana-ios.

Might make more sense to move some of these headers into an extensions category that users can choose to pull in or not. That way we Don't have to delete them but they are not part of the top level API

from ohana-ios.

@maxwellE can you give an example where it's useful to expose the DataProviders here? I might be being daft but i'm not seeing the value in general, and more specifically i'm not understanding why the DataSource should be the one doing it. (If a consumer truly needs a DataProvider later, can they just hold it?)

from ohana-ios.

Also i'm heavily pro making the interface lean for understandability's sake, and if the properties are superfluous, moving them to a category doesn't change that.

If they're not superfluous we should, of course, keep them somehow.

from ohana-ios.