Pedro Assunção - Software Developer

Autocomplete field in Phoenix Live View, Surface, and TailwindCSS

2022-04-25T19:43:23Z

I know it's a mouthful, but hear me out:

I've been looking for an autocomplete field that worked for my purposes (lookup in the database, not in memory, and support multiselect and the ability to limit the number of items a field could support.

Since it couldn't find it and being the dumb dev that i am, i obviously wrote my own. It's meant for Surface forms, but with a bit of tinkering you can make it work with plain LiveView.

defmodule MyProjectWeb.Live.Components.Autocomplete do
  @moduledoc """
  Autocomplete component to lookup a single item from the database
  """
  use MyProjectWeb, :surface_component

  alias Surface.Components.Form

  @doc """
  The form field name for the data that we are looking up
  """
  prop field_name, :atom, required: true

  @doc """
  The label of the field
  """
  slot default, required: true

  @doc """
  Currently selected values for the field
  """
  prop current_values, :map, default: %{}

  @doc """
  Suggestions that the user can select
  """
  prop suggestions, :list, required: true

  @doc """
  Add and remove events that will get triggered
  as user clicks on the suggestions or asks to
  remove one of the current values
  """
  prop add_event, :event, required: true
  prop remove_event, :event, required: true

  @doc """
  Maximum number of items this field allows for. Controls
  whether to show the search field or not.
  """
  prop max_items, :integer, default: 9_999_999

  @impl true
  def render(assigns) do
    assigns =
      assign(assigns, :suggestions, filter_existing(assigns.suggestions, assigns.current_values))

    ~F"""
    
      
        <#slot />
        
          
            {#for {id, title} <- @current_values}
              
                {title}
                
                  
                
              
            {/for}
          

          
            
            
              {#for {id, title} <- @suggestions}
                
                  {title}
                
              {/for}
            
          
        
        
      
    
    """
  end

  defp filter_existing(suggestions, current_values) do
    Enum.reject(suggestions, fn s -> Enum.member?(current_values, s) end)
  end
end

The gist of it is:

