GrammAcc

CacheMeIfYouCan - Small Library for Computed Assigns in LiveView

I created a hex package to provide a reusable abstraction for computed properties in LiveViews.

The specific use-case that was giving me a lot of trouble was a complex tabular data view with pagination, dynamic sort on any column, and multi-select filters.

The streamed table rows need to be refetched based on the page no, page size, sort, and the filters, and the total page count also needs to be computed from a db query based on the page size and filters.

The README and moduledoc for the package have a simplified example showing the same use-case.

The idea behind this library is to provide something that can achieve the same kind of automagical recomputation of memoized properties as React’s useMemo, but in a more structured way that will fit into the LiveView server-side state model.

Cached/computed assigns are defined with a @reactive_cache module attribute, which takes a keyword list of four keys:

use CacheMeIfYouCan.LiveViewCache

@reactive_cache [
  key: :user_list,
  deps: [:page_no, :page_size, :filters, :sort],
  default_value: [],
  cb: &get_users/1,
]

def get_users(socket) do
  stream_async(socket, :user_list, fn ->
    users =
      from(User)
      ...
      |> Repo.all()
    {:ok, users, reset: true}
  end)
end

Recomputation is triggered by the use of wrapper functions assign_cached/3 and assign_new_cached/3. These functions pass their arguments through to the corresponding functions in the Phoenix.Component module but they also bust the cache for any computed properties that depend on the assigned key.

For example, if we have the @reactive_cache defined above, and we use

def handle_params(%{"page_no" => page_no}, _uri, socket) do
  {:noreply, assign_cached(socket, :page_no, page_no)}
end

Then the :page_no will be assigned like normal, but the get_users/1 function will also be called and the :user_list stream will be recomputed in the background.

We also still have complete control over when we trigger a recomputation because we can use the regular Phoenix.Component.assign/3 to assign the :page_no without fetching users if we want to. This is useful for example if we had a polling event or something that updated an assign, but we only wanted to recompute during a specific lifecycle stage or based on a user interaction event.

The assign_new_cached/3 function has a bit more going on. This function wraps the Phoenix.Component.assign_new/3 call and passes on its arguments, but it also automatically sets the default value for any computed properties that depend on the key being assigned. So, if we used

def mount(_, _, socket) do
  socket
  |> assign_new_cached(:page_no, fn -> 1 end)
  |> assign_new_cached(:page_size, fn -> 25 end)
  |> assign_new_cached(:sort, fn -> :asc end)
  |> assign_new_cached(:filters, fn -> [] end)
end

Then the :user_list assign would be initialized to the default value in the @reactive_cache of [] and the get_users/1 function would be called to load the initial stream.

The assign_new_cached/3 function also checks to make sure that all of the deps are in the assigns before it triggers the computation, so it won’t run four times because we call it on four deps, and it also only runs the computation for the connected render. This works well for the common use-case of initializing state with async tasks on mount. And we still have the flexibility to initialize things however we need to by simply using the Phoenix.Component.assign_new instead and setting up everything manually.

To clarify the behavior of the assign_new_cached/3 function, the following are roughly equivalent:

Without assign_new_cached/3

  def mount(_, _, socket) do
    if connected?(socket) do
      socket
      |> assign_new(:page_no, fn -> 1 end)
      |> assign_new(:page_size, fn -> 25 end)
      |> assign_new(:filters, fn -> [] end)
      |> assign_new(:sort, fn -> :asc end)
      |> assign_new(:users_list, fn -> [] end)
      |> get_users()
    else
      socket
      |> assign_new(:page_no, fn -> 1 end)
      |> assign_new(:page_size, fn -> 25 end)
      |> assign_new(:filters, fn -> [] end)
      |> assign_new(:sort, fn -> :asc end)
      |> assign_new(:users_list, fn -> [] end)
    end
  end

With assign_new_cached/3

  def mount(_, _, socket) do
    socket
    |> assign_new_cached(:page_no, fn -> 1 end)
    |> assign_new_cached(:page_size, fn -> 25 end)
    |> assign_new_cached(:filters, fn -> [] end)
    |> assign_new_cached(:sort, fn -> :asc end)
  end

I tried to design the api in a way that would work with existing constructs, so if you’re already fetching data with async assigns/background tasks and you have some helper functions to wrap up the recompute task and run it during different event handlers, then it should be pretty easy to update the code to use this library and reduce the boilerplate.

I’m still in the process of refactoring my site with these patterns, so I haven’t pushed this into production yet. You can try it out if you’re interested, but keep in mind this hasn’t been battle-tested yet. I’m also still trying to figure out how to write tests for a LiveView that doesn’t have an endpoint and plug router set up.