Recently, I tried to learn some low-level system programming stuff. I am a Mac user, and I thought that everything that works on Linux should also work on Mac. After all, Mac is a Unix-based system 😊. I guess we all heard this. Oh boy! I was mistaken. After attempting to run a few programs, I realized I was wrong.

Below are a few points that restrict you from implementing system programming stuff on Mac.

• Kernel Mismatch: macOS ≠ Linux

• macOS doesn't have the procfs or sysfs filesystems used heavily for interacting with kernel objects.

• System programming, it requires a GCC toolchain, which you’d need to install using cross-compilation tools, and it comes at a price.

These points suggest that doing system programming on macOS is not easy. Most of the necessary tools are not available on the system. You can either use virtual machines or Docker, but these options come with some performance costs. After some research, I found a tool called Multipass.

What is Multipass?

Multipass is a super simple way to run an actual Ubuntu Linux VM on your Mac, without the usual “VM setup headache”. You install Multipass, run one command, and you get a clean Ubuntu machine in seconds. It’s made by Canonical (the Ubuntu guys), so the experience feels very “Ubuntu native” instead of a random virtual machine tool.

Using Multipass, you keep your Mac as your main workstation (terminal, editor, browser, notes, etc.), but all the “Linux-only” work happens inside the Ubuntu VM. So you can install gcc, make, gdb/lldb, kernel headers, compile C programs, and build/load kernel modules (inside the VM). For learning system programming, this is almost the best of both worlds, i.e., Mac + Linux.

How to Install multipass?

• Open a search engine of your choice and run a search for “multipass”. Open the first result and search that will open Ubuntu documentation in that page, search (using cmd + f) for Install Multipass Or go to this url.

• Either you can download the installer or you can install using brew.

• Installing through the installer is very straightforward, and to install using brew, you need to run brew install multipass. It will take a couple of minutes to install.

• Now, to confirm if it’s been install you need to run multipass In the terminal, you will see a bunch of helper commands, something like below

  

• Now, we know that it is a lightweight virtual manager, which is currently empty, and we need to install an instance.

• To do so, we need to run the command in the terminal multipass shell . It will take some time to create an instance named primary . It will install a Ubuntu virtual machine.

• After some time, when it is done, the prompt will end, and then we need to enter the shell by running multipass shell primary . We will then be inside the Ubuntu virtual machine, and we will be able to see the screen like below

  

How to connect Multipass with Visual Studio Code?

Now that our multishell is ready, you can see it is just an terminal based ubuntu system, and we don’t have gui to interact with. We can’t install VS Code inside it to access the environment. So, to harness the power of the Ubuntu environment, we need to connect VS Code on our Mac system to the Ubuntu system. We need to follow the steps below.

• Inside the Ubuntu terminal, run the following command: sudo vim /etc/ssh/sshd_config And we will make some changes in the config file to make password-based login into the system.

• Inside the file, find “KbdInteractiveAuthentication no” and change it to yes something like this KbdInteractiveAuthentication yes .

• Now, since we made the changes in the system, we will reload the daemon to see the effect of the changes made. To do so, run the command sudo systemctl daemon-reload .

• Next, we will run sudo service ssh restart so that a remote ssh connection can be made.

• Now, we will reset the password of the instance i.e ubuntu .(Note: ubuntu@primary What we can see in the prompt here ubuntu is the system name and primary the user name). Also, remember this password as it will be used to connect our VS Code with this Ubuntu instance.

• We will run the command sudo passwd ubuntu . It will ask to enter and re-enter the password.

• Now, open the Vs code and move to the Extensions tab and search for “remote development” and install the first result.

• 

• After installing this extension, you’ll be able to see a computer-like icon below the Extension button in VS Code. It is nothing but the “Remote Development” extension. Click on that, and it will open a panel with a list of SSH But it will be empty since we have just installed the extension.

  

• Click on the “+” button in the SSH section, and it will open an input box where we will enter ubuntu@192.168.2.2 (192.168.2.2 is the ip address of our Ubuntu instance, which we can get by running the command hostname -I in the ubuntu@primary terminal).

  

• Press Enter twice, and now you will be able to see an entry under SSH section with the name of ip address, i.e., 192.168.2.2.

• Now, click on the entry inside the SSH list, and you’ll see a prompt to enter the password. Enter the same password you added for the Ubuntu system.

  

• Now, this will connect our VS Code with the Ubuntu instance. To confirm this, create a directory inside the Ubuntu machine, say test , and inside the vscode click the “Open Folder” button, and you will see the test directory listed in the folders list. This confirms that our VS Code and Ubuntu instance are connected.

• 

• Next, we will run some sample C code.

Writing and running a sample C program in a multipass environment?

Now we know how to connect our VS Code with the Multipass environment. We will now run a sample C program to complete the motive of this blog. For this, we need to install gcc to run C/C++ programs. We can install gcc by running sudo apt install build-essential in ubuntu shell. This will install the gcc program. We can confirm if its install by running gcc —version.
Finally, we can create a sample hello_world.c C file in the test folder we created earlier in the Ubuntu instance by running touch hello_world.c or simply in the VS Code. You can see the file in the SSH section of VS Code, something like this.

Add the following small code snippet to it

#include <stdio.h>

int main() {
    printf("Hello, World\n");
    return 0;
}

And finally, we can compile the program through the Ubuntu terminal by running gcc hello_world.c and then by running ./a.outIt will print the result in the terminal.

Conclusion

Multipass is the easiest way to get a clean Ubuntu Linux environment on macOS without changing your main setup. It keeps your Mac workflow intact while giving you real Linux tools and behavior, which is perfect for system programming.

I hope you like this blog on installing and setting up Multipass. If you have any questions, please comment below. Thanks for reading 😊.

NOTE: If you wish to learn C/C++ and System Programming in great detail. You can connect and take training from Bhavith Achar, who is the founder and creator of e-grasp.com. He is an excellent C/C++ Engineer and a teacher, and I have taken System Programming training from him.

While working on a Nestjs project, I encountered a weird problem related to the database column. I was trying to insert a record into a MySQL table using TypeORM. The error I was experiencing stated that a specific column “cannot be null”, even though the column was explicitly defined as nullable.

Investigation & Root Cause

I performed the following checks to identify the root cause:

1. Checked ORM Entity & Column Definition:

    @Column({ type: 'int', nullable: true })
    columnName?: number | null;
   

   The column was correctly marked as nullable in the ORM model.

2. Verified Database Schema using SHOW CREATE TABLE

    CREATE TABLE `table_name` (
      `columnName` int DEFAULT NULL,
      ...
    );
   

   To make sure everything is good at the table structure level, I ran this command SHOW CREATE TABLE TABLE_NAME. This command gives the details of the table and how it is structured. The definition explicitly stated that the column could be null.

3. Checked for Foreign Key Constraints using SHOW CREATE TABLE & SHOW TABLE STATUS

   No explicit foreign key constraint was found enforcing a non-null value.

4. Checked Active Triggers using SHOW TRIGGERS WHERE Table = 'table_name';

   Discovered one or more triggers (e.g., table_name_insert, table_name_update) that were modifying data before the insert/update operation.

5. Issue Identified:

   • A trigger was enforcing a non-null constraint on the column, even though the schema allowed NULL values.

Solution

Option 1: Remove the Trigger (if unnecessary)

DROP TRIGGER trigger_name;

The easiest option to fix this problem was to remove the trigger, which is causing the problem.

Option 2: Modify the Trigger to Handle Null Values Properly

CREATE TRIGGER trigger_name
BEFORE INSERT ON table_name
FOR EACH ROW
BEGIN
  IF NEW.columnName IS NOT NULL THEN
    INSERT INTO log_table (columnName, action)
    VALUES (NEW.columnName, 'INSERT');
  END IF;
END;

We can add a safety check to prevent errors when the inserted record is NULL.

Option 3: Allow NULL values in the log table

We can modify the column definition in the target log_table to allow NULLs.

Conclusion:

• Even if a column is nullable, triggers can override this behavior.

• Always check active triggers using

    SHOW TRIGGERS WHERE `Table` = 'table_name';
  

• Modifying or disabling triggers can resolve unexpected Column Cannot Be Null errors.

I hope you like this small TIL blog. If you have any questions, please comment below. Thanks for reading 😊.

What is a Builder Pattern?

The Builder Pattern is a creational design pattern that provides a flexible solution for constructing complex objects. In other words, it simplifies object construction. It allows for the step-by-step creation of objects, enabling the customization of the object construction process. For example, when constructing a Person object, instead of providing long parameters to the constructor (as a configuration option), we can allow clients to configure the Person objects one piece at a time.

Imagine you are passing a list of parameters like booleans and strings such as isManager, isEmployee, hours, and name to construct a user object. You would pass these parameters like this: Person(true, true, 40, "Julie"). First of all, this looks very messy, and you need to know the order in which these parameters are expected in the Person's constructor. We can improve this with the Builder Pattern.

Why use Builder Pattern?

Two of the most common doubts I see on the internet, and I also had this in the beginning, are: “Can’t we directly pass an object and, based on that, create an object and add everything within a single Person class instead of using the Builder Pattern?”. Another question is, "Can’t we use a Typescript interface to enforce the object creation according to the defined interface, something like this?”

interface PersonModal {
  name: String;
  isEmployee: boolean;
  isManager?:Boolean;
  hours?: Number;
}

The answer to both questions is yes, you can do it, but the Builder Pattern makes the code more readable and easy to use. Its usage is like a Lego box where you have different parts, and you can construct an object as per your need.

You give the responsibility for object creation to a separate builder class instead of its definition class. You just have to add dot notation and method name, and you can add a feature to your object creation. Its main usage is the separation of the construction of complex objects from their representation (official definition). Imagine you are dumping all complex logic in the same representation class, i.e., the Person class. It will eventually become tough to manage. Refer to the pseudo-code to understand what I mean by plug-and-play and how can we construct and object.

Person -- make --> Manager() -- make --> partTimeEmployee()

In code, it looks like this:

new PersonBuilder()
      .makeEmployee()
      .makeManager()
      .build("Julie");

When not to use Builder Pattern?

Till now we’ve seen all good things about Builder Pattern and how it can be help in constructing complex objects. There are few scenario’s where we cannot use (or avoid it). Below are the few points:

• When the object is simple, with few attributes.

• When performance is critical because this pattern introduce overhead because of multiple function calls for each attribute assignment.

• When object structure is stable or unlikely to change builder pattern can be overkill.

Code Examples in Javascript and C++

Javascript version

// Person.js
class Person {
  constructor(builder) {
    this.name = builder.name;  
    this.isEmployee = builder.isEmployee; 
    this.isManager = builder.isManager; 
    this.hours = builder.hours || 0;
  }

  toString() {
    return JSON.stringify(this);
  }
}
export default Person;

// PersonBuilder.js
import Person from "./Person.js";

class PersonBuilder {
  makeEmployee() {
    this.isEmployee = true;
    return this;
  }

  makeManager() {
    this.isManager = true;
    return this;
  }

  addShoppingList(list) {
    this.shoppingList = list;
    return this;
  }

  build(name) {
    this.name = name;
    return new Person(this);
  }
}

export default PersonBuilder;

// index.js
import PersonBuilder from "./PersonBuilder.js";

const Julie = new PersonBuilder()
                      .makeEmployee()
                      .makeManager()
                      .build("Julie");

console.log(Julie);

C++ version

// person.h
#include <iostream>

class PersonBuilder;

class Person {
    std::string name;  
    bool isEmployee = false; 
    bool isManager = false; 
    int hours = 0;

    friend class PersonBuilder;

    public:
    void printUserDetails();
};

class PersonBuilder {
    Person person;

    public:
    PersonBuilder& setName(const std::string& name);
    PersonBuilder& makeEmployee();
    PersonBuilder& makeManager();
    PersonBuilder& addWorkingHours(int hours);
    Person build();
};


// person.cpp

#include "person.h"

PersonBuilder& PersonBuilder::makeEmployee() {
    person.isEmployee = true;
    return *this;
}

PersonBuilder& PersonBuilder::makeManager() {
    person.isManager = true;
    return *this;
}

PersonBuilder& PersonBuilder::addWorkingHours(int workingHours) {
    person.hours = workingHours;
    return *this;
}

PersonBuilder& PersonBuilder::setName(const std::string& name) {
    person.name = name;
    return *this;
}

Person PersonBuilder::build() {
    return person;
}

void Person::printUserDetails() {
    std::cout << "Name: " << name 
              << ", isEmployee: " << isEmployee 
              << ", isManager: " << isManager 
              << ", Working Hours: " << hours << std::endl;
}

int main() {
    Person julie = PersonBuilder()
                        .setName("Julie")
                        .makeEmployee()
                        .build();
    julie.printUserDetails();
    return 0;
}

Conclusion

The Builder Pattern is easy to understand and a good starting point for learning OOP design patterns. I’ll be writing about other design patterns in upcoming blog posts. I hope you like this blog. If you have any questions, please comment below. Thanks for reading 😊.

Getting started

First of all, we should have a LiveView project. On any page of the project, add a table with a few dummy records or render real records from the database in the table. The records should be enough to make the table scrollable to transition to the particular searched record. Now let's get started.

Add search input

As per the demo gif you saw earlier, adding an input field is the main ingredient to achieve the above feature. So, we are going to add a search input above the table. Make sure to add input , and the table code in the same container div. This is because the search input and the table will be used in the javascript hook for DOM access. Refer to the code below.

<div class="user-table-container" id="user-table-container" phx-hook="SearchUser">
  //Add below container to add search input
  <div class="search-container">
    <label for="search" class="block text-sm">Search</label>
    <input name="search"  placeholder=" Search..." id="search-user">    
  </div>

  <table> 
     <thead class="bg-gray-50">
       <tr>
         <th scope="col" class="w-3 text-left text-sm"></th>
         <th scope="col" class="w-3 text-left text-sm">>Name</th>
         <th scope="col" class="w-3 text-left text-sm">>Count</th>
       </tr>
     </thead>
     <tbody class="divide-y divide-gray-200 bg-white">
       <%= for {record, index} <- Enum.with_index(@records) do %>
         <tr>
          <td class="whitespace-nowrap px-3 py-4 text-sm text-gray-500"></td>
          <td class="whitespace-nowrap px-3 py-4 text-sm text-gray-500 user-name"><%= record.name %></td>
          <td class="whitespace-nowrap px-3 py-4 text-sm text-gray-500"><%= record.count %></td>
         <tr>
       <% end %>  
     </tbody> 
  </table>
</div>

Adding Javascript Hook

As per the title of this blog, it is quite obvious that the solution revolves around DOM (Document Object Manipulation). DOM manipulation is achieved using JavaScript. To integrate JavaScript into our LiveView app, LiveView has a concept of JS Hooks. JS Hooks allows us to register JavaScript lifecycle callbacks on DOM nodes (To know more about Hooks, I wrote a blog about Infinite Scroll in LiveView and explained Hooks in great detail). We will add a file assets/js/user_search.js with the following code.

export default SearchUser = {
    mounted() {
        const searchInput = this.el.querySelector("input")
        console.log(searchInput)
    }
}

