Return AutoFetchCollection in v2

[meerkapp]

In version 2, AutoFetchCollection became a collection with AutoFetchDataAdapter. Don't you find this approach confusing? Collections with AutoFetchDataAdapter do not have the same capabilities as collections with other adapters. For example, we add collections to SyncManager, so in theory we can add a collection with AutoFetchDataAdapter. But that's not how it works. In my opinion, the best option is to return AutoFetchCollection by making a separate class, which uses AutoFetchDataAdapter by default. I also don't quite understand how in v2 I can check whether data has been uploaded to AutoFetchDataAdapter for a specific request. The registerQuery and unregisterQuery methods are missing. The only way to register a request now is to call the find method.

About AutoFetchCollection

[maxnowack]

I wanted to separate “how we fetch/handle external data” from the Collection itself. The goal is for Collection to focus only on two things: delegating CRUD operations and exposing a reactive API around them. That’s why I removed AutoFetchCollection (and its parent ReplicatedCollection) and moved that behavior into data adapters, which felt like a more flexible direction overall.

That said, the current AutoFetchDataAdapter is just a first pass, and I’m very open to improving or extending it.

Bringing back an AutoFetchCollection wrapper doesn’t seem wrong to me either. If it’s essentially a convenience class that defaults to AutoFetchDataAdapter, that sounds like reasonable syntactic sugar and I’d be fine with that approach.

Thanks for your thoughts. PRs are highly appreciated 🙂