Allow connecting to any IEnumerable<T>

[DaRosenberg]

Now that we have AutoRefresh() and Filter() it would make sense to be able to connect to any type of enumerable, even immutable ones, because the combination of AutoRefresh() and Filter() basically introduces the observability.

Now we have to do something like this:

var o = new ObservableCollection<StaticRowInfo>(someArray)
        .ToObservableChangeSet()
        .AutoRefresh(x => x.IsVisible)
        .Filter(x => x.IsVisible)

I.e. wrap the array in an observable collection that will not be used for anything, just take up unnecessary memory.

Would be nicer if we could do something like this:

var o = someArray
        .ToObservableChangeSet()
        .AutoRefresh(x => x.IsVisible)
        .Filter(x => x.IsVisible)

The implementation should preferably not simply create a wrapper ObservableCollection<T> behind the scenes, because then this improvement would be little more than syntactic sugar.

[robsonj]

Maybe some thin wrapper over IEnumerable that implements IObservable<IChangeSet> ?

[RolandPheasant]

Something like this (for both list and cache)

var myObservableChangeSet =  myEnumerable.ToObservableChangeSet()

and implement a light weight source to act as the backing store

public class OneTimeSourceList<T>: IObservableList<T>
{
       \\implement with simplified internals
}

[DaRosenberg]

Yes, exactly!

[robsonj]

Would this not work...

    public static class ObservableListEx
    {
        public static IObservable<IChangeSet<T>> ToObservableChangeSet<T>(this IEnumerable<T> self)
            => self.ToObservable().ToObservableChangeSet();
    }

[glennawatson]

The implementation should preferably not simply create a wrapper ObservableCollection behind the scenes, because then this improvement would be little more than syntactic sugar.

I believe that would violate that line. Would work but a bit of extra overhead.

[robsonj]

Is it extra overhead though? I gotta download the MS source to see what it is actually doing.

[robsonj]

Next version...

    internal class OneTimeSourceList<T> : IObservableList<T>
    {
        internal OneTimeSourceList(IEnumerable<T> source)
            => Items = source;

        public IEnumerable<T> Items { get; }

        public IObservable<int> CountChanged
            => Observable.Empty<int>();

        public int Count
            => Items.Count();

        public IObservable<IChangeSet<T>> Connect(Func<T, bool> predicate = null)
            => Observable.Defer(() =>
        {
            var change = new Change<T>(ListChangeReason.Add, Items);
            var changeSet = new ChangeSet<T>(new[] {change});
            return Observable.Return(changeSet);
        });

        public void Dispose()
        {
        }
    }

    public static class ObservableListEx
    {
        public static IObservable<IChangeSet<T>> ToObservableChangeSet<T>(this IEnumerable<T> self)
            => new OneTimeSourceList<T>(self).Connect();
    }

[RolandPheasant]

Something like that is perfect

[robsonj]

Not sure the OneTimeSourceList is even needed to be honest, the Observable.Defer() code could be inlined into the extension method

[glennawatson]

So like a ienumerable.tochangeset or something.

[robsonj]

    public static class EnumerableExtensions
    {
        public static IObservable<IChangeSet<T>> ToObservableChangeSet<T>(this IEnumerable<T> self)
            => Observable.Defer(() =>
            {
                var change = new Change<T>(ListChangeReason.Add, self);
                var changeSet = new ChangeSet<T>(new[] { change });
                return Observable.Return(changeSet);
            });
    }

Example usage...

IObservable<IChangeSet<T>> result = myEnumerable.ToObservableChangeSet();

[RolandPheasant]

That's even better

[glennawatson]

I guess the only disadvantage of the above is it's not really observable. Although it keeps it consistent so it's transparent for observable collections etc.

[robsonj]

Why isn't it Observable? I guess if you mean, if you then add an item to the source enumerable after calling this extension, then no you wont get any additional changeset notification for that add, but I don't see any way around that due to the source being a plain old enumerable.

[DaRosenberg]

The inline approach looks pretty much perfect to me. I was going to point out that the OneTimeSourceList should either have an overridable Dispose() implementation or be sealed, but the extension method approach makes that a moot point.

"Not observable" in that sense is precisely the benefit of this proposal - my suggestion was inherently intended for scenarios where the underlying IEnumerable<T> is assumed to be immutable, or where we otherwise don't care about changes past the point of subscription.

[robsonj]

Yea, I think the extension method should cover your needs then. I'll submit a pull request later this evening with some unit tests if the proposed solution is acceptable

[glennawatson]

Yeah I agree, just the only other alternative is instead of using ToObservableChangeSet() as a name use ToChangeSet()

I think the I prefer keeping one consistent naming scheme myself though.

[RolandPheasant]

Awesome. Could you do the same but add a key selector overload so it can equally apply to cache.

Also could you add the extensions to ObservableListEx and ObservableCacheEx respectively

[robsonj]

Yep, will do Roland.