Notice, the mounted function, it is the first code that executed when the Hook is initialized( Please read this blog if this doesn't make sense). The above code finds the input field on the web page (where users type their search queries) using querySelector. This will be the starting point of the JavaScript logic. Now, whenever a user starts to type in the search bar, the hook will detect the change and log the searchInput object in the console. In the next section, we will look at the remaining work and explanation of the logic of the DOM search.

Search code explanation

Refer to the complete code of the hook. You've already seen the explanation of searchInput. Now, let's look into how each line of the code works.

export default SearchUser = {
  mounted() {
    const searchInput = this.el.querySelector("input")

    searchInput.addEventListener('input', () => {
        let searchQuery = this.el.querySelector("input").value

        const tableRows = this.el.querySelectorAll('table tbody tr')

        tableRows.forEach(row => {
          // Get the text content of the row
          const rowData = row.textContent.toLowerCase()
          const userNameContainer = row.querySelector('.user-name')
          if (searchQuery.length && rowData.includes(searchQuery.toLowerCase())) {
            // Move focus to the row
            userNameContainer.classList.add('ring-4') // `ring-4` is a tailwind class.
            row.scrollIntoView({behavior: "smooth", block: "center", inline: "nearest"})
          } else {
            userNameContainer.classList.remove('ring-4') // `ring-4` is a tailwind class.
          }

        });

        if (rowData.includes(searchQuery)) {
          row.scrollIntoView({behavior: "smooth", block: "center", inline: "nearest"})
        }
      }
    );  
  }
}

Listening to search events:

We want to listen for the user's typing event. As soon as the user starts typing in the search input, we need to begin searching for the element. To do this, we add an event listener that triggers whenever the user types into the input field (using the input event). The addEventListener method handles this for us.

searchInput.addEventListener('input', () => {
  let searchQuery = this.el.querySelector("input").value
}

We will also get the searched query into a variable searchQuery.

Getting the rows:

Whatever search text we get in the event listener, we need to use that text to filter the table. For that, we will first need to get all the records on the page. We want to select all the table rows (<tr>) inside the body (<tbody>) of a table (<table>). We will do this using querySelectorAll, which returns a list (or a NodeList) of all matching rows in the table.

const tableRows = this.el.querySelectorAll('table tbody tr')

• this.el refers to the parent element that contains the table. It's used to scope the search within that element.

• 'table tbody tr' is the CSS selector used to find all the <tr> elements (table rows) that are inside <tbody> of a <table>.

This line essentially collects all the rows in the table so that we can later loop through each of them to check their content.

Get each row content:

Now, we are going to loop over each row of the table we queried in the previous step. For each row in the table, it converts the row's text to lowercase (to make the search case insensitive) and checks if the row contains the search query.

tableRows.forEach(row => {
  // Get the text content of the row
  const rowData = row.textContent.toLowerCase()
  ...
  ...
})

Highlight Matching Rows:

We are going to search for the name of the user in the table. If you remember (or you can go through the html code), we have added the user-name class to the name td in each row. We will query the user-name element and save it in userNameContainer. Later, we will use it to highlight (add a border) or de-highlight (remove border) matched rows.

const userNameContainer = row.querySelector('.user-name')

We will add a condition to check if searchQuery has any content and if each row contains the searchQuery. If the row contains the search term, the row is highlighted by adding a ring-4 class (this is a Tailwind CSS class that adds a visible border around the row) and also scrolls smoothly to the row, making it visible using scrollIntoView.

if (searchQuery.length && rowData.includes(searchQuery.toLowerCase())) {
  // Move focus to the row
  userNameContainer.classList.add('ring-4') 
  row.scrollIntoView({behavior: "smooth", block: "center", inline: "nearest"})
} else {
  userNameContainer.classList.remove('ring-4') // `ring-4` is a tailwind class.
}

Similarly, when if the searchQuery doesn't match remove the previous highlighted class i.e ring-4

Scroll to Matched Rows:

if (rowData.includes(searchQuery)) {
  row.scrollIntoView({behavior: "smooth", block: "center", inline: "nearest"})
}

This code checks if a specific table row contains the user's searched query. If it does, the page scrolls smoothly to bring the matching row into view, centered on the screen.

Conclusion

I hope you like this blog. If you have any questions please comment below. Thanks for reading 😊.

• \d table_name in the Postgres terminal or

• Run the query SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'your_table_name'; in the database admin tools like Beaver or PgAdmin.

Since the changes were about indexes, I had to be extra cautious to understand their details. So, I was wondering if there could be a way I could see the result soon after running the migrations or whenever I need to view the list of indexes in the same terminal I am working. After doing some tinkering, a mix task was something that came to my mind to achieve the goal. Let's understand the requirements more deeply to make development easier.

Requirement

We want a mix command that will list all the indexes in our application database. We will run the command mix list_indexes and it will render all the indexes in our application. Refer to the image below to get an idea of what output the command is going to render.

Notice, the perfect tabular structure its borders, gaps, etc. We're going to develop the logic to replicate this exactly. So, let's get started.

Adding mix task command

Before starting to create a mix task (command) first I'll give you a brief introduction to what is a mix task. In any Phoenix project when we run mix help it lists all the custom mix tasks. Refer to the example diagram below to get an idea.

Now, we want to write our custom mix task to render the list of indexes. To achieve this, we will create a file lib/mix/tasks/list_indexes.ex. In the file, we will add the following code

  defmodule Mix.Tasks.ListIndexes do
      use Mix.Task

      @shortdoc "To list all the indexes in the database"

      def run(_args) do
           # Write your task logic here
      end
  end

If you'll notice we have added use Mix.Task macro, which adds task capability to this file. To list this task within our application we can run mix help in the project terminal. You will get the list of the tasks but won't find the task we created. It is because we need to compile the project. We will do this by running mix compile. Now on running mix compile and later running mix help again we can see the task we created.

Writing the main logic

Up until now, we understood the requirements and what we wanted to achieve and we set up the code structure. The main logic is remaining, so this will be our approach

• Query database to fetch all the indexes using Ecto.

• Get the longest name in each column

• Render header

• Render all rows

Query database to fetch all the indexes using Ecto.

This will be the simplest part of this blog. We will write a simple Ecto query to fetch all the indexes in the project, which will be passed down for further processing.

defmodule Mix.Tasks.ListIndexes do
     ............
     ............
     ............
     query = from p in "pg_indexes",
        select: %{index_name: p.indexname, table_name: p.tablename},
        where: p.schemaname == "public"

     rows = Repo.all(query)

end

The query is quite simple and intuitive. We are querying the pg_indexes table, which is part of the public schema. For the sake of the demo, we are just querying index_name and table_name. Later, we pass the query to Repo.all to fetch it. To make the query (syntax) and Repo.all work, we have aliased Ecto.Query and imported Repo. This will return a list of structs with index_name and table_name, something like this:

[
  %{index_name: "schema_migrations_pkey", table_name: "schema_migrations"},
  %{index_name: "distributors_pkey", table_name: "distributors"},
  %{index_name: "distributors_email_index", table_name: "distributors"},
  %{index_name: "distributors_tokens_pkey", table_name: "distributors_tokens"},
  .....
]

Get the longest name in each column

In this section, we will write a logic to find the longest string length for each column from fetched records. This will help us to add padding to each column. Suppose, you have two records for column index_name say username_index and distributors_email_index. The function we are going to write will return the length of distributors_email_index because it is the longest one. We will have to write this logic such that it will return a list with the length of two columns (since there are two columns Index Name and Table Name. The code will consist of two functions longest_columns_values/1 and find_longest_length/1. First, we will understand the longest_columns_values.

👉 longest_columns_values/1:

This function takes a list of records as its argument. Each record is a map with keys :index_name and :table_name. The purpose of this function is to transform the records into a list of lists containing only the values of :index_name and :table_name and then find the longest length for each column by passing to the find_longest_length/1 function.

def longest_columns_values(records) do
  Enum.map(records, fn index ->
    [index.index_name, index.table_name]
  end)
  |> find_longest_length
end

👉 find_longest_length/1:

This private function (you can avoid making it private) takes a list of columns of each row and calculates the maximum length of the strings in each column.

defp find_longest_length(rows) do
  Enum.reduce(rows, [], fn row, acc ->
    Enum.zip(row, acc ++ [0])
    |> Enum.map(fn {str, len} ->
      String.length(str) |> Kernel.max(len)
    end)
  end)
end

• Enum.reduce(rows, [], fn row, acc -> ... end):

  This line uses Enum.reduce to iterate over each row in rows. The acc (accumulator) starts as an empty list and is used to store the maximum lengths of each column.

• Enum.zip(row, acc ++ [0]):

  For each row, this line zips the current row with the accumulator. If the accumulator is shorter than the row, it is padded with zeros.

• Enum.map(fn {str, len} -> String.length(str) |> Kernel.max(len) end):

  This line maps over the zipped list of {str, len} tuples. It calculates the length of str and compares it with len (the current maximum length), keeping the larger of the two.

The result of find_longest_length/1 is a list of integers representing the maximum length of the strings in each column. Refer to the example to understand its usage.

rows = [
  %{index_name: "schema_migrations_pkey", table_name: "schema_migrations"},
  %{index_name: "username_key", table_name: "some_long_table_name"},
]

IO.inspect(longest_field_values(rows))
#=> [ 22, 20] - 22 is the length of `schema_migrations_pkey` 
#=> because it is the longest name in the first column i.e. `:index_name`,
#=> and 20 is the length of `some_long_table_name` 
#=> because it is the longest name in the second column i.e. `:table_name`.

Adding the header

Now that we have written the logic to get the list of the widest columns(using longest_columns_values), we will use this list to render the table header. For this, we will write a function render_single_row which we will use to render the header, and later we'll reuse it to render all the rows.

Notice the vertical line | at the start, end, and in the middle of the two columns. The start line will be easy to add, but it will be tougher to add the middle and end lines. We don't know how much space we need to leave after each column letter. This is where longest_columns_values will shine. But how are we going to use it? There is a formula that we are going to follow to give space after each column and the formula is

spaces_count = widest_column_for_the_position - column_name

\=> Explanation

We have seen earlier in the previous section widest_column_counts = [22, 20] and as per the screenshot, the first column is Index Name which is of length 10 . The Index Name is the first column so we will use the first element of widest_column_counts . Hence, the value will be space_count will be 20-10=10 .

So, we will write a render_single_row/2 function as per the above explanation. It will take two arguments i.e row (header in this case) and widest_column_counts .

defp render_single_row(%{index_name: index_name, table_name: table} , widest_column_counts) do
    IO.write("| ")

    [index_name, table]
      |> Enum.with_index()
      |> Enum.each(fn {column_content, index} ->
          border = render_border(index, column_content, widest_column_counts)
          IO.write("#{item} #{border}")
        end)

    IO.puts(" ") #Next line
end

As you can see the function starts with rendering the leftest vertical line | . Then we iterate over the list of columns and render the content using IO.write("#{column_content} #{border}"). So, the above logic is nothing but the entire row rendering logic.

Also, we will write a function render_border which will render ending vertical lines along with trailing spaces as discussed earlier. It will take three parameters position_of_column , item - the item to be rendered and columns_count

defp render_border(position_of_column, item, columns_count) do
    count = Enum.at(columns_count, position_of_column) - String.length(item)
    "#{String.duplicate(" ", count)} | "
end

The above-written code logic has already been explained. We are just fetching space_counts and we are duplicating spaces " " as per count value and ending with a vertical line | .

Render all rows

This is the final section of the table render logic. Remember we fetched the records, and it was nothing but a list of records. We've already completed the logic to render a single row. Now, we have to render a list of rows. For this, we just have to iterate over the rows. Below is the function that will do this job.

defp render_multiple_rows(rows, widest_column_counts) do
  Enum.each(rows, fn row -> render_single_row(row, widest_column_counts) end)
end

Final working code

 defmodule Mix.Tasks.ListIndexes do
  use Mix.Task

  @shortdoc "To list all the indexes in the table"

  alias MyProject.{ Repo }
  import Ecto.Query


  def run(_args) do
    Mix.Task.run("app.start", [Repo])

    query = from p in "pg_indexes",
        select: %{index_name: p.indexname, table_name: p.tablename},
        where: p.schemaname == "public"

    table_headers = %{index_name: "Index Name", table_name: "Table Name"}
    rows = Repo.all(query)
    widest_column_counts = longest_field_values(rows)

    # To render Table header
    render_single_row(table_headers, widest_column_counts)

    # render Table header bottom  border
    IO.puts("| #{String.duplicate("-", Enum.sum(widest_column_counts) + 9)} |")

    # render Table rows
    render_multiple_rows(rows, widest_column_counts)
  end

  # Helper functions
  defp render_multiple_rows(rows, widest_column_counts) do
    Enum.each(rows, fn row -> render_single_row(row, widest_column_counts) end)
  end

  defp render_single_row(%{index_name: index_name, table_name: table} , widest_column_counts) do
    IO.write("| ")

    [index_name, table]
      |> Enum.with_index()
      |> Enum.each(fn {column_content, index} ->
          border = render_border(index, column_content, widest_column_counts)
          IO.write("#{item} #{border}")
        end)

    IO.puts(" ") #Next line
  end

  defp render_border(position_of_column, item, columns_count) do
    count = Enum.at(columns_count, position_of_column) - String.length(item)
    "#{String.duplicate(" ", count)} | "
  end

  defp find_longest_length(rows) do
    Enum.reduce(rows, [], fn row, acc ->
      Enum.zip(row, acc ++ [0])
      |> Enum.map(fn {str, len} ->
        String.length(str) |> Kernel.max(len)
      end)
    end)
  end

  def longest_field_values(records) do
    Enum.map(records, fn index ->
      [index.index_name, index.table_name]
    end)
    |> find_longest_length
  end
end

Final Thoughts

This task may seem a little absurd, but my motivation was to avoid and save some clicks and switching between terminals. We can tweak the code a little further and pass flags to the command, something like --table_name and --first_50/--last_50, to render the first 50 or last 50 records of the passed `table_name`. I felt like sharing this in the hope that it might benefit someone. I hope you like this blog. If you have any questions, please comment below. Thanks for reading 😊.

Creating a Phoenix LiveView Project

First of all, we should have a LiveView project. If you have one skip this section and continue Installing Chromic PDF section. If you don't have one then create a new LiveView project by running mix phx.new my_app --live. We will then navigate to the project directory by running cd my_app in the terminal. And finally, run the project running mix phx.server in the terminal. Once, the project starts running navigate to localhost:4000 to see the "Welcome phoenix" page.

Installing Chromic PDF

To create a PDF, the Elixir community has an awesome library called chromic_pdf. It is very easy to integrate. It does not use puppeteer, and hence does not require Node.js. It communicates directly with Chrome's DevTools API over pipes, offering the same performance as puppeteer, if not better. So we are going to use it. Let's add it to our project. Open the mix.exs file and make an entry of it as shown below.

defp deps do
  ...
  {:chromic_pdf, "~> 1.14"},
  ...
end

Then install the dependency by running mix deps.get. It will install all the dependencies. Now, we will run ChromicPDF as part of our application by adding it in application.ex.

defmodule MyApp.Application do
   ...
  def start(_type, _args) do
    children = [
      ...
      ChromicPDF
      ...
    ]
    ...
  end
...
end

This will make sure that this process should be started when the application starts and is supervised by the Supervisor.

Adding endpoint to generate PDF

We want our pdf generator to be served at a different endpoint and serve a regular HTTP response because we cannot send pdf over a web socket i.e. LiveView. We will add a GET endpoint /generate-invoice under BillsController.

scope "/", MyAppWeb do
    pipe_through [:browser, :require_authenticated_distributor]

    get "/generate-invoice", BillsController, :index
end

Make sure to add the require_authenticated_distributor plug (or any other authentication/authorization plug) in the pipeline to make sure the endpoint is authenticated else it will be exposed to the attackers.

Adding Controller

Now, we will add the controller for the endpoint we added in the router

defmodule MyAppWeb.BillsController do
  use MyAppWeb, :controller

  def index(conn, _params) do
    #Assign some attributes and values which we can use in the pdf.
    conn = assign(conn, :total_amount_paid, 10000) 
    {:ok, pdf} = to_pdf(conn.assigns) ### We will write this function later.

    send_download(
        conn,
        {:binary, Base.decode64!(pdf)},
        content_type: "application/pdf",
        filename: "invoice"
    )
  end
end

At the end of the index action, we can see the send_download button which takes 4 parameters:

• conn: a connection struct.

• content in binary tuple format i.e.pdf in this case.

• content_type: the content type.

• filename: give the file name of our choice.

send_download is used to send the given file or binary as a download. In other words, it will be the reason to download the generated PDF in your browser.

Implementing to_pdf function

In the index action, we saw the to_pdf function in the previous section. We are going to implement it in this section. In this function, we will see ChromicPDF in action. You will see two functions source_and_options and print_to_pdf.

• source_and_options: The module Template in ChromicPDf usage is mainly to generate HTML from the provided template and styling. We can see it calls the source_and_options function which returns the source and options for a PDF to be printed, as per the given set of template options like content and size of the PDF.

• print_to_pdf: As the name suggests it Prints a PDF. It is a blocking call which means it will block further code until the PDF is generated.

Refer to the following code

def to_pdf(assigns) do
    [
      content: content(assigns), # `content` function yet to be implemented
      size: :a4,
    ]
    |> ChromicPDF.Template.source_and_options()
    |> ChromicPDF.print_to_pdf()
end

Generating content for the PDF

Now, the most important part of the implementation. You have seen the content function in to_pdf which is yet to be implemented. We are going to implement that and learn why we are going to use components and not views. Earlier, Phoenix.View was used to render HTML (view) which was later passed to the ChromicPDF#source_and_options function. But since Phoenix 1.7 the Phoenix.View has been eliminated and substituted with the new Phoenix.Template. Phoenix 1.7 supports function components to render both controller-based and LiveView-based components. So, we are going to use Phoenix.LiveComponent instead of Phoenix.View. For this, we will create a component PdfRenderer component inside the components folder, and in the module, we will add a render function. In this function we will write the HTML and CSS we want to render for the PDF. Refer to the following code.

defmodule PdfRendererComponent do
  use Phoenix.LiveComponent

  def render(assigns) do
    ~H"""
      <h1>Invoice</h1>
      <p style="font-size: 200%;">Total:  <%= @total_amount_paid %> </p>
    """
  end
end

In the above render function you can see the field total_amount_paid attribute. Where does this come from? If you remember in the controller we assigned the total_amount_paid attribute to the conn struct. We are getting it here because of the assign parameter in the render function. To access it in this component we have to pass the conn.assign struct directly to the component. Something like this,

PdfRendererComponent.render(assigns)

We will implement this function content to render this component. Refer to the following code.

defp content(assigns) do
    Phoenix.HTML.Safe.to_iodata(PdfRendererComponent.render(assigns))
end

In Phoenix, you can call the functions of the components using Phoenix.HTML.Safe.to_iodata. The official documentation says "(It) provides better performance when sending or streaming data to the client". So, in this case, the HTML is sent to the ChromicPDF.Template.source_and_options() to render. Whatever HTML and CSS we write in the render function will be passed to the source_and_options. The final working code of the controller is below.

defmodule MyAppWeb.BillsController do
  use MyAppWeb, :controller

  def index(conn, _params) do
    #Assign some attributes and values which we can use in the pdf.
    conn = assign(conn, :total_amount_paid, 10000) 
    {:ok, pdf} = to_pdf(conn.assigns) ### We will write this function later.

    send_download(
        conn,
        {:binary, Base.decode64!(pdf)},
        content_type: "application/pdf",
        filename: "invoice"
    )
  end

  def to_pdf(assigns) do
    [
      content: content(assigns), 
      size: :a4,
    ]
    |> ChromicPDF.Template.source_and_options()
    |> ChromicPDF.print_to_pdf()
 end

 defp content(assigns) do
    Phoenix.HTML.Safe.to_iodata(PdfRendererComponent.render(assigns))
 end
end

Adding Download button

Finally, we need to add an Invoice/Download button to call this endpoint we created. It will be a simple link tag.

<%= link "Invoice", to: "/generate-invoice", class: "button", download: 'invoice.pdf` %>

You’ll notice I have added an download attribute to the link tag. I wrote a small TIL blog on its usage you can check it later 😊.

I hope you like this blog. If you have any questions please comment below. Thanks for reading 😊.

References

• Chromic PDF

<table>
  .....
  .....
  .....
  <tbody>
    <tr>
      <form>
        <td>
          <input type="text" name="count">
        </td>
        <td>
          <input type="text" name="rate">
        </td>
        <td>
          <input type="text" name="paid">
        </td>
      </form>
    </tr>
  </tbody>
</table>

This wasn't working because placing a form as a child element of a table, tbody, or tr is not allowed. If we add it the browser typically relocates the form to appear after the table, leaving its contents, such as table rows, cells, inputs, etc., in their original positions within the table. Hence, when we try to submit the form it won't work.

How can we fix this problem?

To solve this problem we can use the form attribute. For this, we will place an empty form somewhere within the page and outside of the table tag. We need to provide the form an id attribute. This id will be an identifier for the form fields. Something like this

<.simple_form for={@distribution_record_form} id="distribution_record" phx-submit="save" phx-update="ignore" class="flex">  
</.simple_form>

And later inside the table for each field i.e. cell we can add the form attribute to tell the fields to which form it belongs. It should be the same as the id of the form .

<td>
   <.input field={@distribution_record_form[:rate]} form="distribution_record" />
</td>

The form attribute will tell the input field that it is part of distribution_record form. So, when the user tries to submit the form whatever data the user will add in this input box will be part of the distribution_record form. Our requirement is that each row i.e. tr should appear as a form in which the last column will have a submit button. So below is the code of how each row will appear.

<tr>
     <td>
         <.input field={@distribution_record_form[:count]} form="distribution_record" /> 
     </td>
     <td>
         <.input field={@distribution_record_form[:rate]} type="text" form="distribution_record" />
     </td>
     <td><.input field={@distribution_record_form[:paid]} type="text" form="distribution_record" />
     </td>
     <td>
        <.button phx-disable-with="Saving..." form="distribution_record">
            Update
        </.button>
     </td>
</tr>

The above code will map to the form one that we created earlier. The below diagram will give you an idea of how this mapping is going to work.

I hope this diagram will make sense to you. I know this is quite a trivial thing but I wasn't aware until I came across this problem and I noted it in my TIL list and shared it in this blog. I hope you like this TIL blog. If you have any questions please comment below. Thanks for reading 😊.

Problem

While working on one of the projects I added an endpoint i.e. /generate-invoice(GET) in a Phoenix application. Its job was to do some tabular computation and generate a PDF. I added a link tag to call the endpoint something like this

<%= link "Invoice", to: "/generate-invoice", class: "button" %>

As expected it was working fine but later I noticed a weird behavior. After clicking the Invoice button when I tried to click other buttons or any action that involved javascript, it wasn't working. I thought there was some bug with my endpoint or other code I tried to fix it but things weren't working for me.

Solution

When we try to access a GET endpoint that downloads, the browser navigates away from the current page. It doesn‘t know the target will download something, and will therefore shut down the javascript of the current page. Till then I wasn't aware of the download attribute on the link tag. Adding the download attribute on the above link tag helped me in fixing the problem.

<%= link "Invoice", to: "/generate-invoice", class: "button", download: 'invoice.pdf` %>

I hope you like this small TIL blog. If you have any questions please comment below. Thanks for reading 😊.

const sequelize = new Sequelize('database', null, null, {
  dialect: 'mysql',
  port: 3306,
  replication: {
    read: [
      { host: '8.8.8.8', username: 'read-1-username', password: process.env.READ_DB_1_PW },
      { host: '9.9.9.9', username: 'read-2-username', password: process.env.READ_DB_2_PW }
    ],
    write: { host: '1.1.1.1', username: 'write-username', password: process.env.WRITE_DB_PW }
  },
  pool: { 
    max: 20,
    idle: 30000
  },
})

Recently, I came across a situation where I was creating(writing) data and immediately on the next line was returning the created record along with some association as an API response but the record was returning empty.

const recordIds = await fileService.create(req.files)
const files = await fileService.list({ id: recordIds })
return response(res, {record: files})

The fileService.create function creates record file records in the database and returns an array of ids of the files created. In the next line i.e. the fileService.list function takes the array of IDs, fetches the record, and returns an API response in the last line. Below is the implementation of the list function

async list(ids) {
   return await Model.findAll({
      where: {
        id: ids
      },
      ...associationQuery
    })
}

This looks plain and simple but for some reason, the list function didn't return any record. I did a lot of debugging and everything looked fine. Then I came across the property useMaster. The read replication we read about in our introduction takes some time to replicate in the read pool. The write or useMaster: true query uses a write pool to create or fetch data. So, the useMaster: true property fixes the issue of fetching data immediately after creating and it fulfills my requirement. Hence, I added useMaster: true in the above query. So the above list function becomes like this 👇

async list(ids) {
   return await Model.findAll({
      where: {
        id: ids
      },
      ...associationQuery,
      useMaster: true // New added line
    })
}

The above code fixed the issue of data not being fetched in read replicas. I hope you like this small TIL blog. If you have any questions please comment below. Thanks for reading 😊.

References

• Read Replication in Sequelize
• Cover Image

What do we want to achieve? (An example)

Suppose, we have the following SVG string which we want to export on pdf.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" fill="none" stroke="#000" stroke-width="4" aria-label="Chicken">
    <path d="M48.1 34C22.1 32 1.4 51 2.5 67.2c1.2 16.1 19.8 17 29 17.8H89c15.7-6.6 6.3-18.9.3-20.5A28 28 0 0073 41.7c-.5-7.2 3.4-11.6 6.9-15.3 8.5 2.6 8-8 .8-7.2.6-6.5-12.3-5.9-6.7 2.7l-3.7 5c-6.9 5.4-10.9 5.1-22.2 7zM48.1 34c-38 31.9 29.8 58.4 25 7.7M70.3 26.9l5.4 4.2"/>
</svg>

We can see in the above code snippet there are two main tags. One is the main <svg> tag and the other is the <path> tag. Now we are going to refer to react-pdf documentation under the SVG section. We can see we have both tags under the SVG section. For the svg it is a <Svg /> tag and for path it is the <Path> tag. So the above SVG string will become as follows

<Svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" fill="none" stroke="#000" stroke-width="4" aria-label="Chicken">
    <Path d="M48.1 34C22.1 32 1.4 51 2.5 67.2c1.2 16.1 19.8 17 29 17.8H89c15.7-6.6 6.3-18.9.3-20.5A28 28 0 0073 41.7c-.5-7.2 3.4-11.6 6.9-15.3 8.5 2.6 8-8 .8-7.2.6-6.5-12.3-5.9-6.7 2.7l-3.7 5c-6.9 5.4-10.9 5.1-22.2 7zM48.1 34c-38 31.9 29.8 58.4 25 7.7M70.3 26.9l5.4 4.2" />
</Svg>

Converting an image from storage URL to SVG string

The main requirement to use react-pdf SVG is that we need to have normal SVG as a string. But in most cases and even in our case as well, we are getting these images i.e. jpg, png, and svg as URL from the s3 bucket. We need to fetch these images blob and convert it into the SVG string. So, the steps to achieve this are as follows.

• First, fetch the image bytes from the API endpoint.

• Then convert it to text. You can refer to the following code to achieve it.

const response = await fetch(s3_bucket_url,
               { 
                headers: {"x-access-token": token}
               });
const rawSVG = await response.text();
const photoContent = rawSVG;

Creating SVG Renderer component

Now comes the meat of the blog i.e. component that will convert the fetched SVG string to a react-pdf specific SVG. We will create a component SVGRenderer. It will take svgString from the parent component where we are fetching the svgString.

export const SVGRenderer = ({ svgString }) => {
   // Logic will be here
}

The working of this component can be divided into 5 steps:

Step 1: Convert the SVG string to a javascript object.

Step 2: Convert each tag into a react-pdf tag

Step 3: Convert styles into style objects compatible with React-Pdf

Step 4: Create an object of each tag to the corresponding react-pdf SVG object.

Step 5: Calling svgToJsx function.

Step 1 - Convert the SVG string to a javascript object

• We want our SVG string to be converted into a Javascript object so that we can pluck different properties of SVG and use it to render react-pdf specific SVG.

• For this, we are going to use the svg-parser library. The package says that "(It)Takes a string representing an SVG document or fragment, turn it intoHASTJavaScript object.

• We will install the library

  npm install svg-parser --save

• We will import the svg-parser into the component file and it will convert the string to an object.

   import { parse as svgparse } from "svg-parser";

   export const SVGRenderer = ({ svgString }) => {
       const parsedSVG = svgparse(svgString);
       .....
       .....
       .....
    }

Step 2 - Convert each tag into a react-pdf tag

Each SVG is made up of multiple nested tags. Like in our example in the introduction, there is an svg tag underneath there is a path tag. Each tag has its properties and styling. We have to write a recursive function that will pluck the properties, content, and styles of each tag. Later, we will use those properties to construct the react-pdf SVG object. Refer to the following pseudo-code you well get an idea.

  const tag = tag.type === "element" ? tag.tagName : tag.type;
  const props = {
    style: convertStylesStringToObject(tag.properties.style), // We are yet to implement this function
    key: someUniqueKey,
    ...tag.properties
  }
 let children = tag.content

Later, we will use the above constructed props to create an SVG tag. Something like this👇

if (tag === "svg") {
      return <Svg {...props}>{children}</Svg>;
}

The above sample code gives us some idea about how we are going to create the function. We will name this function svgToJsx it will take two arguments. The first argument is the tag we will name it obj and the other tag is the index for the unique key. Refer to the following code.

const svgToJsx = (obj, index) => {
    let name = obj.type === "element" ? obj.tagName : obj.type;
    let props = { key: index + name };

    if (obj.properties !== undefined) {
      if (obj.properties.style !== undefined) {
        props.style = convertStylesStringToObject(obj.properties.style); // Yet to write
      }
      props = { ...obj.properties, ...props };
    }
    let children =
      obj.children !== undefined ? (
        obj.children.map((c, i) => {
          return svgToJsx(c, index + "-" + i);
        })
      ) : (
        <></>
      );
    ......
    ......
    ......
}

Step 3 - Convert styles into style objects compatible with React-Pdf

You may have noticed the convertStylesStringToObject function mentioned in the svgToJsx function which is yet to be implemented. Normally in SVG, we write inline CSS as follows:

<circle style="fill:green; margin: 30px;">

Our target is to convert the style into an object as follows

<Circle style={{ fill: 'green', margin: 30 }} />

For this, we are going to write a reducer function that will convert the CSS string into a JSX compatible style object. It will do two tasks:

a) Remove spaces and semicolons

b) Convert two-word(dasherized) attributes into camel case For example, stroke-width will be converted to strokeWidth, or background-color will be converted to backgroundColor. Refer to the following code for reference.

const convertStylesStringToObject = (stringStyles) => {
    let styles =
      typeof stringStyles === "string" && stringStyles !== undefined
        ? stringStyles
          .replaceAll(""", "'")
          .split(";")
          .reduce((acc, style) => {
            const colonPosition = style.indexOf(":");

            if (colonPosition === -1) return acc;

            const camelCaseProperty = style
                .substr(0, colonPosition)
                .trim()
                .replace(/^-ms-/, "ms-")
                .replace(/-./g, (c) => c.substr(1).toUpperCase()),
              value = style.substr(colonPosition + 1).trim();

            let isSvgStyle = [
              "color",
              "dominantBaseline",
              "fill",
              "fillOpacity",
              "fillRule",
              "opacity",
              "stroke",
              "strokeWidth",
              "strokeOpacity",
              "strokeLinecap",
              "strokeDasharray",
              "transform",
              "textAnchor",
              "visibility"
            ].includes(camelCaseProperty);

            return isSvgStyle && value ? { 
              ...acc, 
              [camelCaseProperty]: value 
            } : acc;
          }, {}) 
        : {};

    return styles;
  };

Step 4 - Pass created SVG attributes, props, and styles to react-pdf SVG tag

We've already seen an example in the introduction where we converted the svg and path to Svg and Path. So, in the final part of the svgToJsx function, we will convert each tag into a react-pdf specific tag as per the name and will apply styles and content.

   if (name === "svg") {
      return <Svg {...props}>{children}</Svg>;
   }

Also, we will import all the SVG tags in the component.

import {
  Svg,
  Line,
  Polyline,
  Polygon,
  Path,
  Rect,
  Circle,
  Ellipse,
  Text,
  Tspan,
  G,
  Stop,
  Defs,
  ClipPath,
  LinearGradient,
  RadialGradient
} from "@react-pdf/renderer";

Step 5: Calling svgToJsx function

In the last step SvgRenderer component will return the svgToJsx function and it will pass parsedSVG.children[0] and an initial index value of 0 as parameters. Refer to the code snippet below.

  return <>
    {svgToJsx(parsedSVG.children[0], 0)}
  </>

Passing the SVG string to the component

Now, we understand the working of the SVGRenderer component. The only step that is remaining is to pass svg string we fetched from the API to this component. Refer to the following code.

 <SVGRenderer svgString={photoContent} />

This completes the entire code explanation of converting SVG to react-pdf specific SVG. Below is the complete code of the SVGRender component.

import React from 'react';
import {
  Svg,
  Line,
  Polyline,
  Polygon,
  Path,
  Rect,
  Circle,
  Ellipse,
  Text,
  Tspan,
  G,
  Stop,
  Defs,
  ClipPath,
  LinearGradient,
  RadialGradient
} from "@react-pdf/renderer";
import { parse as svgparse } from "svg-parser";

export const SVGRenderer = ({ svgString }) => {
  const svgWithoutPixel = svgString.replaceAll("px", "pt");
  const parsedSVG = svgparse(svgWithoutPixel);

  const convertStylesStringToObject = (stringStyles) => {
    let styles =
      typeof stringStyles === "string" && stringStyles !== undefined
        ? stringStyles
          .replaceAll(""", "'")
          .split(";")
          .reduce((acc, style) => {
            const colonPosition = style.indexOf(":");

            if (colonPosition === -1) return acc;

            const camelCaseProperty = style
                .substr(0, colonPosition)
                .trim()
                .replace(/^-ms-/, "ms-")
                .replace(/-./g, (c) => c.substr(1).toUpperCase()),
              value = style.substr(colonPosition + 1).trim();

            let isSvgStyle = [
              "color",
              "dominantBaseline",
              "fill",
              "fillOpacity",
              "fillRule",
              "opacity",
              "stroke",
              "strokeWidth",
              "strokeOpacity",
              "strokeLinecap",
              "strokeDasharray",
              "transform",
              "textAnchor",
              "visibility"
            ].includes(camelCaseProperty);

            return isSvgStyle && value ? { 
              ...acc, 
              [camelCaseProperty]: value 
            } : acc;
          }, {}) 
        : {};

    return styles;
  };

  /**
   * Rendering logic to convert normal SVG (svgString) to react-pdf compatible SVG
   * **/ 
  const svgToJsx = (obj, index) => {
    let name = obj.type === "element" ? obj.tagName : obj.type;
    let props = { key: index + name };

    if (obj.properties !== undefined) {
      if (obj.properties.style !== undefined) {
        props.style = convertStylesStringToObject(obj.properties.style);
      }
      props = { ...obj.properties, ...props };
    }
    let children =
      obj.children !== undefined ? (
        obj.children.map((c, i) => {
          return svgToJsx(c, index + "-" + i);
        })
      ) : (
        <></>
      );
    if (obj.type === "text") {
      return obj.value;
    }
    if (name === "tspan") {
      let y = props.y ?? 0 + props.dy ?? 0;
      let x = props.x ?? 0 + props.dx ?? 0;
      console.log("tspan", children, y);
      return children.length > 0 ? (
        <Tspan x={x} y={y} key={props.key}>
          {children}
        </Tspan>
      ) : (
        <></>
      );
    }
    if (name === "text") {
      return (
        <Text
          x={props.x ?? 0 + props.dx ?? 0}
          y={props.y ?? 0 + props.dy ?? 0}
          key={props.key}
        >
          {children}
        </Text>
      );
    }
    if (name === "svg") {
      return <Svg {...props}>{children}</Svg>;
    }
    if (name === "path") {
      return <Path {...props}>{children}</Path>;
    }
    if (name === "line") {
      return <Line {...props}>{children}</Line>;
    }
    if (name === "polyline") {
      return <Polyline {...props}>{children}</Polyline>;
    }
    if (name === "polygon") {
      return <Polygon {...props}>{children}</Polygon>;
    }
    if (name === "rect") {
      return <Rect {...props}>{children}</Rect>;
    }
    if (name === "circle") {
      return <Circle {...props}>{children}</Circle>;
    }
    if (name === "ellipse") {
      return <Ellipse {...props}>{children}</Ellipse>;
    }
    if (name === "g") {
      return <G {...props}>{children}</G>;
    }
    if (name === "stop") {
      return <Stop {...props}>{children}</Stop>;
    }
    if (name === "defs") {
      return (
        <>
          {/*<Defs {...props}>
        {obj.children !== undefined
          ? obj.children.map((c, i) => {
              return <></>;// svgToJsx(c, index+"-"+i);
            })
          : undefined}
          </Defs>*/}
        </>
      );
    }
    if (name === "clipPath") {
      return <ClipPath {...props}>{children}</ClipPath>;
    }
    if (name === "linearGradient") {
      return <LinearGradient {...props}>{children}</LinearGradient>;
    }
    if (name === "radialGradient") {
      return <RadialGradient {...props}>{children}</RadialGradient>;
    }
  };

  return <>
    {svgToJsx(parsedSVG.children[0], 0)}
  </>
}

