Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: Why is cancelRequest tied to Manager? #142

Closed
skydivedan opened this issue Nov 14, 2017 · 2 comments
Closed

question: Why is cancelRequest tied to Manager? #142

skydivedan opened this issue Nov 14, 2017 · 2 comments
Labels

Comments

@skydivedan
Copy link

I've been using Nuke, and recently have been trying to use DFCache with it. I have no issues with that, but in doing so, it means that I shouldn't be calling loadImage anymore. This is because I need to create my own instance of Manager, that knows about DFCache. Fair enough.

So, I went through my code to start calling CachedNukeManager.loadImage, which works fine. So, then I looked at Nuke.swift and noticed that cancelRequest is a top-level function just like loadImage. So, I figured, I should go through my code and rewrite calls to it as CachedNukeManager.cancelRequest. But after looking at what cancelRequest does, I'm not sure why it's an instance method of Manager, because it only accesses static routines.

I can still change my code over to call CachedNukeManager.cancelRequest, but it seems I don't need to. Is there a plan for Manager to do more here? If not, should cancelRequest just be a public static function?

@kean
Copy link
Owner

kean commented Nov 14, 2017

Hey!

If not, should cancelRequest just be a public static function?

It continued working fine because of to the implementation details (Manager uses associated objects under the hood). So, no, it should definitely be a Manager's method.

So, then I looked at Nuke.swift and noticed that cancelRequest is a top-level function just like loadImage

I've added those top-level functions a while ago simply because I saw Alamofire do the same thing (I'm a bit older and a bit wiser now). There are a lot of reasons why this was a bad idea. If I ever get to release Nuke 6, I would definitely remove those, should've done this a while ago. There are almost 0 benefits in having them, and plenty of drawbacks.

Is there a plan for Manager to do more here?

There have been a lot of plans for improving and extending Nuke, but I simple don't have enough time and motivation to do that right now. I do use Nuke, Nuke+Alamofire and RxNuke (but not other plugins) at my current job though. As soon as I need more features (e.g. progress reporting), I'll probably revisit it. For now, it's in maintenance mode unfortunately. I spend all my free time on Yalta and articles.

@kean kean added the question label Nov 22, 2017
@kean
Copy link
Owner

kean commented Nov 22, 2017

Removed in Nuke 6 (WIP).

@kean kean closed this as completed Nov 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants