Table doesn't always refresh when value of data prop is changed

[hadfieldn]

When the data prop of SurfaceBelma.Table is changed, if the internal sorted_by assign is nil, then sorted_data/1 returns the new data value only if the sorted_data assign is nil, which is true only on mount.

As a result, the table does not render changes made to the data prop until it is remounted or resorted.

(As a workaround, I was able to force a refresh by calling send_update/3 to trigger an update, passing sorted_data as an assign set to the updated value of data, so that it would be the value returned by sorted_data/1.)

If I can find the time in the next few days I'll try to submit a fix, but I wanted to get this recorded before I forget.

[SophisticaSean]

@msaraiva This is preventing us from upgrading surface. This is a horrid bug that needs to be fixed ASAP. I can't use tables on Surface 0.5.0+ because of this bug.

[Zurga]

@SophisticaSean, why does this prevent you from upgrading Surface?

[v0idpwn]

I didn't manage to reproduce this issue. Could you provide an example?

[v0idpwn]

This is the code I wrote:

defmodule SurfaceTestWeb.UserLive.Index do
  use Surface.LiveView

  alias SurfaceBulma.Table

  data users, :list

  @impl true
  def mount(_params, _session, socket) do
    Process.send_after(self(), :duplicate_users, 1000)

    {:ok, assign(socket, :users, [%{name: "John", age: 9}])}
  end

  @impl true
  def render(assigns) do
    ~F"""
    <h1>Listing Users</h1>
    <Table data={user <- @users} id="1">
        <Table.Column label="name">{ user.name }</Table.Column>
        <Table.Column label="age">{ user.age }</Table.Column>
    </Table>
    """
  end

  @impl true
  def handle_info(:duplicate_users, socket) do
    duplicated =
      socket.assigns.users
      |> List.duplicate(2)
      |> List.flatten()

    Process.send_after(self(), :duplicate_users, 1000)

    {:noreply, assign(socket, users: duplicated)}
  end
end

I'm running master.

[Zurga]

The bug only occurs when the data has already been sorted. I was looking at a fix just now and figured that an internal flag that represents whether the data has been updated would maybe do the trick.

[Zurga]

@hadfieldn, @SophisticaSean I think the bug is fixed in master now, could you please confirm?

[SophisticaSean]

@Zurga I'll look today, thanks for looking at this so quickly. We use like 20 different instances of Bulma.Table and we have some pretty complicated tables. If master doesn't fix this I'll get a demo app to reproduce.

The architecture is as follows:

Parent component Users has child live component of UserReporting table which is the table in question.

On Surface 0.3+ and likewise with Bulma the UserReporting table doesn't change when the underlying data in the assigns changes, properly.

What's most odd about this is I can get some of the fields in the table to change. I experimented by adding a boolean column to the table, and the boolean value is derived from an arbitrary drop down menu in the UserReporting component. When that drop down changes the table updates only that column even if the rest of the table data has changed.

On Surface 0.2.1 and Bulma 0.1.0 the tables update correctly when the underlying data changes.

[SophisticaSean]

@Zurga I have confirmed this bug is now fixed in master, could you cut a release pretty please? :)

[SophisticaSean]

also, thanks so much for the quick fix! :)

[Zurga]

@SophisticaSean, you are welcome, it has been released.
If you find time to contribute to SurfaceBulma it would be appreciated :)

[SophisticaSean]

@Zurga do you guys have an open list of things you'd like done? I wouldn't mind tossing some time your way!

[Zurga]

@SophisticaSean, thanks that would be really nice! I created an issue with a wishlist: #23