I hope you like this blog. If you have any questions please comment below. Thanks for reading 😊.

References

• React PDF

• Github.com (Thank you @dennemark for creating the issue and sharing the idea)

Steps

• The most obvious requirement for installing timescaledb is to have Postgress.app installed.
• After installing Postgres.app we will install the timescaledb. For this, we will follow below steps from the official documentation.
• Open your terminal and run
  • brew tap timescale/tap
  • brew install timescaledb
• Next, we have to run timescaledb-tune which requires passing the Postgres path with the version number of Postgres.(NOTE: Suppose, you have multiple version of Postgres say 13 and 14 and we want to install timescaledb on version 14 so we will use var-14 in the conf-path).
• Run following script

  timescaledb-tune --yes --conf-path=/Users/<user_name>/Library/Application\ Support/Postgres/var-14/postgresql.conf
  

• Navigate to /opt/homebrew/Cellar/timescaledb/ and you will see folder with some number, it is nothing but timescaledb version. In my case, it is 2.8.1 so we will be using it in the below script. So, run the below script with your timescaledb number.

/usr/bin/install -c -m 755 $(find /opt/homebrew/Cellar/timescaledb/2.8.1/lib/timescaledb/postgresql@14/ -name "timescaledb*.so")  /Applications/Postgres.app/Contents/Versions/14/lib/postgresql

