Iglistkit: How to surface the result of an async call back to a button or view within a cell?

[chrismanderson]

New issue checklist

• [x] I have reviewed the README and documentation
• [x] I have searched existing issues and this is not a duplicate

General information

What's the recommended way of providing the end result of a async/networking call to a button or a view within a cell?

Say I have a Like button on an Instagram post cell. I could setup a delegate from the cell to start the networking call. My question is, do you all have any recommendations on providing the result of that 'like' action back to the cell; e.g. if the "like" succeeded or failed. Another example is an 'Add to Cart' button. I could start a loading spinner on a button when I tap such a button; but I would need to provide the result back to the button when the call completes. I don't necessarily want to reload the entire cell after the networking call ends as I want to, for example, end a 'loading' spinner on the button gracefully versus a hard cell reload.

I could setup the cell to be a delegate of the controller with some sort of performedActionWasSuccessful(bool:) call, but that feels sort of iffy to me. I've looked at some of the examples you all provide such as RemoveCell and I see a lot of great feedback about getting the tap action out of the cell using IGListKit, but not necessarily getting the result back into the cell. Thanks!

[rnystrom]

@chrismanderson great question! We could definitely provide a better example for this.

What we do is something like the following:

1. Do an async fetch in the section controller
2. In the callback (block or delegate, doesn't matter), ask the [collectionContext cellForSectionController:atIndex:] for the cell (on mobile but I think that's the API)
3. Configure the cell however you want. Be careful b/c it can be nil (in case you do something else with it)

Another option is to use some mutable state on the section controller that configures the cell in cellForItemAtIndex:. On your callback, change the local state (maybe self.name = response["name"]), then reload the section controller/cell. I personally like this approach because it keeps the cell configure code in one place vs spreading it out. But, it has the downside of animations (or can't do custom animations).

Plenty of options tho depending on your needs!

[chrismanderson]

Thanks for the response! That first option makes a lot of sense to me for my use case. The second seems a little off to me in terms of storing state on the VC, but always great to see options. It could be a great idea to add this into the example projects repo, maybe along with the RemoveController section; e.g. respond if the remove succeeds or fails.

[kanumuri9593]

hi @rnystrom @chrismanderson ,Thank you its a nice option for my requirement too, but I have a general question extending this topic
lets say you are loading your posts similar to Instagram through some feed Objects array with each object goes into its own section controller and you are using lazy loading concept to keep increasing the array as shown in your examples, then the user clicked the Like and you configured your cell as you suggested
and cell is out of bounds like the user scrolled down/up;
Now my question is when user scrolls backs to the same cell what would be the behavior since we are using collection view the cells are reused so I thought the cell is build using the Post object from the initial array which doesn't contain the updated like status/count
should I reload the whole data ??
lets say since we are using lazy loading the Post like occurred in third batch of data now how will handle it??
would love your suggestion and expertise in handling this situation

[rnystrom]

@kanumuri9593 in Instagram we have mutable stores that track states like these. That's definitely what I would recommend. Here's an example in a GitHub app I'm building:

• Configure cell state in cellForItemAtIndex:
• State is combination of model || local store

[kanumuri9593]

@rnystrom Thanks for a quick response, I will look into your suggestions

[seanliu1]

[lorixx]

[seanliu1]

[lorixx]