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

best practice: update listcell after async operation #41

Closed
smiLLe opened this issue Mar 29, 2015 · 2 comments
Closed

best practice: update listcell after async operation #41

smiLLe opened this issue Mar 29, 2015 · 2 comments

Comments

@smiLLe
Copy link

smiLLe commented Mar 29, 2015

Hey guys,
similar to your example project i am using a CollectionViewController. each cell represents a product.
a ProductModel has readonly properties like (name, brand, photo...) and a boolean property: liked.
liked tells me if the current logged in user has already liked the product.

now back to the cells. the componenttree in my cell has somewhere a button with two different images representing the liked state. after the user presses the button i must request the server to set the new state and the server returns a new ProductModel.
I am unsure where to trigger the async operation.
Should i enqueue an update in my ViewController to update the cell? But then i have to give the components in my cell a callback/selector to a function in my VC?!

@benlodotcom
Copy link
Contributor

A general pattern you can follow here is to use the context (or a regular prop) to pass down a "like handler" (which is an id that behind the scenes might be your VC). You component will then call this like handler.

@adamjernst
Copy link
Contributor

More broadly, this is a great case where you want to apply the Flux application architecture:

https://facebook.github.io/flux/docs/overview.html

Basically you want a central "store" that holds the immutable objects; an "Action" that represents liking; and a "Dispatcher" that handles the Like action by:

  1. Updating the store to reflect the new state;
  2. Communicating with the server to actually perform the like;
  3. Rolling back the change to the store if the server can't be reached for some reason.

Make sense?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants