Trello cards help you to collaborate, manage projects, and reach new productivity peaks(As per their official Website 😊). You may have used it earlier or some similar board like Jira to manage projects and tasks. When I joined one of my previous organizations, my training was tracked using the Trello board which helped me and other new joiners in learning and track our progress. In this Blog, we are about to create a similar board with a real-time update feature.
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
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" => [
%TrelloApp.Organization.Task{ id: 2 },
%TrelloApp.Organization.Task{ id: 3 }
],
"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