/usr/bin/install -c -m 644 /opt/homebrew/Cellar/timescaledb/2.8.1/share/timescaledb/* /Applications/Postgres.app/Contents/Versions/14/share/postgresql/extension/

• After this open the Postgress app and click the Server Settings button
• It will open a popup on which will click on the show button of config i.e second option.
• This will open a folder with postgresql.conf file selected. Now, open this file and add the following lines at the end of the file.

  shared_preload_libraries = 'timescaledb'
  

• Now, restart the Postgres app. Double click on your database from the list of the database in the app. It will open the command prompt of the selected database. After that run the following command

  CREATE EXTENSION IF NOT EXISTS timescaledb;
  

• This will add timescaledb for your particular database.

I hope you like this blog. If you have any questions then please comment below. Thanks for reading 😊.

References

• Postgress.app
• TimescaleDB
• Timescale Installation
• Stackoverflow (Thank you Dr. Manhattan)

Blog series!!!

This is a 3 part blog series.

• Part 1: We will be generating the application, adding the different tables, and the API layer, and we will test the API layer in the iex shell

• Part 2: We will build the board, add tasks UI, and integrate the board with the functions (API) we created in Part 1 (This is Part 2)

• Part 3: We will be adding real-time behavior to our board (under development)

Plan of attack

• Getting the board and card UI ready ✓

• Adding drag and drop feature to cards ✓

• Adding JS hook and integrating with the UI✓

• Integrating the UI with the API ✓

Getting the skeleton ready i.e Board

• As per our planning, in this part of the series, we have to create our Trello board with cards and drag-drop functionality.

• We are going to add our dashboard in our root URL of the application.

• For this, we will open router.ex and add the following code

scope "/", TrelloAppWeb do
    pipe_through :browser

    live "/", HomeLive
end

• We have registered the root URL i.e / with the home_live file.

• Now, create a file trello_app/lib/trello_app_web/live/home_live.ex and add following code

  defmodule TrelloAppWeb.HomeLive do
    use TrelloAppWeb, :live_view
  
    def mount(_params, _session, socket) do
      { :ok, socket }
    end
  end

• Before creating any view of the LiveView we will add some styling for the board and the cards.

• Open the app.css file in the assets folder and paste the following CSS stylings.

  html {
    font-family: sans-serif;
    background: #b1dade;
    color: #4a6064;
    font-weight: 400;
  }
  
  body {
    margin: 0;
  }
  
  * {
    box-sizing: border-box;
  }
  
  h1, h2, h3, h4, h5, h6 {
    font-weight: 400;
  }
  
  h1 {
    margin: 0;
    background: #303945;
    color: #fff;
    font-weight: 400;
    padding: 0.5rem;
    font-size: 1.2rem;
  }
  
  main {
    display: flex;
    flex-direction: column;
    height: 100vh;
    overflow: hidden;
  }
  
  .fullwidth {
    width: 100%;
  }
  
  .board {
    flex-grow: 1;
    width: 100%;
    padding: 1rem;
    overflow: scroll;
    display: flex;
    align-items: flex-start;
  }
  
  .list {
    margin: 0;
    min-width: 14rem;
    flex-basis: calc(100% / 6 - 1rem);
    padding: 0;
    list-style: none;
    margin: 0.5rem;
    background: #e7f3f4;
    color: #4a6064;
    border-radius: 0.2rem;
    overflow: hidden;
    padding-bottom: 8px;
  }
  
  .list-form {
    margin: 0;
    min-width: 14rem;
    flex-basis: calc(100% / 6 - 1rem);
    padding: 0;
    list-style: none;
    margin: 0.5rem;
    background: #e7f3f4;
    color: #4a6064;
    border-radius: 0.2rem;
    overflow: hidden;
  }
  
  .list-form form {
    padding: 0.5rem;
  }
  
  .list-form form > * + * {
    margin-top: 0.5rem;
  }
  
  .list-form h2,
  .list-header {
    font-size: 0.8rem;
    font-weight: 600;
    margin: 0;
    padding: 0.5rem;
    padding-bottom: 0;
  }
  
  .list-footer {
    margin-top: 0.5rem;
    padding: 0.5rem;
    overflow: auto;
    background: #ddeff0;
    color: #4a6064;
  }
  
  .card {
    margin: 0.5rem;
    margin-bottom: 0;
    background: #fff;
    color: #4a6064;
    padding: 0.5rem;
    border-radius: 0.2rem;
    height: 100px;
  }
  
  .card:first-of-type {
    margin: 0;
  }
  
  .card a {
    color: inherit;
    text-decoration: none;
  }

• Now, add a file home_live.html.heex in the same folder(of home_live.ex) and add h1 tag with some random message for testing purposes.

• As per our design we want three columns planning, progress, and completed to display our cards. Refer to the below image to get an idea.

  

• Now, in the home_live.html.heex add these three columns with id as per the status.

<div class="board" id="trello-board">
    <ul class="list" id="planning">
        <div class="list-header"> Planning </div>
    </ul>

    <ul class="list" id="progress">
       <div class="list-header"> In Progress </div>
    </ul>

    <ul class="list" id="completed">
       <div class="list-header"> In Progress </div>
    </ul>
</div>

• It will just create empty columns without any card because we haven't added any.

Getting the Card ready

• If you remember we have created a function get_grouped_tasks/0 in the Project context.

• We will assign the value of this function to the assigns in the mount function and later will iterate over these values in the view.

• In the mount function of the home_live.ex, add the following code.

  defmodule TrelloAppWeb.HomeLive do
    ....
    alias TrelloApp.Organization
  
    def mount(_params, _session, socket) do
      tasks = Organization.get_grouped_tasks()
      {:ok, assign(socket, tasks: tasks)}
    end  
  end

• We added an alias of the Organization context and assigned tasks to the socket using the get_grouped_tasks function.

• If you remember get_grouped_tasks returns key-value pair of task status as key and a list of tasks as value.

• Something like this

%{
  "planning" => [
      %TrelloApp.Organization.Task{
        __meta__: #Ecto.Schema.Metadata<:loaded, "tasks">,
        description: "designing api",
        id: 2,
        inserted_at: ~N[2022-08-25 09:30:08],
        state: "planning",
        title: "Designing API",
        updated_at: ~N[2022-08-25 09:30:08],
        user: %TrelloApp.Organization.User{
          __meta__: #Ecto.Schema.Metadata<:loaded, "users">,
          first_name: "Michael",
          id: 1,
          inserted_at: ~N[2022-08-25 08:45:25],
          last_name: "holding",
          tasks: #Ecto.Association.NotLoaded<association :tasks is not loaded>,
          updated_at: ~N[2022-08-25 08:45:25]
        },
        user_id: 1
      }
  ],
  "progress" => [
      // two tasks under progress
      %TrelloApp.Organization.Task{ id: 2 },  
      %TrelloApp.Organization.Task{ id: 3 }
   ],
   "completed" => [
      // one task under completed
      %TrelloApp.Organization.Task{id: 4}
   ]
}

• Now, we will iterate over each of the lists in each column.

  <div class="board" id="trello-board">
      <ul class="list" id="planning">
          <div class="list-header"> Planning </div>
          <%= for task <- @tasks["planning"] || [] do %>
             <li class="card">
                <a href><%= task.title %></a>
                 <i><%= full_name({title.user}) %></i>
              </li>
          <% end %>
      </ul>
  
      <ul class="list" id="progress">
         <div class="list-header"> In Progress </div>
         <%= for task <- @tasks["progress"] || [] do %>
             <li class="card">
                <a href><%= task.title %></a>
                 <i><%= full_name({title.user}) %></i>
              </li>
          <% end %>
      </ul>
  
      <ul class="list" id="completed">
         <div class="list-header"> In Progress </div>
         <%= for task <- @tasks["completed"] || [] do %>
             <li class="card">
                <a href><%= task.title %></a>
                 <i><%= full_name({title.user}) %></i>
              </li>
          <% end %>
      </ul>
  </div>

• This will render all cards in each column. Now, we will work on adding the drag and drop feature to our board.

Adding drag and drop feature to cards

I wanted a vanilla javascript library that should be lightweight and highly supportive in the js community. While doing some research I came across sortable-js. Let's install it in the application. Navigate to the assets directory by running cd assets then run

  npm install sortablejs --save

• I went through sortablejs documentation and came across a create method which can help us to move the cards from one point to another.

• It takes the element reference of the column that you want to be sortable as the first argument and the second argument will be an object with different properties you want to apply(as per documentation).

    Sortable.create(planning, {
        group: 'shared',
        animation: 150,
        sort: false,
        onEnd: function (/**Event*/evt) {}
    });

• The last property in the object i.e onEnd callback is where we have to do all manipulation. It is going to execute as soon as we drop the card on the other column. It has one event parameter which will have all information like the detail of the dragged element and the column where it is dropped.

Adding meta-data to each card

• We've discussed the onEnd callback in the create method. It has some information about the dragged element and the point where it is dropped.

• We are going to add a data property with the name task-id and value as id of the task on each card. Notice, the data-task-id property in the li tag.

    <%= for task <- @tasks["completed"] || [] do %>
       <li class="card" data-task-id={"#{task.id}"}> <==Notice this
          <a href><%= task.title %></a>
           <i><%= full_name({title.user}) %></i>
        </li>
      <% end %>

• This data-task-id will act as the information of the element that is being dragged.

• Also, if you remember the id on each column i.e ul tag, will act as information where the card is being dropped.

  <ul class="list" id="completed">

• So, in onEnd callback we can access id and taskId as follows

    console.log(`Id: ${evt.to.id}`) 
    console.log(`taskId: ${evt.item.dataset.taskId}`)

• We will use this information when we are going to write our javascript hook to make all things work.

Adding Javascript Hook

We have installed sortablejs and discussed the method and made some changes in the Html to make it work with our javascript logic. Now, we will add the javascript logic. We will add a mounted callback, which is called and initialized with some initial value as soon as the element on which we are applying it is mounted in the DOM.

• Let's add a file in trello_board.js in assets/js folder.

