Architecting Liveview interactivity into a paginated grid

I’m wondering if Liveview might be a good fit for this scenario:

There’s a dataset of hundreds of records that all contain images and logged-in judges currently have the ability to vote on them if they click on the image in the grid and view the standalone record page for the item.

There’s a request to bring that voting functionality into the grid view. So each item in a grid of, say, 12 items per page would have vote yes/no buttons.

The part that loses me is the concept of dynamically assigning a changeset to each item in the grid so their vote can write to the db and the vote buttons would refresh to show the vote state. Then the user would click on another item and that would write to the db and refresh its state.

All of this happens on a single page and the user could then click to page two and hit items on that page’s grid.

Could Liveview be wired up to hit all these items as standalone changesets within the grid to achieve the visual interactivity the client is looking for? Would we need to craft some sort of grouped changeset for all the items to pass through? All items would use the same model.

Perhaps you could use an ‘old-fashioned’ channel message (or a POST request) to send a vote to the server, update the db/storage, and then broadcast the updated vote count using Phoenix.PubSub?

Then the relevant LiveView(s) can subscribe to these events and update accordingly.

I’d love to hear if there’s a better way to deal with this though.

5 Likes

I think this here is the key. Each connected user is going to get their own live view process. If you want all of them to do something, you should have each of those processes subscribe to a topic so that you can send messages telling them what to do.

4 Likes

FYI, here’s an example that uses PubSub to trigger LiveView updates (it’s the “CRUD Users” example): https://github.com/chrismccord/phoenix_live_view_example/blob/master/lib/demo_web/live/user_live/show.ex#L24

4 Likes