Ideas on patterns for more complex Kino components

[venkatd]

Hi, we have an internal tool for visual snapshot testing that operates within a Kino notebook. I was wondering what sort of patterns are recommended when developing more complex UIs. Here's a screenshot:

It's got a lot of interactions going on such as:

• Displaying realtime updates as tests are running
• Filtering
• Approve/reject UX

I've implemented some hacks to have a maintainable model to keeping this under control. Here's a snippet of our server:

defmodule SnapUnit.Server do
  use GenServer, restart: :temporary

  alias SnapUnit.TestSuite
  alias SnapUnit.Test
  alias SnapUnit.Filters

  @render_debounce 100

  defstruct [
    :frame,
    :test_suite,
    :selected_test,
    :status,
    :filters,
    :render_timer
  ]

  def start_link(opts) do
    GenServer.start_link(__MODULE__, opts)
  end

  def run(server),
    do: GenServer.cast(server, :run_tests)

  def tests(server),
    do: GenServer.call(server, :tests)

  def read_selected_test(server),
    do: GenServer.call(server, :read_selected_test)

  def init(opts) do
    frame = Kino.Frame.new(placeholder: false)
    Kino.render(frame)

    test_suite = Keyword.fetch!(opts, :test_suite)

    {:ok,
     %__MODULE__{
       frame: frame,
       test_suite: test_suite,
       selected_test: nil,
       status: :idle,
       filters: %Filters{}
     }, {:continue, :render}}
  end

  def handle_continue(:render, state) do
    {:noreply, schedule_render(state)}
  end

  def handle_call(:tests, _from, %__MODULE__{test_suite: test_suite} = state) do
    {:reply, TestSuite.tests(test_suite, Filters.all()), state}
  end

  def handle_call(:read_selected_test, _from, %__MODULE__{test_suite: test_suite} = state) do
    {:reply, TestSuite.get_test(test_suite, state.selected_test), state}
  end

  def handle_cast(:run_tests, %{status: :running} = state) do
    {:noreply, state}
  end

  def handle_cast(:run_tests, %__MODULE__{filters: filters} = state) do
    new_state = %{state | status: :running}

    tests_to_run = TestSuite.tests(new_state.test_suite, filters)

    stream =
      Task.Supervisor.async_stream_nolink(
        SnapUnit.TaskSupervisor,
        tests_to_run,
        fn test ->
          TestSuite.run_single_test(new_state.test_suite, test.name)
        end,
        max_concurrency: 5,
        timeout: 2 * 60 * 1000,
        ordered: false,
        on_timeout: :kill_task
      )

    server_pid = self()

    spawn_link(fn ->
      for result <- stream do
        GenServer.cast(server_pid, {:test_result, result})
      end

      GenServer.cast(server_pid, :all_done)
    end)

    {:noreply, schedule_render(new_state)}
  end

  def handle_cast({:test_result, {:ok, %Test{} = updated_test}}, state) do
    new_suite = TestSuite.merge_test(state.test_suite, updated_test)

    new_state = %{state | test_suite: new_suite}
    {:noreply, schedule_render(new_state)}
  end

  def handle_cast({:test_result, {:exit, _reason}}, state) do
    {:noreply, state}
  end

  def handle_cast(:all_done, state) do
    new_state = %{state | status: :idle}
    {:noreply, schedule_render(new_state)}
  end

  def handle_info({:update_test_group, %{type: :change, value: group}}, state) do
    new_state = %{state | filters: %{state.filters | group: group}}
    {:noreply, schedule_render(new_state)}
  end

  def handle_info({:update_test_status, %{type: :change, value: status}}, state) do
    new_state = %{state | filters: %{state.filters | status: status}}
    {:noreply, schedule_render(new_state)}
  end

  def handle_info({{:view, test_name}, _}, state) do
    {:noreply, schedule_render(%{state | selected_test: test_name})}
  end

  def handle_info({{:approve, test_name}, _}, state) do
    new_suite = TestSuite.approve(state.test_suite, test_name)
    {:noreply, schedule_render(%{state | test_suite: new_suite})}
  end

  def handle_info({{:clear_expected_actual, test_name}, _}, state) do
    new_suite = TestSuite.clear_expected_actual(state.test_suite, test_name)
    {:noreply, schedule_render(%{state | test_suite: new_suite})}
  end

  def handle_info({{:rerun, test_name}, _}, state) do
    new_test = TestSuite.run_single_test(state.test_suite, test_name)
    new_suite = TestSuite.merge_test(state.test_suite, new_test)
    {:noreply, schedule_render(%{state | test_suite: new_suite})}
  end

  def handle_info(:render, state) do
    # Actually render
    do_render(state)

    # Clear out the timer reference, since we're done.
    new_state = %{state | render_timer: nil}
    {:noreply, new_state}
  end

  def handle_info({:run_tests, _}, state) do
    GenServer.cast(self(), :run_tests)
    {:noreply, state}
  end

  defp schedule_render(%__MODULE__{render_timer: nil} = state) do
    # No pending timer, so set one
    ref = Process.send_after(self(), :render, @render_debounce)
    %{state | render_timer: ref}
  end

  defp schedule_render(state) do
    # If you want to debounce, you can cancel the old timer and set a new one:
    Process.cancel_timer(state.render_timer)
    ref = Process.send_after(self(), :render, @render_debounce)
    %{state | render_timer: ref}
  end

  defp do_render(%__MODULE__{
         test_suite: %TestSuite{} = test_suite,
         selected_test: selected_test_name,
         frame: frame,
         status: status,
         filters: filters
       }) do
    Kino.Frame.render(
      frame,
      SnapUnit.UI.build(%{
        test_suite: test_suite,
        status: status,
        selected_test: selected_test_name,
        filters: filters
      })
    )
  end
end

What I find is that, modeling it like React makes things manageable. This means:

• Component events (button click, etc) bubble up to the GenServer
• We update the state and re-render the UI (Kino components) to a Kino.Frame liberally. It's not very performant so the best workaround I found was to debounce re-renders to ~100ms.

My question is: are there better patterns for implementing this? Perhaps something to make this pattern easier could exist inside of Kino? Perhaps something Kino inspired or Liveview inspired?

[josevalim]

That's typically the pattern we follow (or we do it in JS). If you want something a bit more structure, take a look at Kino.Screen: https://hexdocs.pm/kino/Kino.Screen.html

[venkatd]

Ah this is great. I had not heard of Kino.Screen not sure how I missed it. Thanks!