• We will initialize Sortable.create for all of the three columns. We will get all of the three columns using document.getElementById('column_id'). Refer to the code below.

  import Sortable from 'sortablejs';

  TrelloBoard = {
    mounted(){ 
      const planning = document.getElementById('planning')
      const progress = document.getElementById('progress')
      const completed = document.getElementById('completed')
      const pushEvent = (target, taskId) => {
        this.pushEvent("move_task", {target, taskId})
      }

      Sortable.create(planning, {
          group: 'shared',
          animation: 150,
          sort: false,
          onEnd: function (/**Event*/evt) {
            pushEvent(evt.to.id, evt.item.dataset.taskId) 
          }
      });

      Sortable.create(progress, {
          group: 'shared',
          animation: 150,
          sort: false,
          onEnd: function (/**Event*/evt) {
            pushEvent(evt.to.id, evt.item.dataset.taskId) 
          }
      });

      Sortable.create(completed, {
          group: 'shared',
          animation: 150,
          sort: false,
          onEnd: function (/**Event*/evt) {
            pushEvent(evt.to.id, evt.item.dataset.taskId) 
          }
      });
  }
 export default TrelloBoard

• Everything seems similar to what we discussed earlier, except the pushEvent function.

• This function is initialized on the fourth line of the mounted function and it takes target and taskId as the parameter and creates an event "move_task"usingthis.pushEvent` function and passes these two parameters as an object.

• At last but not least we will include our TrelloBoard hook in our LiveSocket. For this, we will open the app.js file and import TrelloBoard and include it in our Hooks object, and add the Hooks to our LiveSocket constructor as follows.

    import TrelloBoard from "./trello_board"
    let Hooks = { TrelloBoard }

    let liveSocket = new LiveSocket("/live", Socket, {params: {_csrf_token: csrfToken}, hooks: Hooks }) 
    # Notice `hooks: Hooks`

Calling the Hook

To call our Javascript logic i.e hook we’ll add the phx-hook attribute on the Trello board with value as the hook name i.e TrelloBoard where we want to perform our drag-drop operations.

<div class="board" id="trello-board" phx-hook="TrelloBoard">
  <ul class="list" id="planning">
    <div class="list-header"> Planning </div>
      .........
      .........
      .........
   // Remaining UI code
</div>

Handling move_task event in LiveView

• In our javascript hooks onEnd callback we created a pushEvent named move_task which also sends target and taskId.

• In LiveView, the events which are sent by the client using pushEvents can be handled using handle_event.

• Open the home_live.ex file and add the following function.

  defmodule TrelloAppWeb.HomeLive do
     .........
     .........
     .........
  
    def handle_event("move_task", %{"target" => target, "taskId" => taskId}, socket) do
        Project.change_task_state(taskId, target)
        {:noreply, socket}
    end
  end

• As you can see in this handle_event function we are extracting target and taskId using pattern matching.

• Later, we used the change_task_state/2 function(which we created in Part 1 of this blog series) and passed the taskId and target parameters to the function.

• This not only moves the card in UI but also persists the state in the database.

This completes the second blog of this series. In this part, we build the board, add tasks UI along with drag and drop functionality and integrated the board with our API layer. In the next part, we will make our Trello board in real-time. I hope you like this blog. If you have any questions then please comment below. Thanks for reading 😊.

References

• Github Repo

• Sortablejs

What are going to build?

We are going to build a Trello look-alike board. It will have different cards belonging to different sections. We can drag and drop cards to different sections with a smooth transition. Along with the drag-and-drop transition of cards to different sections, the whole experience will be real-time. If any user makes any change in the card section then any other user watching the application screen doesn't have to explicitly refresh the browser to see the effect. Refer to the gif below to get an idea.

Blog series!!!

This is a 3 part blog series.

• Part 1: We will be generating the application, adding the different tables, and the API layer, and we will test the API layer in the iex shell (This is Part 1)
• Part 2: We will build the board, add tasks UI, and integrate the board with the functions (API) we created in Part 1
• Part 3: We will be adding real-time behavior to our board (under development)

Action Plan

• Creating a LiveView project
• Adding User and Task Tables.
• Adding Task and User struct
• Designing the API Layer

Let's start building 👷

Creating LiveView project

• First of all, our system should have Elixir installed. We can confirm this by running Elixir -v.
• Once confirmed we need to create/generate the Phoenix LiveView application.
• This can be done by running mix phx.new trello_app --live
• if you get this error

  ** (Mix) The task "phx.new" could not be found
  Note no mix.exs was found in the current directory
  

  Then run mix archive.install hex phx_new
• Then navigate to project directory cd trello_app and run mix phx.server. Once, the project starts running navigate to localhost:4000 to see the welcome phoenix screen.

Adding User and Task Tables.

• As per our requirement, we have two entities that need to be created, the card and the user to which this card belongs. We will call these cards Task.
• So, we will add two tables the User table and the Task table.
• Let's add migration files for these two Tables.
• For the sake of clarity we will add two separate migration files for these two tables.
• For User table run mix ecto.gen.migration create_user and for Task table run mix ecto.gen.migration create_task

• Now open trello_app/priv/repo/migrations/{{some_time_stamp}}_create_user.exs migration file at and the add following fields in the migration file.

  defmodule TrelloApp.Repo.Migrations.CreateUser do
    use Ecto.Migration
  
    def change do
       create table(:users) do
          add :first_name, :string, null: false
          add :last_name, :string, null: false
  
          timestamps()
       end
    end
  end
  

• Similarly for task table open trello_app/priv/repo/migrations/{{some_time_stamp}}_create_task.exs migration file and the following fields

  defmodule TrelloApp.Repo.Migrations.CreateTask do
     use Ecto.Migration
  
     def change do
        create table(:tasks) do
           add :title, :string, null: false
           add :description, :text
           add :user_id, references(:users)
           add :state, :string, null: false
  
           timestamps()
       end
   end
  end
  

• Now we will now run the command mix ecto.migrate. This will create tables User and Task in the database.

Adding Task and User struct

• We have created User and Task tables now we are going to add User and Task structs so that we can use Ecto queries effectively.
• First, we will add the Task struct. For that we will create a file trello_app/lib/trello_app/organization/task.ex.

• Add the following code to the file.

  defmodule TrelloApp.Organization.Task do
    use Ecto.Schema
    import Ecto.Changeset
  
    alias TrelloApp.Organization.{ Task, User }
  
    schema "tasks" do
       field :title, :string
       field :description, :string
       field :state, :string
  
       belongs_to :user, User
  
       timestamps()
    end
  
    def changeset(%Task{} = task, attrs) do
      task
      |> cast(attrs, [:title, :description, :state, :user_id])
    end
  end
  

• Similarly, we will add the User struct in the same organization directory with a file name user.ex.

• We will add a similar code here as well.

  defmodule TrelloApp.Organization.User do
    use Ecto.Schema
    import Ecto.Changeset
  
    alias TrelloApp.Organization.{ Task, User }
    schema "users" do
      field :first_name
      field :last_name
  
      has_many :task, Task
      timestamps()
    end
  
    def changeset(%User{} = user, attrs) do
       user
       |> cast(attrs, [:first_name, :last_name])
    end
  end
  

• In the above code, both the structs i.e User and Task has fields defined in the schema macro similar to the migration files.
• We've also defined the relationship between the structs(Tables). It is a one-to-many relationship between User and Task which means User can have many Task. We've also defined the changeset functions for manipulating the data.
• Now, to test if everything is working fine we will add some dummy data in both the tables using the iex shell.
• Open the terminal and navigate to the root directory level of the project. Now run the iex shell by typing iex -S mix.
• Now alias both the structs and Repo to avoid typing long struct names.

  alias TrelloApp.Organization.{ Task, User }
  

• First, we will insert the User record for that we will run the following code.

  User.changeset(%User{}, %{first_name: "Michael", last_name: "Jordan"}) 
  |> Repo.insert
  
  User.changeset(%User{}, %{first_name: "Andrew", last_name: "Flintoff"}) 
  |> Repo.insert
  

• This will insert two User's records with id of 1 and 2.

• Similarly, we will add a few Task records for both users but with different states. For testing purposes, we will add four tasks with the states "planning", "progress", and "completed".

  %Task{} 
  |> Task.changeset(%{title: "Designing API", description: "designing api", state: "planning", user_id: 1}) 
  |> Repo.insert
  
  %Task{} 
  |> Task.changeset(%{title: "Take Backup", description: "take backup", state: "progress", user_id: 2}) 
  |> Repo.insert
  
  %Task{} 
  |> Task.changeset(%{title: "Add Migrations", description: "write migrations", state: "progress", user_id: 1}) 
  |> Repo.insert
  
  %Task{} 
  |> Task.changeset(%{title: "Write Script", description: "write script", state: "completed", user_id: 2}) 
  |> Repo.insert
  

• After running the above queries we will have one User record and three Task records.

Designing the API Layer

• As per our requirement we only want two functions in our API Layer, which are get_grouped_tasks and change_task_state.

• What get_grouped_tasks will do?

• If you remember in the Task struct we have a state field. We've added three tasks records with state planning, progress, and completed.
• We want our tasks should be grouped (as per the state mentioned in the task) and placed in the respective states column.
• In this function, we will have three stages of data transformation
  • Fetch all tasks
  • Preload the owner of the tasks (Just for beautification of the task to mention the owner of the task)
  • Grouping the tasks
• Below is the code of the above pseudo-code.

  def get_grouped_tasks() do
    Task
    |> Repo.all()
    |> Repo.preload(:user)
    |> Enum.group_by(fn %{state: state} -> state end)
  end
  

• Our second method will be change_task_state.

• What change_task_state will do?

  
• When we move our task (say) from Progress to Completed, we want to change the state field of the task from progress to completed.
• This function will take two parameters task_id and transition_state i.e the column we want our task should be moved.
• In this function, we will have three stages of data transformation
  • Get task by task_id parameter
  • Change the state of the task as per provided transition_state using changeset function in Task struct
  • Update the Task
• Below is the code of the above pseudo-code.

  def change_task_state(task_id, transition_state) do
    Task
    |> Repo.get(task_id)
    |> Task.changeset(%{state: transition_state})
    |> Repo.update
  end
  

• We are going to place both functions in a separate module organization.ex under trello_app/lib/trello_app folder.

• This module will be the provider of the two functions, which we will use in the LiveView module later.

  defmodule TrelloApp.Organization do
    alias TrelloApp.Repo
    alias TrelloApp.Organization.Task
  
    def get_grouped_tasks() do
      Task
      |> Repo.all()
      |> Repo.preload(:user)
      |> Enum.group_by(fn %{state: state} -> state end)
    end
  
    def change_task_state(task_id, transition_state) do
      Task
      |> Repo.get(task_id)
      |> Task.changeset(%{state: transition_state})
      |> Repo.update
    end
  end
  

Testing the API Layer in the iex shell

• We've created our Task and User structs as well as designed our API Layer. Let's test the API Layer in the iex shell.
• If you remember, we've added a few records of task and user.
• So, as per our API layer, we have to functions get_grouped_tasks/0 and change_task_state/2. First, we will test get_grouped_tasks/0,
• For testing, we will alias the Organization module

    alias TrelloApp.Organization
  

• Now run Organization.get_grouped_tasks(), this will return grouped tasks as per their states

  %{
  "planning" => [
      %TrelloApp.Organization.Task{
        __meta__: #Ecto.Schema.Metadata<:loaded, "tasks">,
        description: "designing api",
        id: 2,
        inserted_at: ~N[2022-08-25 09:30:08],
        state: "planning",
        title: "Designing API",
        updated_at: ~N[2022-08-25 09:30:08],
        user: %TrelloApp.Organization.User{
          __meta__: #Ecto.Schema.Metadata<:loaded, "users">,
          first_name: "Michael",
          id: 1,
          inserted_at: ~N[2022-08-25 08:45:25],
          last_name: "holding",
          tasks: #Ecto.Association.NotLoaded<association :tasks is not loaded>,
          updated_at: ~N[2022-08-25 08:45:25]
        },
        user_id: 1
      }
  ],
  "progress" => [
      // two tasks under progress
      %TrelloApp.Organization.Task{ id: 2 },  
      %TrelloApp.Organization.Task{ id: 3 }
   ],
   "completed" => [
      // one task under completed
      %TrelloApp.Organization.Task{id: 4}
   ]
  }
  

• We got one task for planning, one task for completed, and two for progress. This is exactly as per the tasks we added with different states.
• So far so good, now we will test change_task_state for first task i.e id=1.
• change_task_state/2 expects two parameters task_id and transtion_state.
• We will move our task with id=1 to the completed state. So, we will run Organization.change_task_state(1, 'completed') in our shell.
• This will transition our task of id=1 to the completed column. We can test this by again running the get_grouped_task. It will not return the planning group since there is no task left with the planning state.

This completes the first blog of this series. In the next part as per our planning, we will build the board, add tasks UI along with drag and drop functionality and will integrate the board with our API layer. I hope you like this blog. If you have any questions then please comment below. Thanks for reading 😊.

References

• Github Repo

The podcast was about my blog Fetching data from external Graphql API service in Phoenix LiveView. We discussed Elixir, LiveView, Graphql, and its testing. I really enjoyed being on the podcast and discussing Elixir with the team.

This is the link to the podcast if you are interested in listening and I hope you'll like the podcast.

References

• My Podcast
• Elixir Mix
• Graphql Blog

What is a Toast?

Toasts are non-interactive, passive, and asynchronous short messages for users. Generally, they are used as an interface feedback pattern for informing the user about the results of an action. This is the most bookish answer about what is a Toast. In the easiest form, it is a popup that provides simple feedback about an operation.

How our toaster should work?

As per definition, a toaster is a popup that provides feedback about an operation. For example, if the user tries to submit a form by clicking the submit button. The user should get feedback after the submission as "Your account is created successfully". In our LiveView application, we want this event(toaster display) should happen after some operation. We are going to call our toaster display logic through pushEvent after that operation. So, our toaster generation logic will be as follows

• After any operation in Elixir code we will trigger the push_event
• The push_event will be handled by the handleEvent handler in the javascript Hook
• This pushEvent handler will ultimately trigger the toaster popup.

Now, that we are ready with our roadmap let's start building 👷

Finding javascript Toaster library

I wanted a vanilla javascript library that should be lightweight and highly supportive in the js community. While doing some research I came across toastify-js. Let's install it in the application. Navigate to the assets directory by running cd assets then run

  npm install toastify-js

Adding the toaster styling

• We need to import toastify styles in our app.css by adding the following line

  @import "../node_modules/toastify-js/src/toastify.css";
  

• Next, we will add a javascript hook.

Adding Javascript Hook

After installing toastify we will then add the javascript logic. We will add a mounted callback, which is called and initialized with some initial value as soon as the element on which we are applying it is mounted in the DOM. As we have discussed that our toaster should be called after our elixir code will trigger handle_event. So, we will add our event handler in our mounted callback.

• Let's add a file in message_toaster.js in assets/js folder.
• Add a mounted callback with an handleEvent named toast.

import Toastify from 'toastify-js'

MessageToaster = {
  mounted() {
    this.handleEvent('toast', (payload) => {
      Toastify({
        text: payload.message,
        duration: 3000
        }).showToast();        
    })
  }
}
export default MessageToaster

• We will import Toastify and use it in the handleEvent.
• In the handleEvent, we have a callback function with a payload param. It will have a custom message which will be used in the Toastify.

• At last but not least we will include our MessageToaster hook in our LiveSocket. For this, we will open the app.js file and import MessageToaster and include it in our Hooks object, and add the Hooks to our LiveSocket constructor as follows.

    import MessageToaster from "./message_toaster"
    let Hooks = { MessageToaster }
  
    let liveSocket = new LiveSocket("/live", Socket, {params: {_csrf_token: csrfToken}, hooks: Hooks }) 
    # Notice `hooks: Hooks`
  

Registering the Hook

• To call our Javascript logic i.e hook we’ll add the phx-hook attribute on the root page with value as the hook name i.e MessageToaster. We will add our phx-hook="MessageToaster" on the live.html.heex page.

• Add the following code

  # lib/project_name_web/templates/layout/live.html.heex
  <div phx-hook="MessageToaster">
       <%= @content %>
  </div>
  

Calling the Toaster

• As discussed we are going to call our toaster from Elixir code after a certain event. For testing purposes, we are going to add a button in one of our LiveView's HTML code as follows

  # live/user_registration_live.html.heex
  <button phx-click="submit_form">Register User</button>
  

• Then we will add handle_event for the submit_form

  def handle_event('submit_form', params, socket) do
    # Form submission logic
  end
  

• In the handle_event after our form submission logic we will make handle_event

    def handle_event("submit_form", params, socket) do
        # Form submission logic
        ....
        ....
        ....
       {:noreply, push_event(socket, "toast", %{message: "Your record has been created successfully"})}
    end
  

• Final working DEMO is as follows

I hope you like this blog. If you have any questions then please comment below. Thanks for reading 😊.

References

• Cover Image
• Toastify.js

NOTE: Jump to Highlighting the current menu (Dirty Solution) section if you already have a project with Navbar.

Let's start building

• First of all, we should have a LiveView project or will create a new LiveView project by running mix phx.new navigation_demo --no-ecto --live

• We will then navigate to the project directory by running cd navigation_demo and run mix phx.server. Once, the project starts running navigate to localhost:4000 to see the Welcome phoenix screen.

Adding liveview pages

• To demonstrate the navbar highlighting logic in Elixir, we will first add three items to the navbar menu with minimal functionality.

• For this open router.ex and following routes

live "/", HomePageLive, :index
live "/page1", Page1Live, :index
live "/page2", Page2Live, :index

• Now go to live folder and add three files home_page_live.ex, page1_live.ex, and page2_live.ex.

• Add mount and render callbacks in each of the following with minimal text. Refer following code for reference

   // home_page_live.ex
   defmodule NavigationDemoWeb.HomePageLive do
      use NavigationDemoWeb, :live_view

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

      def render(assigns) do
         ~H"""
            Home page
         """
     end
   end

   // page1_live.ex
   defmodule NavigationDemoWeb.Page1Live do
      use NavigationDemoWeb, :live_view

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

      def render(assigns) do
       ~H"""
          Page 1
        """
      end
    end

    // page2_live.ex
    defmodule NavigationDemoWeb.Page2Live do
        use NavigationDemoWeb, :live_view

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

        def render(assigns) do
         ~H"""
            Page 2
         """
        end
    end

• Adding of LiveView pages is done, now we will add a navigation menu with minimal styling.

Add Navbar menu

• Before adding the Navbar menu we will do some cleanup in our existing code.

• Open templates/layout/root.html.heex and remove all code in the body tag and just add the following code

  <body>
      <%= @inner_content %>        
  </body>

• Open the live.html.heex file and add the following code

  <nav>
     <h3>NavBar Test</h3>
     <ul>
        <li><%= live_patch "Home", to: Routes.home_page_path(socket, :index)%></li>
        <li><%= live_patch "Page 1", to: Routes.page1_path(socket, :index)%></li>
        <li><%= live_patch "Page 2", to: Routes.page2_page_path(socket, :index)%></li>
      </ul>
  </nav>

* Open `app.css` and add the following styling

    ```css
    nav { display: flex; justify-content:space-between; align-items: center; padding: 1rem 2rem; background: #cfd8dc; }

    nav ul { display: flex; list-style: none; }

    nav li { padding-left: 1rem; }

    nav a { text-decoration: none; color: lightblue }

    .active { background: red; }

• The resulting home page will be as follows

  ![Screenshot 2022-06-11 at 12.34.14 PM.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1654931128407/bdL8-r1Wh.png align="left")

But, now here the problem starts if you will notice the `home` page in the navbar does not have any kind of indication that it is the currently selected menu.

Highlighting the current menu (Dirty Solution)

• The easiest solution can be using the `handle_params` callback in each LiveView file and assigning some variable say `current_path` to the socket struct which will be accessible in the `live.html.heex`

def handle_params(_params, url, socket) 
   {:noreply, socket |> assign(current_path, URI.parse(url).path)} 
end

• In the live.html.heex, add the following logic

  ```

    <%= live_patch "Home", to: Routes.home_page_path(socket, :index)%>
  
    <%= live_patch "Page 1", to: Routes.page1_path(socket, :index)%>
  
    <%= live_patch "Page 2", to: Routes.page2_page_path(socket, :index)%>
  

• This will work, but it will become very cumbersome when there are more tabs. Also, this approach is not DRY.

Highlighting the current menu (Improved Solution)

• The above solution is not very DRY. We can improve this code using the concept of on_mount and attach_hook.

• We want that every time when the user changes the menu in our app it should trigger handle_params. Also, we don't want handle_params to be placed in every LiveView.

• We can add custom behavior to other callbacks using attach_hook.

• So, we'll register this callback i.e handle_params to the socket struct, something like this.

socket |> attach_hook(:set_menu_path, :handle_params, &manage_active_tabs/3)

• In the above code,

  • :set_menu_path is the hook name

  • :handle_params is the callback

  • manage_active_tabs is the function body of handle_params

• This hook will be assigned to socket struct and this will be done in the on_hook function.

• We'll attach these hooks via Phoenix.LiveView.Router.live_session.

• We'll add a file live/route_assigns.ex, and we'll mount the RouteAssigns module using on_mount in the router.ex as follows

live_session :default, `on_mount: NavigationDemoWeb.RouteAssigns` do
    scope "/", NavigationDemoWeb do
        pipe_through :browser
        live "/", HomePageLive, :index
        live "/page1", Page1Live, :index
        live "/page2", Page2Live, :index
    end
end

• In on_mount you have access to socket struct. We will assign a menus key with value as a list of tuples of menu name and the route of the menu.

• Refer to the following code

defmodule NavigationDemoWeb.RouteAssigns do
    import Phoenix.LiveView
    alias NavigationDemoWeb.Router.Helpers, as: Routes

    def on_mount(:default, _params, _session, socket) do
      socket =
        assign(socket,
          menus: [
            {"Home", Routes.home_page_path(socket, :index)},
            {"Page 1", Routes.page1_path(socket, :index)},
            {"Page 2", Routes.page2_path(socket, :index)}
          ]
        )

      {:cont,
        socket
        |> attach_hook(:set_menu_path, :handle_params, &manage_active_tabs/3)
        }
    end

    defp manage_active_tabs(_params, url, socket) do
      {:cont, assign(socket, current_path: URI.parse(url).path)}
    end
end

• Notice cont in the return tuple of on_mount and manage_active_tabs functions. The hook has the option to either halt or continue the process.

• In our handle_params callback function i.emanage_active_tabs we will assign current_path field to socket struct. This field will help us to select the current menu.

• Because of assigning menus to the socket variable it will be accessible in the live.html.heex file.

• We can iterate over it i.e menus, with the first element of the tuple as the link name and the second element as the path. Refer to the code below

// live.html.heex
<ul>
    <%= for {menu_name, path} <- @menus do %>
      <li class={"#{if path == @current_path, do: "active"}"}>
        <%= live_patch menu_name, to: path %>
      </li>
    <% end %>
</ul>

• In the above code, you can notice the if condition which applies active if @current_path is equal to the path of the menu.

• The active class applied a background of red color to highlight the selected menu.

I know the blog was very conceptual with lots of information. I hope I did justice with the explanation and you like this blog. If you have any questions then please comment below. Thanks for reading 😊.

What is Infinite Scroll?

Before we start, we first need to understand how Infinite scroll works. To get a fair idea about Infinite Scroll, refer to the gif image below.

This is similar to what we see on Youtube, Facebook, Instagram, etc. It keeps user engage in the content and also keep away user from the hassle of clicking the Next button to load content.

How Infinite Scroll works?

Infinite Scroll logic is very simple, we just have to add a javascript event listener which will listen to the scroll event. It will get triggered as soon as we reach the bottom (near the bottom) of the page. Below is the logic to detect the bottom of the page.

let scrollAt = () =>
  let scrollTop = document.documentElement.scrollTop || document.body.scrollTop
  let scrollHeight = document.documentElement.scrollHeight || document.body.scrollHeight
  let clientHeight = document.documentElement.clientHeight
  return scrollTop / (scrollHeight - clientHeight) * 100
}

We just need to call this logic in the proper LiveView lifecycle and this can be achieved with LiveView JS Hooks.

What is JS hook?

Phoenix LiveView often markets itself as that we can create reactive apps without writing JavaScript. But still, there comes a time when you have to write javascript. To integrate Javascript in our LiveView app, LiveView provides us with a concept of LiveView JS Hooks. JS Hooks allow us to register JavaScript lifecycle callbacks on DOM nodes.

How does JS Hook work?

There are different types of lifecycle callbacks like mounted, reconnected, and updated. The mounted is the first callback that is called and initialized with some initial value as soon as the element on which we are applying it is mounted in the DOM. So, here we will add our addEventListener and initialize some value. We will create a new file for our hook file in assets/js/infinite_list.js and add the following code.

let scrollAt = () => {
  let scrollTop = document.documentElement.scrollTop || document.body.scrollTop
  let scrollHeight = document.documentElement.scrollHeight || document.body.scrollHeight
  let clientHeight = document.documentElement.clientHeight

  return scrollTop / (scrollHeight - clientHeight) * 100
}

InfiniteList = {
  page() { return this.el.dataset.page },
  mounted(){
    this.pending = this.page()
    window.addEventListener("scroll", e => {
      if(this.pending == this.page() && scrollAt() > 90){
        this.pending = this.page() + 1
        this.pushEvent("load-blogs", {})
      }
    })
  },
  reconnected(){ this.pending = this.page() },
  updated(){ this.pending = this.page() }
}

export default InfiniteList

As discussed mounted callback is a place where we will add eventListener logic. It detects page bottom and triggers pushEvent of load-blogs. This will call handle_event callback in our lib/fetch_hashnode_web/live/blogs_live.ex which will have the following code logic.

def handle_event("load-blogs", _params, socket) do
    page_no = socket.assigns.page_no + 1
    new_blogs = page_no |> Blog.get_blogs
    blogs = socket.assigns.blogs ++ new_blogs
    socket = assign(socket, blogs: blogs, page_no: page_no)
    {:noreply, socket}
end

The logic here is self-explanatory we are fetching blogs using Blog.get_blogs by passing incremented page_no to it and assigning the blogs to the socket struct.

Adding temporary_assigns

One last change we have to make in the blogs_live.ex code. We have to use temporary_assigns for our blogs field in the mount callback. When we assign new blogs to socket.assigns.blogs there are chances that our data can grow, which will increase data in the socket, and ultimately our application performance will be affected. Refer to the following change

def mount(_params, _session, socket) do
    blogs = Blog.get_blogs()
    socket = assign(socket, blogs: blogs, page_no: 0)
    {:ok, socket, temporary_assigns: [blogs: []]}
end

Adding the hook in LiveSocket

Now we will include our InfiniteList hook in our LiveSocket. For this, we will open the app.js file and import InfiniteList and include it in our Hooks object, and add the Hooks to our LiveSocket constructor.

import InfiniteList from "./infinite_list"

let Hooks = { InfiniteList }
....
let liveSocket = new LiveSocket("/live", Socket, {params: {_csrf_token: csrfToken}, hooks: Hooks }) 
// Notice `hooks: Hooks`

Now that we have added our InfiniteList hook to our hooks list. We will call this hook in our final arrangement.

Calling the Hook

To call our Javascript logic i.e hook we’ll add the phx-hook attribute on the div with value as the hook name i.e InfiniteList where we want to perform scrolling.

<div class="blogs" id="infinite-list" phx-hook="InfiniteList" phx-update="append" data-page={@page_no}>
   <%= for blog <- @blogs do %>
      // Display logic
   <% end %>
</div>

You will also notice the data-page attribute which has the value of @page_no. This attribute is the reason, that we were able to access the page number in the page method of the InfiniteScroll hook.

InfiniteList = {
  page() { return this.el.dataset.page },
  ...

The phx-update=append helps us to append or prepend the updates rather than replacing the existing contents. And don't miss to add the id attribute as well on the div. So, the following is the list of attributes that we need to apply on the div to enable javascript interactions.

• Hooks (phx-hook="InfiniteList")
• phx-update (phx-update=append)
• data attribute (data-page={@page_no})
• id (id='infinite-list')

Conclusion

For performing Infinite scroll we have to

• Create hooks
• Add it to the hooks list in LiveSocket object
• Add hook on the div where you want to perform scrolling so that it can communicate with the javascript.

I hope you like this blog. If you have any questions then please comment below. Thanks for reading 😊.

References

• Cover Image
• Infinite Scroll GIF
• JS Logic for detecting bottom screen

Action Plan

• Creating LiveView project
• Installing and configuring graphql client.
• Adding API layer to fetch data.
• Integrating API layer with UI

Let's start building 👷

• First of all, as discussed will create a LiveView project.
• We will confirm if Elixir is installed by running elixir -v.
• Once confirmed we need to create/generate the Phoenix LiveView application.
• This can be done by running mix phx.new fetch_hashnode --no-ecto --live and this will generate one.
• We will then navigate to the project directory by running cd fetch_hashnode and run mix phx.server. Once, the project starts running navigate to localhost:4000 to see the Welcome phoenix screen.

Installing Graphql client

• I searched for Graphql client in Elixir and came across a few but the one that caught my eye is Neuron. It is very easy to configure and use so I decided to go with Neuron.
• We will configure Neuron by first adding it to the list of dependencies.
• Open the mix.exs file and add Neuron to the list of dependencies.

  def deps do
  [
   ........,
    {:neuron, "~> 5.0.0"}
  ]
  end
  

• Now run mix deps.get to install the dependency.
• Next, we are going to configure Neuron.

Configure Neuron

• To query Hashnode API, we have to add a url in the Neuron configuration.
• As per documentation we can test Neuron in iex shell by running the following query.

iex> Neuron.Config.set(url: "https://api.hashnode.com/")

• After adding this you can query Hasnode API as follows

Neuron.query("""
{
  user(username: "your_username") {
      publication {
          posts(page: 0) {
              title
              brief
              slug
              cuid
              coverImage
          }
      }
  }
}
""")

• This query will return a Neuron response with a list of blogs on page number 0, along with the nitty-gritty details of header responses, something like below.

{:ok,
 %Neuron.Response{
   body: %{
     "data" => %{
       "user" => %{
         "publication" => %{
           "posts" => [
             %{ } // blog 1,
             %{ } // blog 2
           ]
    }
           ]
         }
       }
     }
   },
   headers: [
     {"Connection", "keep-alive"},
     {"Content-Length", "3186"},
     ......
   ],
   status_code: 200
 }
}

• So far so good, everything is looking fine. In our next step, we'll add an API layer where we'll place the above query to fetch the data.

Adding API layer to fetch data

• We will add a module that will have all two functions one to fetch all blogs and one to fetch specific blogs.
• Create a file a create a folder blog_posts under lib/fetch_hashnode. In that, we'll add the blog.ex file.

• Add the following code to it.

  defmodule  FetchHashnode.Blog do
    @username "your_hashnode_username"
  
    def get_blogs(page \\0) do
      Neuron.query("""
        {
          user(username: "#{@username}") {
            publication {
                posts(page: #{page}) {
                    title
                    brief
                    slug
                    cuid
                    coverImage
                }
            }
          }
        }
      """)
    end
  
    def get_detail_blog(slug) do
      Neuron.query("""
        {
            post(slug: "#{slug}", hostname: "#{@username}") {
            title,
            slug,
            cuid,
            coverImage,
            content,
            contentMarkdown,
            tags {
            name
            }
         }
       }
      """)
   end
  end
  

• The above two functions are self-explanatory. It is simple and very similar to what we have tried earlier in the console.
• Let's fire up the iex shell by running iex -S mix phx.server and do some testing of these functions.
• We'll first test the get_blogs function which expects to return a list of all blogs on page 0 (because the default is 0).
• Run the following query

  iex>  FetchHashnode.Blog.get_blogs
  

• We will get the error " you need to supply an url". So, what went wrong? 🤔
• If you'll remember we registered the url with the Neuron in the shell earlier by doing something like this.

  Neuron.Config.set(url: "https://api.hashnode.com/")
  

• We want Neuron should be aware of this url as soon as the server starts. So, we will add the above snippet in application.ex in the start function.

def start(_type, _args) do
    children = [
      FetchHashnode.Repo,
      ....
   ]
   opts = [strategy: :one_for_one, name: FetchHashnode.Supervisor]

   Neuron.Config.set(url: "https://api.hashnode.com/")  # This is the line
   ...
end

• Now, again restart the server iex -S mix phx.server and again query the function FetchHashnode.Blog.get_blogs and voila!! it's working now.
• Similarly for the second function i.e get_detail_blog we need to pass the slug of the blog. So, we will test the function with some slug like this

FetchHashnode.Blog.get_detail_blog('writing-mix-task-in-elixir-phoenix')

• This will return a detailed version of the blog.

Integrating API layer with UI

• Now, that we have a working API layer. We will add a LiveView page to display these fetched blogs.
• Add blogs endpoint in router.ex by adding the following code

scope "/", FetchHashnodeWeb do
    pipe_through :browser

    live "/blogs", BlogsLive
end

• Now add a file lib/fetch_hashnode_web/live/blogs_live.ex and add the following mount callback in the code.

  defmodule FetchHashnodeWeb.BlogsLive do
   use FetchHashnodeWeb, :live_view
   alias FetchHashnode.Blog
  
   def mount(_params, _session, socket) do
     {:ok, blogs} = Blog.get_blogs()
     blogs = get_in(blogs.body, ["data", "user", "publication", "posts"])
     socket = assign(socket, blogs: blogs )
     {:ok, socket}
   end
  end
  

• We have aliased the Blog module and queried the get_blogs function in the mount function.
• We have assigned the fetched blogs to the blogs variable using pattern matching.
• Later we have extracted all the blogs and assigned them to socket this will make it available in the view in the render callback.
• We will loop over the blogs variable in the view to display something like this.

  def render(assigns) do
     ~L"""
        <%= for blog <- @blogs do %>
           Title: <%= blog["title"] %> 
           <hr>
        <% end %>
     """
  end
  

• It will look something like below
• Similarly, we can fetch a particular blog and display it on a separate LiveView page. I'll leave this logic up to you 😊.

I hope you like this blog. Of course, there is some scope of refactoring that I intentionally didn't touch. If you have any questions then please comment below. Thanks for reading 😊.

References

• Neuron
• LiveView

How PubSub works? 🤔

Phoenix PubSub is an API that is responsible for doing live updates in the app. The documentation itself says it's a Realtime Publisher/Subscriber service. In application, our LiveView(module) process subscribes to a particular channel(s). When a message is published on a topic, the message is broadcast. Similarly, when a message is published from a topic, the message is broadcast to all the subscribers of that topic. When the broadcast message is received to the subscribed Process their state is updated which ultimately re-renders the view. Below diagram will give you an idea about subscribers and

Subscriber

Publisher

Adding the Subscriber

• We've understood the concept of the subscriber. It will be a function that will be called by the LiveView module.
• The Phoenix.PubSub module has a subscribe function that takes 2 parameters.
  • The PubSub instance of our app, in our case it is NoteApp.PubSub
  • The name of the channel/topic, in our case it is "notes"
• Question arises where do we place this function. Ideally, it should be placed in the context API layer but we haven't created any context API layer. So, we will create a new module lib/note_app/notes/note.ex and the following code.

  defmodule NoteApp.Notes.Note do
    def subscribe() do
       Phoenix.PubSub.subscribe(NoteApp.PubSub, "notes")
    end
  end
  

Publishing/Broadcasting the message

• We know that PubSub has a subscribe function, likewise, it also has a broadcast function in it.
• We have to call this function to publish/broadcast the message.
• As per our requirement we want to publish the message(note) as soon as we create the note.
• So our logic will reside in our create_note callback just after creating the note.
• We need to pass the message as a tuple with the first field as the message name(as an atom) in our case it will be :create_note and the other field is the note created.

lib/note_app/notes/note_server.ex

def handle_cast({:create_note, note}, notes) do
    updated_note = add_id(notes, note)
    updates_notes = [updated_note | notes]

    message = {:note_created, updated_note}

    #broadcast logic -start
    Phoenix.PubSub.broadcast(
      NoteApp.PubSub,
      "notes",
      message
    )
    #broadcast logic -end
    {:noreply, updates_notes}
  end

• The broadcast function takes 3 parameters.
  • The PubSub instance of our app, in our case it is NoteApp.PubSub
  • The name of the channel/topic, in our case it is "notes"
  • The message we want to broadcast.

Subscribing to the Topic/Channel

• Any LiveView process which needs to be updated has to subscribe to the topic/channel.
• We have already created a notes topic.
• Our NotesLists LiveView needs to subscribe to this topic/channel.
• This is achieved very easily, we just need to add call the subscribe function in the mount callback.
• But there is a caveat, we can only call the subscribe function when our LiveView is connected to socket. Also, we need to alias the Note module to use lib/note_app_web/live/notes_index_live.ex

  defmodule NoteAppWeb.NotesIndexLive do
    alias NoteApp.Notes.Note
    def mount(_params, _session, socket) do
         if connected?(socket), do: Note.subscribe()
         .....
         .....
         .....
    end
  end
  

• We know LiveView is nothing but a GenServer process, so when the publisher broadcasts the message our LiveView process needs to handle that message. We will achieve that with the handle_info callback in our NotesList LiveView module. Add the following function in the module.

lib/note_app_web/live/notes_index_live.ex

  defmodule NoteAppWeb.NotesIndexLive do
        ........
        ........
        ........

       def handle_info({:note_created, note}, socket) do
           socket = update(socket, :notes, fn notes -> [note | notes] end)
           {:noreply, socket}
      end
  end

• We pattern match the broadcast message and retrieve the note and update the notes list in the socket with the latest message.

I hope you like this easy implementation of using Phoenix PubSub for achieving live updates. If you have any questions then please comment below.

References:

• Project Repo
• Cover Image

Plan of attack

• We are going to add different LiveView routes ✓

• We will implement List page displaying all notes ✓

• Implement detail page for note ✓

• Add update and delete action for the note ✓

• Add create note form ✓

• We will be integrating the API with each of these actions. ✓

Let's start adding routes definition 🚧

• As discussed we are going to have 3 routes.

• One for "List", "detail" and one for "create".

• For adding route open lib/note_app_web/router.ex file and add following code.

scope "/", NoteAppWeb do
    pipe_through :browser

    # These are the new routes
    live "/", NotesIndexLive
    live "/notes/new", NotesNewLive
    live "/notes/:id/edit", NotesEditLive
  end

• live is a macro that requires 3 arguments, in this case, we are passing 2.

  1. Endpoint URL

  2. Module name of the liveview file associated with that endpoint.

• So, we are going to have 3 modules in the folder lib/note_app_web/live. They are

  1. notes_index_live.ex

  2. notes_new_live.ex

  3. notes_edit_live.ex.

• These routes are self-explanatory as per the name.

Add Notes List page ✅

• Every live module acts like a controller, which is invoked as soon as we hit the route associated with that live file.

• Every live file starts with the mount function which acts like a constructor (in OOP sense). It takes 3 parameters

  • params =>params has URL parameter specific data.

  • session => User session specific information.

  • socket => It acts as a state for every Liveview page.

• It returns the ok tuple with the socket.

• Since, this page is about the list of notes, we are going to query our GenServer about the list of notes it has.

• We are going to assign queried list of notes and number of notes to the socket variable.

defmodule NoteAppWeb.NotesIndexLive do
    use NoteAppWeb, :live_view
    alias NoteApp.Notes.NoteServer

    def mount(_params, _session, socket) do
       all_notes = NoteServer.all_notes()
       socket = assign(socket, :notes, all_notes)
       socket = assign(socket, :notes_length, Kernel.length(all_notes))
       {:ok, socket}
    end
end

• As you will notice we have alias the NoteServer module i.e GenServer. If you remember there is an all_notes function in it. We have called it and assigned it to the all_notes variable.

• Using the assign function we have assigned these notes to the notes variable.

• Similarly, we have assigned the number of notes to the notes_length variable.

• Now our data is ready, now we need to render the view.

• For that Liveview has a render function. We have our list of notes and their count we are going to display it in this render function.

   ~L"""
      <div class="notes">
        <div class="notes-header">
            <h2 class="notes-title">&#9782; Notes</h2>
            <p class="notes-count"><%= @notes_length %></p>
        </div>

        <div class="notes-list">
          <%= for note <- @notes do %>
            <%= live_patch to: Routes.live_path(@socket, NotesEditLive, note.id) do %>
              <div class="notes-list-item">
                <h3><%= note.title %></h3>
                <p><%= note.body %></p>
              </div>
            <% end %>
          <% end %>
        </div>

        <%= live_patch "+", to: Routes.live_path(@socket, NotesNewLive), class: "floating-button" %>
      </div >
    """

• This HTML code has lots of styling which you can copy from the assets/app.css file in the project repo of this blog.

• Rest displaying the logic of the list of notes is simple, we are just iterating over the @notes variable and displaying it under the notes-list-item div.

• There is live_patch helper defined twice in the view. One is used to navigate to the detail page of the particular note. The other navigate to the create page.

• This function takes the Route.live_path value which says where we are going to navigate and its associated params.

• So we are passing the NotesEditLive and NotesNewLive as value to these helpers.

Add detail page for note along with edit ✄ and delete ✕ action

• Detail page is where we are going to display detail of the note title and its body.

• We have a separate LiveView file for it as well i.e NotesEditLive.

• We are going to add two actions update and delete in the view.

• We have these two methods in our NoteServer module as well.

• If you remember we added live_patch link to naviate to the details page. We passed Routes.live_path(@socket, NotesEditLive, note.id) to the live_patch helper.

• The note.id in the live_path function is nothing but path param for the detail page which generates URL something like this notes/1/edit.

• Inside the details LiveView mount function we are going to fetch this id from the params parameter of the mount function.

• Using this id we are going to fetch a particular note.

• In file lib/note_app_web/live/notes_new_live.ex we are going to add following mount function.

defmodule NoteAppWeb.NotesEditLive do
    alias NoteAppWeb.NotesIndexLive
    use NoteAppWeb, :live_view
    alias NoteApp.Notes.NoteServer

    def mount(%{"id" => id}, _session, socket) do
       note = NoteServer.get_note(String.to_integer(id))
      {:ok, assign(socket, :note, note)}
    end

• Similarly, we are going to add our view in the render function. There we have added the form with some handle_events like phx-change to manage change in the inputs and phx-submit to submit the form. (Check References for these handle_events)

• We have added the Delete button with the phx-click event which handles the logic to delete the note.

      def handle_event("delete_note", _value, socket) do
           NoteServer.delete_note(socket.assigns.note.id)
           {:noreply,
              socket
              |> redirect(to: "/")
           }
      end

• Finally, we have phx-submit event that gets called on clicking the Done button, and logic for updating the note is called.

     def handle_event("save_note", _value, socket) do
           NoteServer.update_note(socket.assigns.note)
          {:noreply,
             socket
             |> redirect(to: "/")
           }
      end

• The final working code for the Notes detail Liveview is below.

defmodule NoteAppWeb.NotesEditLive do
    alias NoteAppWeb.NotesIndexLive
    use NoteAppWeb, :live_view
    alias NoteApp.Notes.NoteServer

    def mount(%{"id" => id}, _session, socket) do
       note = NoteServer.get_note(String.to_integer(id))
      {:ok, assign(socket, :note, note)}
    end

    def render(assigns) do
      ~L"""
        <div class="note">
            <div class="note-header">
               <h3>
                    <%= live_patch "<", to: Routes.live_path(@socket, NotesIndexLive) %>
               </h3>
               <button type="submit" form="create-note-form">Done</button>
               <button phx-click="delete_note">Delete</button>
             </div>

             <form id="create-note-form" phx-change="detect_change" phx-submit="save_note">
                <input type="text" placeholder="Add Title" value="<%= @note.title %>" name="title"/>
                 <br>
                 <br>
                 <textarea placeholder="Add note" name="body"><%= @note.body %></textarea>
             </form>
          </div >
       """
      end

      def handle_event("detect_change", %{"title" => title, "body" => body}, socket) do
          updated_note = %{socket.assigns.note | title: title, body: body}
         {:noreply, assign(socket, :note, updated_note)}
      end

      def handle_event("save_note", _value, socket) do
           NoteServer.update_note(socket.assigns.note)
          {:noreply,
             socket
             |> redirect(to: "/")
           }
      end

      def handle_event("delete_note", _value, socket) do
           NoteServer.delete_note(socket.assigns.note.id)
           {:noreply,
              socket
              |> redirect(to: "/")
           }
      end
end

Add page for creating a new note

• The only part that is remaining is the creation of note.

• The form on the /new endpoint is very similar to the details page.

• We are navigating to this page by passing NotesNewLive module to live_path. Routes.live_path(@socket, NotesNewLive)

• In this LiveView module we are going to initialize empty variables title and body for the form and will use them in the render function.

• Similar to the edit page we will have handle_events on saving the form where we are going to call the create_note function from our GenServer API.

defmodule NoteAppWeb.NotesNewLive do
  use NoteAppWeb, :live_view
  alias NoteApp.Notes.NoteServer
  alias NoteAppWeb.NotesIndexLive

  def mount(_params, _session, socket) do
    socket = assign(socket, title: "", body: "")
    {:ok, socket}
  end

  def render(assigns) do
    ~L"""
    <div class="note">
      <div class="note-header">
        <h3>
          <%= live_patch "<", to: Routes.live_path(@socket, NotesIndexLive) %>
        </h3>
        <button type="submit" form="create-note-form">Done</button>
      </div>

      <form id="create-note-form" phx-change="detect_change" phx-submit="save_note">
        <input type="text" placeholder="Add Title" value="<%= @title %>" name="title"/>
        <br>
        <br>
        <textarea placeholder="Add note" name="body"><%= @body %></textarea>
      </form>
    </div >
    """
  end

  def handle_event("detect_change", %{"title" => title, "body" => body}, socket) do
    {:noreply, assign(socket, title: title, body: body)}
  end

  def handle_event("save_note", _value, socket) do
    new_note = %{id: nil, title: socket.assigns.title, body: socket.assigns.body}
    NoteServer.create_note(new_note)
    {:noreply,
         socket
         |> redirect(to: "/")
    }
  end
end

So, that's our complete LiveView implementation of all CRUD functions. There is some scope of refactoring in the app like creating components for common code (which I will cover in another blog 😉). The main purpose of the blog was to introduce the concept of GenServer and LiveView. I hope you like this blog. If you have any questions then please comment below.

References:

• Project Repo

• LiveView

• handle_events