The current_values property accepts what the database object already contains in that field (probably a list of id's.
The suggestions property receives a map for which the key is the id of the suggestion and the value is the title/name to be displayed when suggesting.
The two events control what gets called when the user adds (i.e. clicks a suggestion) or removes (i.e. clicks remove on an existing item. These events will be controlled on the outside.
The max_items property defines at which point do we stop showing the search box for this field (i.e. the max number of selected items was reached).

The rest is pretty simple:

Whenever the user enters something in the search field, the form will get it's change event triggered and we only need to intercept that event based on whether we are asking for a completion or not. This is easy to achieve, for instance, like described next.

My form component contains this:

@impl true
  def handle_event(
        "change",
        %{
          "_target" => ["autocomplete_user"],
          "autocomplete_user" => query
        },
        socket
      ) do
    cond do
      String.length(query) < 2 ->
        {:noreply, assign(socket, :user_autocomplete_suggestions, [])}

      true ->
        suggestions =
          query
          |> Users.find()
          |> Enum.map(fn %{id: id, title: title} ->
            {id, title}
          end)

        {:noreply, assign(socket, :user_autocomplete_suggestions, suggestions)}
    end
  end

As you can see, the suggestions for that field get set as a list of tuples (as accepted on the autocomplete component) and those suggestions are passed in when we update state. Here's the render of the component:


  User

The users_autocomplete_values(@blog) is basically building the currently assigned user to the blog:

defp user_autocomplete_values(%{user_id: nil}), do: %{}
defp user_autocomplete_values(%{user: %{id: id, name: name}}),
    do: %{id => name}

As you can see, the function returns a map where the key is the id, and the value is the displayed name, as per what the component expects. Also, this is the case where you want to autocomplete only one value. Here's an example function for more than one:

defp user_autocomplete_values(%{users: users}) do
  users
  |> Enum.map(fn %{id: id, name: name} ->
    {id, name}
  end)
  |> Map.new()
end

Here the blog would have multiple users. Maybe not the best practical example, but you get the idea of how that current_values property can be built.

Finally, we only need to implement the add and remove functions on the form component (or live view). For a single item autocomplete something like this would work:

@impl true
def handle_event("add_user", %{"id" => id} = _event, socket) do
  validate_and_save(
    %{"blog" => %{"user_id" => id}},
    assign(socket, :user_autocomplete_suggestions, [])
  )
end

@impl true
def handle_event("remove_user", %{"id" => _id} = _event, socket) do
  validate_and_save(%{"blog" => %{"user_id" => nil}}, socket)
end

And if you wanted to support multiple users, something like this should do the trick:

@impl true
def handle_event("add_user", %{"id" => id} = _event, socket) do
  existing_user_ids = Enum.map(socket.assigns.customer.users, & &1.id)

  validate_and_save(
    %{"customer" => %{"customer_users" => [id | existing_user_ids]}},
    assign(socket, :users_autocomplete_suggestions, [])
  )
end

@impl true
def handle_event("remove_user", %{"id" => id} = _event, socket) do
  existing_user_ids = Enum.map(socket.assigns.customer.users, & &1.id)
  new_user_ids = List.delete(existing_user_ids, String.to_integer(id))

  validate_and_save(
    %{"customer" => %{"customer_users" => new_user_ids}},
    assign(socket, :users_autocomplete_suggestions, [])
  )
end

Happy coding!

Elixir/Phoenix VSCode snippets

2021-02-23T15:54:26Z

Here's my current Elixir VSCode snippets elixir.json file.

You can add it to VSCode by Ctrl/Cmd+Shift+P and choosing Preferences : Configure User Snippets, then opening elixir.json. If you don't have one yet, you can create a new snippet file in the same place.

Supported snippets:

gs: GenServer
gscast: GenServer Cast Function
gscall: GenServer Call Function
lv: Phoenix LiveView
lvc: Phoenix LiveComponent
lvhe: Phoenix LiveView Handle Event Function
lvhi: Phoenix LiveView Handle Info Function

Hope that's useful, here's the file:

{
    "My GenServer": {
        "prefix": "gs",
        "body": [
            "defmodule ${4:package}.${1:name} do",
            "\tuse GenServer",
            "\trequire Logger",
            "",
            "\t@me __MODULE__",
            "",
            "\tdef start_link(${2:opts}) do",
            "\t\t{:ok, pid} = result = GenServer.start_link(@me, ${2:opts}, name: @me)",
            "\t\tLogger.debug(\"#{@me} GenServer started with# #{inspect(pid)}.\")",
            "\t\tresult",
            "\tend",
            "",
            "\tdef init(${3:initial_state}) do",
            "\t\t{:ok, ${3:initial_state}}",
            "\tend",
            "",
            "\t$0",
            "end"
        ],
        "description": "My GenServer"
    },
    "GenServer Cast": {
        "prefix": "gscast",
        "body": [
            "def ${1:function}() do",
            "\tGenServer.cast(@me, :${1:function})",
            "end",
            "",
            "${0}"
        ],
        "description": "GenServer cast function"
    },
    "GenServer Call": {
        "prefix": "gscall",
        "body": [
            "def ${1:function}() do",
            "\tGenServer.call(@me, :${1:function})",
            "end",
            "",
            "${0}"
        ],
        "description": "GenServer call function"
    },
    "LiveViewLiveComponent": {
        "prefix": "lvc",
        "body": [
            "defmodule ${1:module} do",
            "\t@moduledoc \"\"\"",
            "\t${2:module_doc}",
            "\t\"\"\"",
            "\tuse Phoenix.LiveComponent",
            "",
            "\t@impl true",
            "\tdef update(_assigns, socket) do",
            "\t\t{:ok, socket}",
            "\tend",
            "",
            "\t@impl true",
            "\tdef render(assigns) do",
            "\t\t~L\"\"\"",
            "\t\t${0}",
            "\t\t\"\"\"",
            "\tend",
            "end",
        ]
    },
    "LiveView": {
        "prefix": "lv",
        "body": [
            "defmodule ${1:module} do",
            "\t@moduledoc \"\"\"",
            "\t${2:module_doc}",
            "\t\"\"\"",
            "\tuse Phoenix.LiveView",
            "",
            "\t@impl true",
            "\tdef mount(_params, _session, socket) do",
            "\t\t{:ok, socket}",
            "\tend",
            "",
            "\t@impl true",
            "\tdef handle_params(_params, _url, socket) do",
            "\t\t{:noreply, socket}",
            "\tend",
            "",
            "\t@impl true",
            "\tdef render(assigns) do",
            "\t\t~L\"\"\"",
            "\t\t${0}",
            "\t\t\"\"\"",
            "\tend",
            "end",
        ]
    },
    "LiveViewHandleEvent": {
        "prefix": "lvhe",
        "body": [
            "@impl true",
            "def handle_event(\"${1:event}\", %{\"${2:var}\" => ${2:var}} = _event, socket) do",
            "\t${0}",
            "\t{:noreply, socket}",
            "end"
        ]
    },
    "LiveViewHandleInfo": {
        "prefix": "lvhi",
        "body": [
            "@impl true",
            "def handle_info(${1:event}, socket) do",
            "\t${0}",
            "\t{:noreply, socket}",
            "end"
        ]
    }
}

Happy Elixir'ing

Allow Erlang/Elixir to open ports 80 and 443

2021-02-16T12:44:56Z

By default users other than root cannot open ports below 1000, for security reasons. If you want to - say - run your website in Elixir without nginx on port 80 or 443, you can allow the Erlang binary to open ports below 1000 using setcap (run as root):

setcap 'cap_net_bind_service=+ep' /erts-11.1/bin/beam.smp

Manjaro 5.10 Kernel will not boot

2021-01-12T16:13:47Z

If - like me - you get stuck on boot after Manjaro updates to Linux Kernel 5.10, the solution is pretty simple:

Boot into 5.9 (you can choose the option in the grub boot menu
Reinstall the 5.10 kernel with:
```
sudo pacman -S linux510
```
For good measure, reinstall the Nvidia driver (if you have an Nvidia card, that is) with:
```
sudo pacman -S linux510-nvidia
```

After that, the 5.10 kernel should boot.

Automatic enum values conversion in Elixir

2020-11-18T19:48:25Z

One annoying detail about web forms is that on submission (unless you are using changesets) all the values come back as strings. This forces you to have to handle the correct formats before, say, passing those params into a service module to execute some action.

To simplify this process, i recently created a simple guesser function that evaluates the values of a map, namely booleans, integers, floats, dates, and datetimes. It is recursive and can go into lists as well. Check the examples:

  @doc """
  Function to try to guess the type of a variable and return the guessed value. Some
  applications might include converting a parameter map coming from a form (all strings)
  into a proper map with typed values, for instance:
       %{foo: "123", bar: "true", foobar: "2020-12-13"}
  would become:
       %{foo: 123, bar: true, foobar: ~D[2020-12-13]}
  The function supports simple values (a string, for instance), is also recursive into
  lists and maps and, if it can't figure out the type, it returns the original value.
  Will also trim the values before testing so `" 123"`, for instance, becomes `123`.
  ## Examples
  ## Simple types
      iex> to_typed("")
      ""
      iex> to_typed("123")
      123
      iex> to_typed(" 456")
      456
      iex> to_typed("-123")
      -123
      iex> to_typed("123.345")
      123.345
      iex> to_typed("-12.3")
      -12.3
      iex> to_typed("true")
      true
      iex> to_typed("  true  ")
      true
      iex> to_typed("false")
      false
      iex> to_typed("2020-12-13")
      ~D[2020-12-13]
      iex> to_typed("2015-01-23T23:50:07Z")
      ~U[2015-01-23 23:50:07Z]
      iex> to_typed("2015-01-23T23:50:07.123+02:30")
      ~U[2015-01-23 21:20:07.123Z]
  ## Maps
      iex> to_typed(%{})
      %{}
      iex> to_typed(%{another_integer: "5345345435"})
      %{another_integer: 5345345435}
      iex> to_typed(%{another_map: %{foo: "true"}})
      %{another_map: %{foo: true}}
      iex> to_typed(%{a_list: ["foo", "true"]})
      %{a_list: ["foo", true]}
  ## Lists
      iex> to_typed([])
      []
      iex> to_typed(["123"])
      [123]
      iex> to_typed(["12.3"])
      [12.3]
      iex> to_typed(["true", "false"])
      [true, false]
      iex> to_typed(["true", ["false"]])
      [true, [false]]
      iex> to_typed([%{foo: "1"}, %{foo: "2.5"}])
      [%{foo: 1}, %{foo: 2.5}]
      iex> to_typed(["bla", "bla", "2015-01-23T23:50:07Z", ["12345", %{cool: "true"}]])
      ["bla", "bla", ~U[2015-01-23 23:50:07Z], [12345, %{cool: true}]]
  ## Other
      iex> to_typed(nil)
      nil
      iex> to_typed(123)
      123
      iex> to_typed("actually_a_string")
      "actually_a_string"
  """
  @spec to_typed(any()) :: any()
  def to_typed(map) when is_map(map) do
    map
    |> Enum.map(fn {key, value} ->
      value =
        cond do
          is_map(value) -> to_typed(value)
          is_list(value) -> to_typed(value)
          true -> to_typed(value)
        end

      {key, value}
    end)
    |> Map.new()
  end

  def to_typed(list) when is_list(list) do
    Enum.map(list, fn value ->
      cond do
        is_map(value) or is_list(value) -> to_typed(value)
        is_binary(value) -> to_typed(value)
        true -> value
      end
    end)
  end

  def to_typed(value) when is_binary(value) do
    value = String.trim(value)

    cond do
      value == "true" ->
        true

      value == "false" ->
        false

      value =~ ~r/\A\d{4}-\d{2}-\d{2}\z/ ->
        value |> Timex.parse!("{ISOdate}") |> Timex.to_date()

      value =~ ~r/\A\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}/ ->
        value |> Timex.parse!("{ISO:Extended}") |> Timex.to_datetime()

      value =~ ~r/\A-?\d+\.\d+\z/ ->
        String.to_float(value)

      value =~ ~r/\A-?\d+\z/ ->
        String.to_integer(value)

      true ->
        value
    end
  end

  def to_typed(value), do: value

Hope you find it useful.

Happy Elixir'ing...

Linux window auto-organizer (across multiple screens)

2020-09-25T10:55:54Z

One of the things that always makes me crazy is window organization on the desktop. OSX has pretty good apps to manage windows, but i always find Linux a bit lacking so i decided to roll out my own simple solution.

It's written in Elixir because i like it, but can easily be adapter for other languages since it uses wmctrl to get information about windows and define their positions. The rest is just find the windows roughly by name and assigning the positions and dimensions i want. And it works across multiple screens because apparently X11 reports positions as one single virtual screen if you are not mirroring your screens, of course.

Just put the script in a directory that your PATH contains, and don't forget to change the first line to point to the correct elixir binary path. Then you can just execute whenever you want and all your windows will pop into their positions automagically.

Happy windowing...

EDIT: Updated script to not blow up when a particular window is not open.

#!/home/void/.asdf/shims/elixir

require Logger

windows = %{
  opera: %{x: 3408, y: 0, w: 1712, h: 1403},
  terminal: %{x: 0, y: 0, w: 1584, h: 1371},
  thunderbird: %{x: 6045, y: 200, w: 995, h: 1051},
  jetbrains: %{x: 2560, y: 0, w: 2060, h: 1373},
  slack: %{x: 5120, y: 200, w: 1184, h: 1050},
  spotify: %{x: 1592, y: 0, w: 968, h: 1373}
}

defmodule WindowGatherer do
  def run(windows) do
    IO.inspect("Gathering windows...")

    {window_lines, 0} = System.cmd("wmctrl", ["-l", "-p", "-G", "-x"])
    window_lines = window_lines
    |> String.split("\n")
    |> Enum.reject(&(String.split(&1) == []))
    |> Enum.map(fn line ->
      [id, _, _, _, _, _, _ | rest] = String.split(line)
      %{
        id: id,
        names: rest |> Enum.join(" ") |> String.downcase()
      }
    end)

    fill_ids(windows, window_lines)
  end

  defp fill_ids(windows, window_lines) do
    windows
    |> Enum.map(fn {window_key, window_data} ->
      window_attributes = window_lines
        |> Enum.filter(&(&1.names =~ Atom.to_string(window_key)))
        |> Enum.reject(&is_nil/1)
        |> Enum.at(0)
      case window_attributes do
        map when is_map(window_attributes) ->
          {window_key, Map.put(window_data, :id, Map.fetch!(map, :id))}
        _ -> nil
      end
    end)
    |> Enum.reject(&is_nil/1)
    |> Map.new()
  end
end

defmodule WindowOrganizer do
  def run(windows) do
    IO.inspect("Organizing windows...")

    windows
    |> Enum.each(fn {key, win} ->
      IO.inspect("Moving #{key}...")
      System.cmd("wmctrl", [
        "-ir",
        win.id,
        "-e",
        "0,#{win.x},#{win.y},#{win.w},#{win.h}"
      ])
    end)
  end
end

windows
|> WindowGatherer.run()
|> WindowOrganizer.run()

How to download files from Google Drive using Elixir

2020-07-24T20:29:19Z

The documentation around downloading a file from a Google Drive account is a bit spread out, so i figured i could make a mini tutorial on how to do this.

The scenario is having a CSV file in a folder on my Google Drive and being able to read it from Elixir. Here's the setup:

Setup a service account using the Google Developer Console Dashboard (there are plenty tutorials on the web how to setup service accounts), and save the .json credentials file in your Elixir project somewhere.

Make sure the service account has access to all accounts in your domain (unsure this step is necessary, TBH).

The service account will have an email associated with it (something along the lines of service_account_name@yourproject.iam.gserviceaccount.com). Share the folder you want to read the files from with that email in your Google Drive interface.

Now we are ready to move to Elixir.
Install the following two dependencies in mix.exs:

{:google_api_drive, "~> 0.15.0"},
{:goth, "~> 1.2.0"},

Configure goth to use your .json credentials file in config.exs (you can also do it programmatically, just look at goth's docs):

config :goth,
  json: “google_service_account.json” |> File.read!

Finally, the following snippet will take the first CSV file it finds and read its contents:

{:ok, %{token: token}} = Goth.Token.for_scope("https://www.googleapis.com/auth/drive")

conn = GoogleApi.Drive.V3.Connection.new(token)

{:ok, %{files: files} = file_list} = GoogleApi.Drive.V3.Api.Files.drive_files_list(
  conn,
  includeItemsFromAllDrives: true,
  supportsAllDrives: true,
  corpora: "allDrives"
)

[first | _rest] = files 
  |> Enum.filter(&(&1.mimeType == "text/csv"))
  |> Enum.map(&(Map.take(&1, [:id, :name])))

{:ok, %{body: body}} = GoogleApi.Drive.V3.Api.Files.drive_files_get(
  conn,
  first.id,
  [
    mimeType: "text/csv",
    alt: "media"
  ],
  [
    decode: false
  ]
)

body

Happy Elixir'ing

Elixir/Phoenix deployments using Github Actions

2020-07-23T16:00:37Z

One of the trickiest parts of getting Elixir services into production is the deployment. Common approaches include using Docker to generate containers that you can then deploy to AWS/Google/Azure, a Kubernetes cluster, or running the creation of the deployment locally (mix releases) and then publishing the finalised version to the target machine.

For my website https://pedroassuncao.com i decided to go with a simpler approach: Instead of building the final product in a local machine, creating a package (container or otherwise), and then deploying it to my host, i chose to do everything in the target system instead, by leveraging Github Actions.

5 Euro if you can guess what noozo means…

This approach has the following advantages:

Migrations don’t require a separate module to run (mix is available in the target system).
Deployment is fast due to cached dependencies on the target system and a simple SSH command running everything at once.
Slack notifications are super easy to integrate into Github actions and they are a fantastic way to keep track of deployment status.
Push and forget strategy for deployment is super easy.
No Docker and all its configuration mess.

Here's how i do it:

On my host (a simple Linode node) i installed Elixir, Erlang, NodeJS and the rest of the dependencies for any Elixir/Phoenix project. This has the disadvantage of having to manually upgrade their versions, but i can live with that by using asdf to manage them. I then proceeded to clone my repo into a folder on the host, where i will build, release, and control the service. This is done once, and has the advantage of caching dependencies directly on the target, which speeds up the deployment process.

Then, every commit i push to master (my code lives on Github, obviously), is caught by the following action:

name: Deploy

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  test_and_deploy:
    runs-on: ubuntu-latest

steps:
  - name: Slack Notification (Start)
    env:
      SLACK_BOT_TOKEN: ${{ secrets.slack_bot_token }}
    uses: pullreminders/slack-action@master
    with:
      args: '{\"channel\":\"@nocivus\",\"text\":\"Starting website deployment...\"}'

  - name: Deploy To Linode
    uses: appleboy/ssh-action@master
    with:
      host: pedroassuncao.com
      username: 
      key: ${{ secrets.ssh_key }}
      port: 22
      script_stop: true
      script: |
        echo "Sourcing nvm..."
        . /home/deploy/.nvm/nvm.sh
        echo "Pulling code..."
        cd noozo_v2/pedroassuncao.com
        git submodule update --remote
        git pull --recurse-submodules origin master
        echo "Updating mix deps..."
        mix deps.get --only prod
        echo "Setting up secrets..."
        rm config/prod.secret.server.exs
        ln -s ~/prod.secret.exs config/prod.secret.server.exs
        echo "Compiling..."
        MIX_ENV=prod mix compile
        echo "Setting up assets..."
        npm install --prefix assets
        npm run deploy --prefix assets
        MIX_ENV=prod mix phx.digest
        echo "Releasing..."
        MIX_ENV=prod mix release --overwrite
        MIX_ENV=prod mix ecto.migrate
        echo "Stopping server..."
        _build/prod/rel/noozo/bin/noozo stop
        sleep 5
        echo "Starting server..."
        _build/prod/rel/noozo/bin/noozo daemon
        echo "All done."

  - name: Slack Notification (Success)
    if: success()
    env:
      SLACK_BOT_TOKEN: ${{ secrets.slack_bot_token }}
    uses: pullreminders/slack-action@master
    with:
      args: '{\"channel\":\"@nocivus\",\"text\":\"Website successfuly deployed :rocket:\"}'

  - name: Slack Notification (Fail)
    if: failure()
    env:
      SLACK_BOT_TOKEN: ${{ secrets.slack_bot_token }}
    uses: pullreminders/slack-action@master
    with:
      args: '{\"channel\":\"@nocivus\",\"text\":\"Website failed to deploy :dizzy_face:\"}'

As you might have noticed, i use Github secrets to inject the Slack webhooks and also the SSH key to connect to my target machine.

I'm pretty happy with this solution so far, however it's not without its flaws:

By not using restart the website is down for 5–10 seconds every deployment (there's probably a way around that, but last i tried it didn't work very well when the mix.exs version changes).
Elixir/Erlang/NodeJS versions need to be manually upgraded on the target host.

Let me know if there's anything i can improve, would love to hear your thoughts!

Happy Elixir'ing

Integrating vis.js with Phoenix Live View

2020-07-23T14:25:13Z

One of the projects here at Drover required us to show a directed graph representation of a flow that happens inside that service and, after looking into various alternatives, we settled on https://visjs.org/.

Since this project has a Phoenix LiveView back-office, I had to figure out how to integrate the graph drawing mechanism into the LV and the way we ended up doing that was by using the hooks mechanism to inject the data into vis.js and draw the graph after the view was mounted.

The Live View

defmodule OutstandingLittleServiceWeb.Diagrams.ShowView do
  @moduledoc “””
  Shows a particular diagram
  “””
  use OutstandingLittleServiceWeb, :live_view
  alias OutstandingLittleService.Data
  alias OutstandingLittleService.Utils

  def render(assigns) do
    ~L”””
    <%= if @loading do %>
      Loading information…

    <% else %>
      <%= @diagram.name %>

      <%= @diagram.uuid %>

      <%= @diagram.description %>

                 style=”width:800px; height:400px”
           phx-hook=”Diagram”
           data-diagram-data=”<%= Poison.encode!(Utils.diagram_to_json(@diagram)) %>”>

      
    <% end %>
    “””
  end

  def mount(_params, _session, socket) do
    {:ok, assign(socket, loading: true)}
  end

  def handle_info({:load_diagram, params}, socket) do
    diagram = Data.get_diagram!(params[“id”], eager_load: true)

    {:noreply,
     assign(socket,
     loading: false,
     diagram: diagram
    )}
  end

  def handle_params(params, _uri, socket) do
    send(self(), {:load_diagram, params})
    {:noreply, assign(socket, loading: true)}
  end
end

As you can see, it’s a pretty standard LV in which i add the phx-hook “Diagram” to the diagram div and also inject the JSON structure i want as a data attribute. Utils.diagram_to_json is merely a helper function that knows how to convert a diagram to a JSON representation that vis.js can use.

LiveView hooks

On app.js i then define the hook that will inject the data and initialise the graph:

import css from “../css/app.css”
import “phoenix_html”

import { Socket } from “phoenix”
import LiveSocket from “phoenix_live_view”
import diagramInit from “./diagram”

let csrfToken = document.querySelector(“meta[name=’csrf-token’]”)
 .getAttribute(“content”)

let Hooks = {}
Hooks.Diagram = {
  mounted() {
    let data = this.el.getAttribute(“data-diagram-data”)
    diagramInit(JSON.parse(data))
  }
}

let liveSocket = new LiveSocket(
  “/live”,
  Socket, {
    hooks: Hooks,
    params: {
      _csrf_token: csrfToken
    }
  }
)
liveSocket.connect()

Initialising the graph

Finally on diagram.js the graph gets initialised:

import { DataSet, Network } from ‘vis/index-network’;

function getOptions() {
  // Return vis.js options here, like layout, physics, etc
  // Ommited for brevity
}

function addNode(nodes, id, label, description, result = null) {
  nodes.push({
    id: id,
    label: “” + label + “”,
    description: description
  })
  return nodes
}

function addLink(links, id, start_id, end_id, label = null) {
  links.push({
    id: id,
    from: start_id,
    to: end_id,
    arrows: “to”,
    physics: “false”,
    label: “” + label + “”
  })
  return links
}

function diagramInit(data) {
  let diagram = data

  // Setup data
  let nodes = []
  diagram.components.forEach(component => {
    nodes = addNode(nodes, component.id, component.name, component.description, component.result)
  })

  // Setup links
  let links = []
  diagram.links.forEach(link => {
    links = addLink(links, link.id, link.start_component_id, link.end_component_id)
  })

  // Setup graph
  let container = document.getElementById(‘diagram’)
  let data = { nodes: nodes, edges: links }
  new Network(container, data, getOptions())
}

export default diagramInit

Notes

Vis is added to the project using “npm install vis”, which will add the entry to the package.json file for you.
Some code on the diagram.js file is obviously specific to my case, namely the links between the diagram components, which are used to tell vis how to connect things, but it boils down to adding the nodes each with a different id, and then telling vis the start and end id for each connection.
As always, your mileage may vary.

Final thoughts

Hopeful by now you should have a good idea how to integrate external JS libraries and make them work with LiveView. It’s basically just figuring out how to plug them into the JS hooks mechanism and pass the adequate data between them.

There are other ways to pass the data, data attributes was just the way that seemed the easiest. But you could probably also use events between JS and the LV to accomplish the same goal, or other strategies.

Happy Elixir'ing!

Integrating vis.js with Phoenix Live View was originally published in Drover Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

OpenApiSpex with mix releases not working

2020-06-25T10:22:07Z

OpenApiSpex is an Elixir lib to provide OpenAPI documentation for your Phoenix web application. The way it works is you annotate the controller functions with @doc statements where you specify what the request and responses should look like.

There is currently an issue with the lib where it relies on the documentation being available inside the compiled BEAM files at runtime which - if you use mix release - by default is not. This makes any requests to your entry points return a cryptic :chunk_not_found error. The reason is the documentation "chunk" inside your controller compiled file is not there (i.e. it was striped when mix release ran).

The workaround for this right now is to pass strip_beams: false in the mix release configuration in your iex.exs file:


  def project do
    [
      ...
      releases: releases()
    ]
  end

  defp releases() do
    [
      prod: [
        include_executables_for: [:unix],
        include_erts: true,
        strip_beams: false,
        quiet: false
      ]
    ]
  end

The only issue with this approach right now is that it will add a fair bit to your final package size (around 25MB extra in my 72MB project).

There is work in progress in the mix release process to allow more granular control over what gets stripped from the compiled files, which will allow us in the future to strip everything except, for instance, documentation (which is only 1 or 2MB).

Happy BEAMing