DEV Community: Hoon Wee

Every Neovim, Every Config, All At Once

Hoon Wee — Wed, 06 Mar 2024 00:26:24 +0000

Neovim is hot 🔥 right now

Neovim, a successful fork of Vim, is a text editor that is gaining popularity. I won't link David Heinemeier Hansson's blog post again since everyone has done it already.

I also won't list all the good stuff about Neovim, since you can find them on the official website and tons of blog posts.

You can build your own IDE, or should I say, own IDEs(plural)

Just by learning a super-easy Lua language, you can build your own IDE with Neovim. If you're a busy person, you can just copy and paste someone else's config.

You can also find a fully-plugged IDE level config like:

All you have to do is to clone the repo and paste it in your ~/.config/nvim directory.

# Backup your current config
mv ~/.config/nvim ~/.config/nvim.bak

# Clone the repo
git clone <remote repo> ~/.config/nvim --depth 1

# Run neovim
nvim

But what if you want to use multiple configs at the same time?

The answer is simple. All you need to set is the NVIM_APPNAME environment variable.

Example: Using LunarVim and NvChad at the same time

Let's say you want to use LunarVim for your web development and NvChad for your data science work.
You should first clone both repos with their custom directory names.

# Clone LunarVim
$ git clone git@github.com:LunarVim/LunarVim.git ~/.config/lunarvim --depth 1

# Clone NvChad
$ git clone https://github.com/NvChad/NvChad ~/.config/nvchad --depth 1

Then, you can set the NVIM_APPNAME environment variable to use each config.

# Run neovim with LunarVim
$ NVIM_APPNAME=lunarvim nvim

# Run neovim with NvChad
$ NVIM_APPNAME=nvchad nvim

You can still use the default config by just running nvim without setting the NVIM_APPNAME environment variable. (This reads the config from ~/.config/nvim)

# Run neovim with the default config
$ nvim

Example: Make aliases for each config

You can also make aliases for each config.

# Add these lines to your .bashrc or .zshrc

alias lunarvim="NVIM_APPNAME=lunarvim nvim"
alias nvchad="NVIM_APPNAME=nvchad nvim"

# Run neovim with LunarVim
$ lunarvim

Conclusion

That's it! You can use multiple Neovim configs at the same time, with just a simple environment variable NVIM_APPNAME.

Now, some might say "Why don't you just use Docker?". Well, not everyone is comfortable with Docker, and since Neovim just supports this feature, why not use it?

I hope this tip helps you to use Neovim more effectively. Happy hacking! 🚀

How to cast & validate map-typed Ecto schema field

Hoon Wee — Fri, 01 Mar 2024 15:04:09 +0000

Problem

Let's go straight to the problem. Suppose you have a Post schema, defined as follows:

# lib/my_app/post.ex

defmodule MyApp.Post do
  use Ecto.Schema
  import Ecto.Changeset

  schema "posts" do
    field :title, :string
    field :content, :string
    field :location, :map
  end
end

We have a location field in Post schema, which is a :map type. :map is often used when you want to store a simple set of key-value pairs, but don't want to create a separate database table for it.

But how do we cast and validate the location field? We can't use Ecto.Changeset.cast/3 directly, because it only works with primitive types like :string, :integer, :boolean, etc. Of course we can check that the location field is a map, but how do we validate the keys and values of the map?

Solution: `Ecto.Changeset.cast_embed/3`

We can use Ecto.Changeset.cast_embed/3 to cast and validate the location field. cast_embed/3 is used to cast and validate embedded associations, but it can also be used to cast and validate map-typed fields.

Let's see how we can use cast_embed/3 to cast and validate the location field. Suppose our location map has to follow these rules:

It can only have keys: :latitude, :longitude and :address
The :latitude and :longitude is required and should be a float
The :address is optional and should be a string

Now we need to change something from the code above - we need to change the type of location field from :map to Location schema. Here's how we can define the Location schema and use cast_embed/3 to cast and validate the location field:

# lib/my_app/post.ex

defmodule MyApp.Post do
  use Ecto.Schema
  import Ecto.Changeset

  schema "posts" do
    field :title, :string
    field :content, :string

    embeds_one :location, Location do
      field :latitude, :float
      field :longitude, :float
      field :address, :string
    end
  end

  def changeset(post, attrs) do
    post
    |> cast(attrs, [:title, :content])
    |> cast_embed(:location, with: &location_changeset/2)
  end

  defp location_changeset(location, attrs) do
    location
    |> cast(attrs, [:latitude, :longitude, :address])
    |> validate_required([:latitude, :longitude])
  end
end

To use cast_embed/3, we need to define the Location schema and use embeds_one/3 to define the embedded schema. We also need to define a location_changeset/2 function to cast and validate the location field.

For migration, you don't have to change anything. The migration will look like this:

defmodule MyApp.Repo.Migrations.CreatePost do
  use Ecto.Migration

  def change do
    create table(:posts) do
      add :title, :string
      add :content, :string
      add :location, :map

      timestamps()
    end
  end
end

As you can see, we still use :map type for the location field in the migration.

Now let's test this on iex by with some happy and sad paths (I've omitted the printed output for brevity):

# Happy path
iex> post = %Post{}
iex> attrs = %{title: "Hello", content: "World", location: %{latitude: 1.23, longitude: 4.56, address: "123 Main St"}}
iex> changeset = Post.changeset(post, attrs)
iex> changeset.valid?
true

# Sad path - missing latitude
iex> post = %Post{}
iex> attrs = %{title: "Hello", content: "World", location: %{longitude: 4.56, address: "123 Main St"}}
iex> changeset = Post.changeset(post, attrs)
iex> changeset.valid?
false
iex> changeset.errors
[latitude: "can't be blank"]

What if we want to make location type reusable?

If you want to make the Location type reusable, you can define it as a separate schema and use it in multiple schemas. Here's how you can define the Location schema and use it in the Post schema:

# lib/my_app/location.ex

defmodule MyApp.Location do
  use Ecto.Schema
  import Ecto.Changeset

  embedded_schema do
    field(:latitude, :float)
    field(:longitude, :float)
    field(:address, :string)
  end

  @doc false
  def changeset(location, attrs) do
    location
    |> cast(attrs, [:latitude, :longitude, :address])
    |> validate_required([:latitude, :longitude])
  end
end

# lib/my_app/post.ex

defmodule MyApp.Post do
  use Ecto.Schema
  import Ecto.Changeset

  schema "posts" do
    field :title, :string
    field :content, :string
    embeds_one :location, MyApp.Location
  end

  def changeset(post, attrs) do
    post
    |> cast(attrs, [:title, :content])
    |> cast_embed(:location)
  end
end

As you can see, we no longer need to reference any location_changeset/2 function in the cast_embed/3 function. It will automatically use the MyApp.Location.changeset/2 function to cast and validate the location field, which is pretty neat.

You can now reuse the Location schema in other schemas as well, for example in a User schema:

# lib/my_app/user.ex

defmodule MyApp.User do
  use Ecto.Schema
  import Ecto.Changeset

  schema "users" do
    field :name, :string
    embeds_one :location, MyApp.Location
  end

  def changeset(user, attrs) do
    user
    |> cast(attrs, [:name])
    |> cast_embed(:location, required: true)
  end
end

If you want to make location be a mandatory field, you can use cast_embed/3 with required: true option like above. This will make sure that the location field is mandatory and will raise an error if it's missing.

Summary

In this article, we learned how to cast and validate map-typed Ecto schema field using Ecto.Changeset.cast_embed/3. We also learned how to make the embedded schema reusable in multiple schemas. This is a very powerful feature of Ecto, and it can help you to keep your code DRY and maintainable.

To learn more about embedded schemas in Ecto, you can refer to the official Ecto documentation: Ecto - Embedded schemas.

I hope you find this article helpful. If you have any questions or feedback, feel free to reach out to me. Happy coding! 🚀

Top 3 Elixir books that will make you love Elixir even more

Hoon Wee — Wed, 28 Feb 2024 12:44:12 +0000

Introduction: Beyond the basics

I've been using Elixir for about 2 years now and so far I can confidently say that it's one of the most practical languages I've ever used. It has a lot of features that make it a joy to work with. It's a functional language, it's concurrent, it's distributed, it's fault-tolerant, and it's easy to learn. Whenever my colleagues ask me about Elixir, I always tell them that it's a language that's worth learning. I also recommend they read some of the introductory books about Elixir, like Elixir in Action by Saša Jurić, Programming Elixir by Dave Thomas, and The Little Elixir & OTP Guidebook by Benjamin Tan Wei Hao. These books are great for getting started with Elixir and they cover the basics of the language and the ecosystem.

But what about the next step? What about the books that will take you beyond the basics? What about the books that will make you love Elixir even more? In this article, I'll share with you the top 3 books that every Elixir developer should read. These books will help you to deepen your understanding of Elixir and to become a better Elixir developer.

Disclosure: I'm not affiliated with any of the authors or publishers of the books mentioned in this article. I'm just a fan of Elixir and I want to share my love for the language with others.

Real-Time Phoenix by Stephen Bussey

So you've learned the basics of Elixir and you've built a few web applications with Phoenix. You've learned how to use Ecto, how to use Phoenix LiveView, and how to use Phoenix PubSub. You've also learned how to use Phoenix Channels to build real-time web applications. But you want to go deeper. You want to learn how to build real-time web applications that are fast, reliable, and scalable.

Real-Time Phoenix is a book that will teach you to understand and how to build real real-time web applications with Phoenix. The book covers topics like WebSockets, Phoenix PubSub, Phoenix Presence, and (a little bit of) Phoenix LiveView. The best part (I think) is that the book covers how to test Phoenix sockets and channels, which is something that many developers struggle or ignore with. The book also covers how to deploy real-time Phoenix applications to production, and some considerations for scaling them.

Metaprogramming Elixir by Chris McCord

Metaprogramming Elixir is a book that will teach you how to write code that writes code. Metaprogramming is one of the most powerful features of Elixir and it's what makes the language so extensible and flexible. Inspired by Lisp, Elixir's metaprogramming is easier than many other languages (Yes, I talking about you Rust).

As many Elixir devs know, the author Chris McCord is the creator of the Phoenix web framework. He was once a Ruby developer and there were times when Ruby was not good enough for his needs. He then discovered Elixir and he was amazed by its features. He was particularly impressed by the metaprogramming capabilities of Elixir, which led him to create powerful macros and DSLs in Phoenix.

In this book, Chris McCord explains how metaprogramming works in Elixir and how you can use it to solve real-world problems. The book covers topics like macros, quote and unquote, code evaluation, and code generation. It also covers the use cases of metaprogramming, like building DSLs, writing code generators, and creating domain-specific abstractions. Once you understand metaprogramming, you'll be able to write more expressive and concise code, and you'll be able to create your libraries and frameworks.

Concurrent Data Processing in Elixir by Svilen Gospodinov

Elixir is known for its concurrency primitives. It has lightweight processes, message passing, and supervision trees, which make it easy to write concurrent code. But how do you write concurrent code in Elixir? How do you build concurrent data processing pipelines? How do you handle backpressure and fault tolerance?

Concurrent Data Processing in Elixir is a book that will answer these questions. The book covers topics like processes, message passing, supervision trees, and fault tolerance. It also covers how to use GenStage, Flow, and Broadway to build concurrent data processing pipelines.

One thing I love about this book is that it starts with a very basic element, the process, and then it builds up carefully to more complex topics like GenStage, Flow, and Broadway. Not only will you get a solid understanding of the basics of concurrent programming in Elixir, but you'll also be able to choose what libraries would be best for your use case.

Conclusion

Elixir is a language that's worth learning. It's a language that's worth mastering. It's a language that's worth loving. The books I've mentioned in this article will help you to deepen your understanding of Elixir and to become a better Elixir developer. They will help you to build real-time web applications, write expressive and concise code, and build concurrent data processing pipelines. They will make you love Elixir even more.

I hope you find these books as useful as I did. What are your favorite Elixir books? Let me know in the comments below.

What's the use of zero-sized types in Rust?

Hoon Wee — Mon, 21 Feb 2022 11:55:36 +0000

A struct type without any fields

Rust's modern type system

Rust is a modern language that has adopted lot's of good features from senior languages.
For example, Traits in Rust has a concept that resembles both Haskell's Type Classes and Java/Typescript's Interfaces.
And special types like Option<T> and Result<T,E> are inspired from lot's of functional programming languages.
Thanks to those adopted concepts, Rust's type system gives outstanding developer experience.

Zero-sized type

Today I want to introduce one of the most underrated type pattern called "zero-sized type(shortened as ZST)".
We can declare them like this.



struct ZeroSizedType;

ZST doesn't contain any fields, which means there's no need to allocate any memory space for this type - makes sense for the name 'zero-sized'!
Question is, what's the use of some struct type if it isn't constructed with fields? Let's find out.

Usage of Zero-sized type - a state machine

The most straighforward example to understand the usage of zero-sized type is a state-machine.
But what is a "state machine"? According to Wikipedia,

A finite-state machine (FSM) or finite-state automaton (FSA, plural:
automata), finite automaton, or simply a state machine, is a mathematical
model of computation. It is an abstract machine that can be in exactly one of
a finite number of states at any given time. The FSM can change from one state
to another in response to some inputs; the change from one state to another is
called a transition.

Looks pretty academic, but state machines can be easily found in real life.
An example image below, we have a simple process of delivering food for our customer.
Since it has states(reserved, cooking, delivering and arrived) and transitions between them, it's a state machine.

There are 4 states - Reserved, Cooking, Delivering and Arrived.
And there are 6 possible transitions from one state to another intercepted state. By connecting transitions, we can create various scenarios(or paths).

Let me show you one of the paths - the most optimistic food delivery scenario.

Reserved: Our customer ask for a food delivery, then we tell the customer that the delivery reservation is confirmed if there's enough food.
Reserved → Cooking : Once the delivery is reserved, the chef should start cooking the food.
Cooking → Delivering : Once food is ready, chef sends the food to our delivery man/woman.
Delivering → Arrived : Food has arrived to our customer. Hooray!

So far we've seen the state transitions with the green path, which is a happy path. But in real life, this might go red, which is sad path ...

Arrived → Delivering : Oh no! We delivered different food to our customer. We should go back to the kitchen with this food.
Delivering → Cooking : We tell our chef that we gave a wrong food to our customer, so we should cook a correct one.
Cooking → Reserved : Our chef choose not to cook, because the kitchen is out of ingredients. We should inform our customer about this. (Alternatively, we can just cook it and do Cooking → Delivery → Arrived again.)
Cooking → Reserved : We tell our excuse to the customer, and cancel the reservation and refund the money.

What a dramatic turn of event! There are tons of possible combinations we can accomplish. You name one!

For further details about state machines, visit here.

Building food delivery state machine with ZST

We can build an exact same food delivery state machine with Rust's ZST.
The full code can be seen here.

To start a new Rust project to follow along my code, run cargo new <project-name>.
Once the project has been set, head to main.rs file and let's begin!

1. States and Default



use std::marker::PhantomData;

struct Reserved;
struct Cooking;
struct Delivering;
struct Arrived;

struct FoodDelivery<State = Reserved> {
    state: PhantomData<State>,
}

impl Default for FoodDelivery<Reserved> {
    fn default() -> Self {
        let state = PhantomData;
        Self { state }
    }
}

This is how our code starts.

We created 4 zero-side structs, which will act as States for our FoodDelivery.
FoodDelivery is a state machine. It receives generic parameter State which obviously holds current state.
By assigning <State = Reserved>, we designate our default state as Reserved.
- Since there's a default generic type, we should implement Default for Reserved state.
The state's type should be PhantomData since our states are zero-sized.

Now we have our starting state Reserved, let's add green/red paths for 4 states.

2. Green/Red paths - State transitions



...

impl FoodDelivery<Reserved> {
    fn reserved(&self) -> FoodDelivery<Cooking> {
        println!("Your delivery has been successfully placed!");
        println!("Now we'll start cooking your food.\n");
        self.proceed::<Cooking>()
    }

    fn cancel_order(&self) -> Self {
        println!("Order canceled - money refunded.");
        println!("We hope you to see in another service.\n");
        self.stay()
    }
}

Both methods above starts from Reserved. fn reserved() is a green path and fn cancel_order() is a path that points itself(cause there's no state to go before this level).

Let continue with other states.



...

impl FoodDelivery<Cooking> {
    fn cooking_finished(&self) -> FoodDelivery<Delivering> {
        println!("Your food is successfully cooked!");
        println!("Now we'll send your food via delivery guy.\n");
        self.proceed::<Delivering>()
    }

    fn cannot_cook(&self) -> FoodDelivery<Reserved> {
        println!("Cannot cook your food - ingredients are out of stock.");
        println!("We'll guide you to cancel your order and get refunded.\n");
        self.proceed::<Reserved>()
    }
}

impl FoodDelivery<Delivering> {
    fn delivered(&self) -> FoodDelivery<Arrived> {
        println!("Delivery guy finished delivering your food.\n");
        self.proceed::<Arrived>()
    }

    fn taking_food_back(&self) -> FoodDelivery<Cooking> {
        println!("We are taking your food back to the kitchen.");
        println!("We will tell chef to cook your food again.\n");
        self.proceed::<Cooking>()
    }
}

impl FoodDelivery<Arrived> {
    fn confirm_arrival(&self) -> Self {
        println!("Food has arrived! Have a nice meal :)\n");
        self.stay()
    }

    fn cancel_arrival(&self) -> FoodDelivery<Delivering> {
        println!("Oh no! Wrong food :(");
        println!("We will take your food again via delivery man/woman\n");
        self.proceed::<Delivering>()
    }
}

Same, the each methods starts from each states. By now you'd notice some interesting parts.

Transition methods are separated for each states: Even though we're implementing the same FoodDelivery struct, methods are implemented in separated manner for each FoodDelivery<State>.
self.proceed() and self.stay(): For transition from state A to B, we can move forward(proceed), otherwises we need to stay.

The reason for the first one is because the underlying generic parameter is filled with different type.
And that makes our Rust compiler to consider FoodDelivery<Reserved> and FoodDelivery<Delivering> as completely different type in binary level.
For us, however, it feels like the type hasn't been changed but somehow Rust managed to separate the state transition methods - like magic!
This was possible because we used ZSTs - they are real types, doing a useful job like this even without any memory allocation.

One thing to consider - although transition methods are separated for each states, self.proceed() and self.stay() seems to be shared. How can this be?

3. Shared methods



...

impl<State> FoodDelivery<State> {
    fn proceed<NextState>(&self) -> FoodDelivery<NextState> {
        FoodDelivery { state: PhantomData }
    }
    fn stay(&self) -> Self {
        Self { state: PhantomData }
    }
}

We can simply make methods sharable by implement methods not for the statically typed ones, but for the generics.
All we need to use is to implement with generic type parameter.

4. Test scenarios

Now let's test some scenarios! In this post I'll just repeat the two scenarios I described above(the happy path and the sad path),
but you can build any state flows you can possibly create.



...

fn main() {
    println!("\n{:=^50}\n", " Happy Path ");
    let happy_path = FoodDelivery::default()
        .reserved()
        .cooking_finished()
        .delivered()
        .confirm_arrival();

    println!("\n{:=^50}\n", " Turns out Sad Path ");
    let _turns_out_sad = happy_path
        .cancel_arrival()
        .taking_food_back()
        .cannot_cook()
        .cancel_order();
}

Splendid isn't it? Let's try out.



$ cargo run

[Output]

=================== Happy Path ===================

Your delivery has been successfully placed!
Now we'll start cooking your food.

Your food is successfully cooked!
Now we'll send your food via delivery guy.

Delivery guy finished delivering your food.

Food has arrived! Have a nice meal :)


=============== Turns out Sad Path ===============

Oh no! Wrong food :(
We will take your food again via delivery man/woman

We are taking your food back to the kitchen.
We will tell chef to cook your food again.

Cannot cook your food - ingredients are out of stock.
We'll guide you to cancel your order and get refunded.

Order canceled - money refunded.
We hope you to see in another service.

We've built our own state machine with Rust's amazing type system. Hooray!

Conclusion

In this post we've discovered about what is a zero-sized type in Rust, and how should we use it.
One thing to clarify is that actually we've seen only one of the ZSTs.
There are others like (), ! and much more, and yet we've seen the struct version of it.
Those also have an interesting usage to discuss about, but I am gonna leave them for future posts.
For further details about ZSTs, visit here.

Thanks for reading my post! I'll see you later. Until then, Happy Coding!

Rust structs - How well are you using it?

Hoon Wee — Mon, 14 Feb 2022 16:21:24 +0000

How well are you using `struct`s?

There are several ways to use structs, and we will see some of them and analyze the pros and cons.

Method 1: Public struct with public fields

For public struct with public fields, the easiest way to create struct instance is to do like StructName { field1: .., field2: .. }.

struct Student<'a> {
    name: String,
    age: i32,
    friends: Vec<&'a str>
}

fn main() {
    let harry = Student {
        name: "Harry Potter".to_string(),
        age: 12,
        name: vec!["Ron Wealsey"],
    };

    /* using '.' operator */
    let _harry_name = harry.name;
    let _harry_age = harry.age;
    let _harry_friends = harry.friends;

    /* struct destructuring */
    let Student {
        _harry_name,
        _harry_age,
        _harry_friends
    } = harry;
}

Pros: Super Simple

Super simple to define struct.
- You don't need to create any other methods to get and set the field data.
Getting the field value out of the struct is very easy.
- You can use . operator to take the field value out. (ex) harry.name
- You can also use struct destructuring by StructName { field1, field2, .. }.

Cons: Too easy to access

There's no private data for this struct.
- If you need any encapsulation for these data fields, this method is not for you.
Getting a field like this will give a owned value, which is normally unwanted for most of the case.
- Rust has a special rule called 'ownership', which means that if the value doesn't implement Copy trait, the value moves to new variable.

  let harry = Student {
      name: "Harry Potter".to_string(), // This field is `String` type, which doesn't implement a `Copy` trait.
      age: 12,
      name: vec!["Ron Wealsey"],
  }

  let harry_name = harry.name; // `harry.name` is moved into a variable `harry_name`
  let another_name = harry.name; // COMPILE ERROR, since now `harry` doesn't have a value of `name` field.

You can fix this with using & operator by borrowing the value, yet the better way is make a getter method.

  let harry_name = &harry.name;
  let another_name = &harry.name;

It can be dangerous to allow both reading and writing by just getting field value with . operator.

  /* Reading the value */
  let harry_name = harry.name;

  /* By adding a `mut` keyword, you can write the value of the field */
  let mut write_harry_name = harry.name;
  write_harry_name = "James Potter".to_string();

The only difference that separates from reading to writing the field value is whether there's a mut keyword or not, which is prone to mistakes.
For simple programs this would be no problem, but still it's important not to make situations that accidentally writes a value in context where we shouldn't.

Method 2: Using Getter and Setter

The method above is the simplest, yet it's maybe too publicly accessible. You may want to encapsulate the struct by customizing
which field can be read or written from public context. The most common way to accomplish this is to make a getter and setter methods.

You can implement the methods for structs using impl.

/* This struct is public, yet it's fields are private */
struct Student<'a> {
    name: String,
    age: i32,
    friends: Vec<&'a str>,
}

impl<'a> Student<'a> {
    pub fn name(&self) -> &str {
        &self.name
    }
    pub fn age(&self) -> i32 {
        self.age
    }
    pub fn friends(&self) -> &[&str] {
        self.friends.as_slice()
    }
}

fn main() {
    let harry = Student {
        name: "Harry Potter".to_string(),
        age: 12,
        friends: vec!["Ron Weasley", "Hermione Granger"],
    };

    let harry_name = harry.name();
    let harry_age = harry.age();
    let harry_friends = harry.friends();

    println!("{harry_name}, {harry_age}, {:?}", harry_friends);
}

Pros: Nicely encapsulated

No we have some level of encapsulation.
- With the code like above, we provide only two functionalities - building a struct instance, and reading each fields. Our code won't let others to set different value in the field.
Segregating the role for read/writing delivers better understanding while reading the code.
- By getting the value with method, it will give a better understanding whether this is reading or writing it. While in the public struct and public fields method, it was hard to know whether the code is reading or writing the value.

  let harry_name = harry.name;

  // This is easier to understand the intention of the code.
  let harry_name = harry.name();
  let harry_name = harry.set_name("Harry".to_string());

You can choose a custom type for getting a field value.
- Defining the method gives you whole another power of control. You can choose whether to return the borrowed value or owned value.

  impl Student {
      // Returning the borrowed value - this will live until the struct instance is alive
      fn borrowed_name(&self) -> &str {
          &self.name
      }
      // Returning the owned and cloned value - this will live as long as it's now moved.
      fn owned_name(&self) -> String {
          self.name.clone()
      }
  }

  fn main() {
      let harry = Student {
          name: "Harry potter".to_string(),
      };
      let borrowed_name = harry.borrowed_name();
      let owned_name = harry.owned_name();

      println!("{borrowed_name}, {owned_name}");

      drop(harry); // now you can't access to borrowed value

      println!("{owned_name}");
  }

Cons: Verbose

Bunch of codes to write!
- If you have 3 fields in your struct, then you will have to write 3 getter methods and 3 setter methods if you want to make a full Read/Write API. And that can be a burden for the developer.

For the lazy developers - use `getset`

If you are too lazy for writing all those methods, try using getset crate.
It provides several macros which is really easy and intuitive to use.

Here's a quick example how to use it.

use getset::{Getters, Setters};

#[derive(Getters, Setters)]
struct Student {
    #[getset(get, set)]
    name: String,
}

fn main() {
    let mut harry = Student {
        name: "Harry Potter".to_string(),
    };

    let _get_name = harry.name(); // returns &String type
    let _set_name = harry.set_name("Harry".to_string()); // returns &mut Student type
}

Method 3: Builder Pattern

For those who have studied enough about object-oriented programming, you might have heard of Design Patterns.
Simply put, it's a collections of idiomatic solution for solving problems in OOP project.
From one of the design patterns, there's a builder pattern, which you build a struct instance by setting the field values step-by-step.

Ok...talk is cheap, I'll show you the code. Here's how you implement builder pattern in Rust.

struct Student<'a> {
    name: String,
    age: i32,
    friends: Vec<&'a str>,
}

impl<'a> Student<'a> {
    pub fn builder() -> StudentBuilder<'a> {
        StudentBuilder::new()
    }
    // This can be used after the building process is complete
    pub fn name(&self) -> &str {
        &self.name
    }
}

struct StudentBuilder<'a> {
    name: String,
    age: i32,
    friends: Vec<&'a str>,
}

impl<'a> StudentBuilder<'a> {
    pub fn new() -> Self {
        Self {
            name: "".to_string(),
            age: 0,
            friends: vec![],
        }
    }
    pub fn name(self, name: String) -> Self {
        // `..self` is a syntax sugar for `age: self.age, friends: self.friends`
        Self { name, ..self }
    }
    pub fn age(self, age: i32) -> Self {
        Self { age, ..self }
    }
    pub fn friends(self, friends: Vec<&'a str>) -> Self {
        Self { friends, ..self }
    }
    pub fn build(self) -> Student<'a> {
        let StudentBuilder { name, age, friends } = self;
        Student { name, age, friends }
    }
}

fn main() {
    let harry = Student::builder()
        .name("Harry Potter".to_string())
        .age(12)
        .friends(vec!["Ron Weasley", "Hermione Granger"])
        .build();
}

With builder pattern, we use intermediary type called StudentBuilder(or it should be any [StructName]Builder) to assign field types step-by-step.

Pros: Complete Segregation

It provides a segragation between intializer and getter/setter.
- Initializer is a special kind of method - it doesn't use any self data, yet it creates them. The role of the initializer and the setter methods should not be confused, while the latter is just a mutator for the previously initialized value.
By using intermediary Builder struct, we restrict the access of struct fields until it's intialized.
- Before finalizing the construct of Student struct with build() method, it doesn't give you an exact Student struct, so we cannot use any getters and setters. This will prevent our code from making errors of using unset values.

Cons: Even longer code

Implementing a builder pattern gives a better encapsulation than Method 2, which results in creating more code as a trade-off.
We have to set all the field values in single chain like builder().field_one(val).field_two(val).field_three(val).build(), which can be restrictive because there might be some situations that we cannot afford all the field values beforehand.
- This can be solved with implementing ergonomic version.

Ergonomic Builder Pattern

The restrictiveness of 2nd problem we had in builder pattern can be solved by providing mutability in builder methods.
The implementation code should be changed like this.

struct Student<'a> {
    name: String,
    age: i32,
    friends: Vec<&'a str>,
}

impl<'a> Student<'a> {
    pub fn builder() -> StudentBuilder<'a> {
        StudentBuilder::new()
    }
    pub fn name(&self) -> &str {
        &self.name
    }
}

struct StudentBuilder<'a> {
    name: String,
    age: i32,
    friends: Vec<&'a str>,
}

impl<'a> StudentBuilder<'a> {
    pub fn new() -> Self {
        Self {
            name: "".to_string(),
            age: 0,
            friends: vec![],
        }
    }
    pub fn name(&mut self, name: String) {
        self.name = name;
    }
    pub fn age(&mut self, age: i32) {
        self.age = age;
    }
    pub fn friends(&mut self, friends: Vec<&'a str>) {
        self.friends = friends;
    }
    pub fn build(self) -> Student<'a> {
        let StudentBuilder { name, age, friends } = self;
        Student { name, age, friends }
    }
}

fn main() {
    let mut harry_builder = Student::builder();

    let name = "Harry Potter".to_string();
    harry_builder.name(name);

    let age = 12;
    harry_builder.age(age);

    let friends = vec!["Ron Weasley", "Hermione Granger"];
    harry_builder.friends(friends);

    let harry = harry_builder.build();
}

This way, we can place the code for setting the field values in place where they are affordable.
This small fix hasn't even increased any code lengths, so that's super-awesome!

For the detailed explanation for builder patterns in Rust, find it here.

Conclusions

So, what method should we choose for our project? It's hard to answer, but there's an old wisdom for any kind of craftsmanship.

" The more difficult for the maker, the better for the user. "

Three methods that we've seen in this article shows the best example for the
quote above. More you write your code, you provide better developer experience for
you and others who use your crate. It's completely up to you, but here I give you
some obvious recommendations.

For projects which needs rapid development, go for the easiest first, and then the more difficult one when refactoring.
For projects that should have solid foundations from the beginning,
- Implement getter/setter or builder pattern by your own, if you have a lot of time.
- Or use helper crates like getset to quickly implement getter/setter, if you have less time to finish.

One thing you should remember is that using getset is great, but for better customization (like configuring the return types of methods) , you should implement it by yourself.

I hope this article will guide you feel lost when using struct in Rust. I'll come back with more Rust-related posts!

Until then, happy coding :)

Build comments section with Next.js and Supabase

Hoon Wee — Mon, 07 Feb 2022 23:32:21 +0000

Let's build our own comments section because... why not?

Hi yall folks! In this series, we will use sexy combination - Next.js + Supabase - to build a comment section for blogs.

Our goal

Just like every good-old Todo list tutorials, we will build simple CRUD(Create, Read, Update and Delete) features for our comments.

Adding comments
Reading comments
Editing comments
Deleting comments
Replying to comments

The follow-along code can be found here.

What do we need?

Obviously, we'll be using those three:

Next.js: Probably the best production-ready frontend framework in this planet
Supabase: Trendy BaaS(Backend as a Service) product for PostgreSQL lovers

And also some extras that will make our project super-easy:

TailwindCSS: CSS library that will make styling super-easy.
SWR: Super-simple data fetching/caching library

Local Settting: Next.js and TailwindCSS

Create Next App

We'll first create a basic Typescript-based Next.js application using npx create-next-app.



$ npx create-next-app --typescript supabase-comments

When the project is created, head to the files directory and you'll see those basic files.
We won't be needing all of them, so we'll remove some of them.



...node_modules
├── package.json
├── pages
│   ├── _app.tsx
│   ├── api
│   │   └── hello.ts
│   └── index.tsx
├── public              # <- Remove
│   ├── favicon.ico     # <- Remove
│   └── vercel.svg      # <- Remove
├── styles
│   ├── Home.module.css # <- Remove
│   └── globals.css
├── tsconfig.json
└── yarn.lock

Add TailwindCSS for NextJS

Above done, then we'll add TailwindCSS & other dependencies for our styling.



$ yarn add -D tailwindcss postcss autoprefixer
$ yarn tailwindcss init -p

The last command will create tailwindcss.config.js file, which is a config javascript file for TailwindCSS.
This simple file does a lot, but right now we'll just define which files should TailwindCSS watch for.



module.exports = {
  content: [
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

And then, replace contents in styles/globals.css with the code down below.



@tailwind base;
@tailwind components;
@tailwind utilities;

Now we can properly use our TailwindCSS with NextJS!
To test if it works, replace the contents in pages/index.tsx with the code down below.



import type { NextPage } from "next";
import Head from "next/head";

const Home: NextPage = () => {
  return (
    <div>
      <Head>
        <title>Comments Page</title>
      </Head>
      <div className="p-12">
        <h1 className="text-2xl font-bold">Comments!</h1>
      </div>
    </div>
  );
};

export default Home;

Run the following command to serve web page in development environment,



$ yarn dev

... and head to http://localhost:3000 to see the bold typed Comments! in the blank web page.

Well done! We are done with our local settings(except SWR, but we'll install it later), so let's head to remote setting.

Remote Setting: Supabase

Create an organization and a project

Head to official Supabase website and sign in with your Github account.

Then it will lead you to the app dashboard.
Click New Project and then click + New Organization to create your new project team.
(If you already have an organization, feel free to skip creating one)

Then it will tell you to create a new name for your organization. Just type any cool name, and hit Create organization.

Now for the organization we've just created, we'll create a new project which will contain SQL tables.

Name: I'll just name it "Master Supabase", but the naming doesn't matter.
Database Password: For the password, try using passgen tool to create a strong one. I normally create one from PassGen.co, with length longer than 14.
Region: Choose the nearest place where you live(as for me, Seoul).
Pricing Plan: Choose 'Free tier', but you can upgrade later if you want.

Once finished the form, hit Create new project.

And now we have our brand new Supabase project! Feel free to explore around, discover what you can do.

Create `comments` table

Now we will make a SQL table called comments. To do that click a 'Table editor' menu in left panel of the dashboard.
If your project is new, the there will be no tables in it. Let's hit Create a new table.

Then it will show you a side panel to insert form for your table's settings.

Name: comments, but feel free to choose other name.
Description: This is optional, and I am gonna skip it this time.
Enable Row Level Security: This is a fancy feature in Supabase, but we'll discover it my later post. Now we just skip it.
Columns: We'll edit & add several columns like the image below.

Make sure you change the type of 'id' column into uuid!

If you've finished and confirmed the form, hit Save button.

Now we have our comments table! Let me explain each table columns' role :

id: An unique identifier of the column.
created_at: We'll use this to sort our comments in created order.
updated_at: We'll use this and created_at's difference to tell if the comment has been edited.
username: This will be used to indicate user who wrote the comment.
payload: Actual content of the comment.
reply_of: I will save the comment's id that we are replying to.

Create comment

Add input form and Supabase client library

Our index page is kinda empty now, so we should make it look better. Replace the code in pages/index.tsx to the code down below.



import type { NextPage } from "next";
import Head from "next/head";

const Home: NextPage = () => {
  return (
    <div>
      <Head>
        <title>Comments Page</title>
      </Head>
            <div className="pt-36 flex justify-center">
        <div className="min-w-[600px]">
          <h1 className="text-4xl font-bold ">Comments</h1>
          <form onSubmit={onSubmit} className="mt-8 flex gap-8">
            <input type="text" placeholder="Add a comment" className="p-2 border-b focus:border-b-gray-700 w-full outline-none" />
            <button className="px-4 py-2 bg-green-500 rounded-lg text-white">Submit</button>
          </form>
        </div>
      </div>
    </div>
  );
};

export default Home;

We added as simple input form to create a comment. There are some styling codes added,
but since this is not a TailwindCSS tutorial I will leave the explanation to better resource.

Our form looks good, but it doesn't really do anything. To create a comment, we should do this process:

User type the comment in the form, then hit Submit.
We somehow send the comment data to our Supabase comments table.
We check our table, see if the data has been added.

To perform the 2nd step, we need a Supabase node client library. Run the command below to add it.



$ yarn add @supabase/supabase-js

Make our messenger for Supabase

Now we need to create a supabase client object, which is a messenger that will help us interact with Supabase.
Add these 2 lines in pages/index.tsx.



...
import { createClient } from "@supabase/supabase-js";

export const supabase = createClient(supabaseUrl, supabaseKey);

const Home: NextPage = () => {
  return (
    <div>
...

To create a Supabase client object, we need two data: Supabase project URL and key.
These can be found in Settings > Project settings > API section in our Supabase project dashboard.

Understanding environment variables

These keys should be stored somewhere secure and separate.
Many of the developers save secured data as 'environment variables', commonly shorten as 'env vars'.

Env vars also works as 'variables' which can be set differently across the environment.
For our case, we need to define env vars for development environment, and to do that in NextJS, we use .env.local file.
If you want to use the same variables in production environment, you can use .env.production file and replace the values.

Ok, now let's create a .env.local file in our NextJS app's root directory.
Then copy-paste the first key (anon/public key) in the image above and save it to NEXT_PUBLIC_SUPABASE_KEY.
For the second key (URL key), save it to NEXT_PUBLIC_SUPABASE_URL.

If done correctly, it should look like this.



NEXT_PUBLIC_SUPABASE_KEY=[first-key]
NEXT_PUBLIC_SUPABASE_URL=[second-key]

Now what's all that NEXT_PUBLIC_ prefix? NextJS handles env vars differently by their names:

With NEXT_PUBLIC_ prefix: Those are exposed in browser, which means it can be used in client-side jobs.
Without NEXT_PUBLIC_ prefix: Those are server-side jobs.

So that means our supabase basically use those keys in browser side. Once we define or edit our .env.local file, we have to restart
the development server, so go to terminal and kill the current session with CTRL-C, and then restart with yarn dev.

Since we can use our env vars now, add and edit the following lines in pages/index.tsx.



...
import { createClient } from "@supabase/supabase-js";

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL ?? "";
const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_KEY ?? "";

export const supabase = createClient(supabaseUrl, supabaseKey);

const Home: NextPage = () => {
  return (
    <div>
...

The extra ?? "" after each env var initalization is to prevent them to be undefined type, which then createClient won't accept it.

Send an `insert` request

Before we use our supabase messenger, we will first get user's comment payload from our input form.
To do that,

Add a comment react state for the placeholder of user's comment payload.
Add onChange function to update the comment payload in comment whenever the payload is changed.
Add onSubmit function to handle the submit behavior of the form. In our case we don't want to reload everytime when we submit the form, so we use event.preventDefault().

The code change will be as following.



...
const Home: NextPage = () => {
  const [comment, setComment] = useState<string>("");

  const onChange = (event: ChangeEvent<HTMLInputElement>) => {
    const commentValue = event.target.value;
    setComment(commentValue);
  };

  const onSubmit = (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();
        console.log(comment);
  };
...
        <form onSubmit={onSubmit} className="mt-8 flex gap-8">
            <input
                onChange={onChange}
                type="text"
                placeholder="Add a comment"
                className="p-2 border-b focus:border-b-gray-700 w-full outline-none"
            />
...

To test if it works, open the Devtools for your browser and head to Console tab, type something in the input and hit Submit.
If succeeded, it will show like the image below.

Now we'll use our supabase client to create a comment. In SQL table's perspective, it will basically add a new row.
Replace onSubmit function to code down below. Don't forget to add an async keyword since the supabase client api returns a Promise.



...
  const onSubmit = async (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();

    const { data, error } = await supabase.from("comments").insert({
      username: "hoonwee@email.com",
      payload: comment,
    });

    if (!error && data) {
        // If succeed
      window.alert("Hooray!");
    } else {
        // If failed
      window.alert(error?.message);
    }
  };
...

Let me disect the await supabase part real quick:

.from("comments") : This indicates which table should be looked for, since theoretically we have lot's of table in project.
.insert(table_row) : By using insert, we create a new row in our comments table with give table_row data.
- As you can see, we have only put username and payload in our table_row, because the rest of the data will have it's default value.
const { data, error }: Supabase will give us a response containing data which contains information of our action, and error if there's an error.

Now let's write something again and hit Submit. And if you have succeeded, you'll see an alert window containing Hooray! message.

Well that's pretty nice, but we still don't know whether our data has been sent or not.
Head to comments table in Supabase dashboard, and you'll see a new data row inserted.

Read comments

Create a comment list

Okay great, now we can create comments but we also want to display them in our web page.
To do that we'll do following steps:

We get all the comments from the comments table.
We display it - in list-like format.
We will sort then by created_at data to see them chronologically.

First we should add some UI for the list! Add the following code in pages/index.tsx.



...
export const supabase = createClient(supabaseUrl, supabaseKey);

interface CommentParams {
  id: string;
  created_at: string;
  updated_at: string;
  username: string;
  payload: string;
  reply_of?: string;
}

const Home: NextPage = () => {
  const [comment, setComment] = useState<string>("");
  const [commentList, setCommentList] = useState<CommentParams[]>([]);
...
          Submit
        </button>
      </form>
      <div className="flex flex-col gap-4 pt-12">
        {commentList.map((comment) => (
          <div key={comment.id} className="border rounded-md p-4">
            <p className="font-semibold mb-2">{comment.username}</p>
            <p className="font-light">{comment.payload}</p>
          </div>
        ))}
      </div>
    </div>
...

Let's disect this part real quick:

Below our form element we added a comment list section, iterated by commentList react state that we newly created.
The commentList state has a array-type of CommentParams interface, which contains all the column names for each object key.
The question mark ? at reply_of field indicates that this field is optional.

Send a `select` request

Before moving to next step, I want you to add more comments using our form

because once we succeed to get the comments from supabase, it will look awesome when we have bunch of comments.

Once you've done adding more comments, now let add a new function called getCommentList that will use supabase client to
get all the comments. Add the code down below.



...
  const [commentList, setCommentList] = useState<CommentParams[]>([]);

  const getCommentList = async () => {
    const { data, error } = await supabase.from("comments").select("*");
    if (!error && data) {
      setCommentList(data);
    } else {
      setCommentList([]);
    }
  };

  useEffect(() => {
    getCommentList();
  }, []);
...

Right now getCommentList function will be called once only, when we first render our page.
To do that we will call our getCommentList in useEffect hook. Since the useEffect hook has no external dependency,
this will invoke the inner part only once when the component is rendered.

Now check our web page. It will look much like other comment sections!

Sort comments by created order

Now our Supabase client takes the comment list in created order,
but soon after when we edit and reply to some of the comments it would bring them by updated order.

So we should do a little tweak in our code to sort them.



...

          <div className="flex flex-col gap-4 pt-12">
            {commentList
              .sort((a, b) => {
                const aDate = new Date(a.created_at);
                const bDate = new Date(b.created_at);
                return +aDate - +bDate;
              })
              .map((comment) => (
                <div key={comment.id} className="border rounded-md p-4">
                  <p className="font-semibold mb-2">{comment.username}</p>

...

Breaking this down:

We added .sort before doing .map in comment list rendering part.
The logic inside .sort will arrange from the oldest to the youngest.
The + sign at the beginning of aDate and bDate is for casting Date type to number type, since Typescript's sort()'s return value has to be in number type.

Update and Delete Comments

Plan a feature

We make mistakes, especially a lot when we write something in the internet.
That's why there's always a Edit and Delete section in posts and comment section in Facebook, Medium, Twitter and etc.

A properly working editing feature should have these features:

Able to edit the payload(content) right at the comment item itself.
Disable edit button unless payload hasn't changed.
Indicate if this comment has been edited.

A great deleting feature should:

Ask user if they're really gonna delete this to prevent if this was a click mistake.
Then delete it.

Create edit input form

For the best user experience, the input form to edit the comment should not be the same place where you add a comment but the comment list item itself.
That means we should upgrade our comment list item, so let's add the following code to do it!



...

const Home: NextPage = () => {
  const [comment, setComment] = useState<string>("");
  const [commentList, setCommentList] = useState<CommentParams[]>([]);
  const [editComment, setEditComment] = useState<EditCommentParams>({
    id: "",
    payload: "",
  });

  const onChangeEditComment = (event: ChangeEvent<HTMLInputElement>) => {
    const payload = event.target.value;
    setEditComment({ ...editComment, payload });
  };

  const confirmEdit = () => {
    window.alert("Confirm edit comment");
  };

  const getCommentList = async () => {
    const { data, error } = await supabase.from("comments").select("*");

...
        <div key={comment.id} className="border rounded-md p-4">
          <p className="font-semibold mb-2">{comment.username}</p>
          <div className="flex items-center gap-2 justify-between">
            {comment.id === editComment.id ? (
              <input
                type="text"
                value={editComment.payload}
                onChange={onChangeEditComment}
                className="pb-1 border-b w-full"
              />
            ) : (
              <p className="font-light">{comment.payload}</p>
            )}
            {editComment.id === comment.id ? (
              <div className="flex gap-2">
                <button type="button" onClick={confirmEdit} className="text-green-500">
                  Confirm
                </button>
                <button
                  type="button"
                  onClick={() => setEditComment({ id: "", payload: "" })}
                  className="text-gray-500"
                >
                  Cancel
                </button>
              </div>
            ) : (
              <button
                type="button"
                onClick={() => setEditComment({ id: comment.id, payload: comment.payload })}
                className="text-green-500"
              >
                Edit
              </button>
            )}
          </div>
        </div>
      ))}
    </div>

...

A brief analysis for this one:

We added editComment state, which will set which comment to edit and to what payload it should be.
We added two functions:
- onChangeEditComment: This will watch the value of edit form input and set the payload to edit with setEditComment.
- confirmEdit: This will send a request to Supabase to update the comment, but right now we just put silly window alert.
We updated our comment item section to switch between 'read-mode' and 'edit-mode' with editComment state.

Constructing `update` request

Now only thing to do is just replacing the confirmEdit function to communicate with Supabase.
Replace that part with this code. I'm sure you are now getting familiar with supabase api.




...

   const confirmEdit = async () => {
    const { data, error } = await supabase
      .from("comments")
      .update({
        payload: editComment.payload,
      })
      .match({ id: editComment.id });
    if (!error && data) {
      window.alert("Edited Comment!");
    } else {
      window.alert(error?.message);
    }
  };

...

So apparently from this code,

We used update function to update the data.
- We only need to pass the changed part, not the whole other parts.
Then used match function to target which comments should be updated.

But wait, shouldn't we update the updated_at?

That is correct! We will do it in Supabase Dashboard, not in our Next.js code.
We will use an actual SQL query to accomplish this, and to do that head to SQL Editor through navigation bar.
Then you'll see an input box to write down the SQL query. Insert the SQL query down below.



create extension if not exists moddatetime schema extensions;

create trigger handle_updated_at before update on comments
  for each row execute procedure moddatetime (updated_at);

So much to explain about this query, but basically it will set the updated_at column to the current timestamp for every update.
Hit Run to run the query and adapt the trigger.

Now our edit request will work like a charm. Try editing any comment, and then refresh. If succeeded then you'll see your comment edited.

Disable `Confirm` button when comment is not edited

Currently we just allow user to click Confirm button whenever they press Edit button, without checking if the payload has changed.
This can arise two problems:

Our confirmEdit function always changes updated_at data, so even though we've mistakenly confirm the edit without changing, the comment will always be marked as edited since there's no going back in time.
Now this is not that critical matter, but if we were to use this in much bigger project, then there will be unnecessary transaction between user browser and Supabase.

To prevent this, we need to disable the Confirm button when user hasn't change their comment. Let's tweek a code a little bit.




...

    {editComment.id === comment.id ? (
      <>
        <button
          type="button"
          onClick={confirmEdit}
          disabled={editComment.payload === comment.payload}
          className={`${editComment.payload === comment.payload ? `text-gray-300` : `text-green-500`}`}
        >
          Confirm
        </button>
        <button
          type="button"
          onClick={() => setEditComment({ id: "", payload: "" })}
          className="text-gray-500"

...

Now our Confirm button will be disabled unless the content of the comment has been changed.

Indicate `edited`

Comment item should indicate that it has been edited. This can be acheived quite easily - by comparing created_at and updated_at.




...

      .map((comment) => (
        <div key={comment.id} className="border rounded-md p-4">
          <p className="font-semibold mb-2">
            {comment.username}
            {comment.updated_at !== comment.created_at && (
              <span className="ml-4 text-sm italic font-extralight">edited</span>
            )}
          </p>
          <div className="flex items-center gap-2 justify-between">
            {comment.id === editComment.id ? (

...

Now if we edit any comment, it will indicate edited in extra-light & italic font.

Delete comment

Deleting comment is not so different from updating comment - it uses same match function to target which comment should
be deleted. Let's do this real quick.




...

  const confirmDelete = async (id: string) => {
    const ok = window.confirm("Delete comment?");
    if (ok) {
      const { data, error } = await supabase.from("comments").delete().match({ id });
      if (!error && data) {
        window.alert("Deleted Comment :)");
      } else {
        window.alert(error?.message);
      }
    }
  };

...

                  onChange={onChangeEditComment}
                  className="pb-1 border-b w-full"
                />
              ) : (
                <p className="font-light">{comment.payload}</p>
              )}
              <div className="flex gap-2">
                {editComment.id === comment.id ? (
                  <>
                    <button type="button" onClick={confirmEdit} className="text-green-500">
                      Confirm
                    </button>
                    <button
                      type="button"
                      onClick={() => setEditComment({ id: "", payload: "" })}
                      className="text-gray-500"
                    >
                      Cancel
                    </button>
                  </>
                ) : (
                  <>
                    <button
                      type="button"
                      onClick={() => setEditComment({ id: comment.id, payload: comment.payload })}
                      className="text-green-500"
                    >
                      Edit
                    </button>
                    <button type="button" onClick={() => confirmDelete(comment.id)} className="text-gray-700">
                      Delete
                    </button>
                  </>
                )}
              </div>
            </div>
          </div>
        ))}
      </div>
    </div>

...

After adding the code, click the Delete button in the comment item that you want to delete, press Ok in confirm window,
and refresh the page - then the comment is gone!

You see, making CRUD feature with Supabase is Supa-easy!

Replying to Comments

How our reply will work

Now guess the only column in our table that we haven't used yet - that's right, the reply_of column. We'll use it right away to
add a feature to reply comments.

Let's think how our reply feature would work best:

User clicks Reply button on the comment item.
Then our input form(for adding comments) will show that this comment will be a replying comment of some other comment.
Once added and fetched to the comment list, it should still be distinguishable from normal comments.

Adding `Reply of: ....`

Alrighty, as always let's work with the UI part first.




...

  const [editComment, setEditComment] = useState<EditCommentParams>({ id: "", payload: "" });
  const [replyOf, setReplyOf] = useState<string | null>(null);

  const onChangeEditComment = (event: ChangeEvent<HTMLInputElement>) => {

...

    <h1 className="text-4xl font-bold ">Comments</h1>
    <form onSubmit={onSubmit} className="mt-8 flex gap-8">
      <div className="w-full">
      {replyOf && (
        <div className="flex gap-4 my-2 items-center justify-start">
          <p className="text-xs font-extralight italic text-gray-600">
            Reply of: {commentList.find((comment) => comment.id === replyOf)?.payload ?? ""}
          </p>
          <button onClick={() => setReplyOf(null)} className="text-xs font-light text-red-600">
            Cancel
          </button>
        </div>
      )}

...

    .map((comment) => (
      <div key={comment.id} className="border rounded-md p-4">
        {comment.reply_of &&
          <p className="font-extralight italic text-gray-600 text-xs">
            Reply of: {commentList.find((c) => c.id === comment.reply_of)?.payload ?? ""}
          </p>
        }
        <p className="font-semibold mb-2">
          {comment.username}

...

            Delete
          </button>
          <button type="button" onClick={() => setReplyOf(comment.id)} className="text-orange-500">
            Reply
          </button>
        </>
      )}
    </div>

...

Here in this code, we can see that:

We declared a new state called replyOf to save the id of replying comment that we select.
We added a single text line in (1) Input form (2) Above username in comment item, showing which comment we are replying to.
- In input form, we also added a Cancel button to cancel replying to it and revert our input form to normal one.
We added a Reply button, which will use setReplyOf to save the id of comment that we select.

Ok this explanation enough, but basically it will look like this simple.

Then all you need to add is to pass the replying comment's id to reply_of field in onSubmit.




...

  const onSubmit = async (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    const { data, error } = await supabase.from("comments").insert({
      username: "hoonwee@email.com",
      payload: comment,
      reply_of: replyOf,
    });
    if (!error && data) {
      window.alert("Hooray!");
    } else {
      window.alert(error?.message);
    }
  };

...

Now try adding a replying comment and then refresh. If done correctly, you'll see a reply comment like the image below.

Restyling using Icons

Problems with text-only UI

So now our comment section is already awesome. It can read, create, update, delete and reply to comments.
While it's fully functional, we have to admit that it looks very boring and visually unapealing - because we only used texts for our UI.

The problem with using only text for our UI can invoke bad user experiences like:

It can be less intuitive, which will confuse users.
If the text is too long, it can ruin the overall visual design.

So to solve this, we need some design element that can pack the meaning of the UI into strong and concise visual format.
The best one for this, as far as I know, is an icon.

Text → Icons

There are tons of icon packs in internet, and in here we will use one called Hero icons.
Since it's been developed from the people behind TailwindCSS, it works best with our project.

Install Hero icons with the following command.



$ yarn add @heroicons/react

Now let's start replacing several texts into Hero icons!




...

import { ReplyIcon, PencilIcon, TrashIcon, CheckCircleIcon, XCircleIcon, XIcon } from "@heroicons/react/outline";

...

          Cancel
        </button>
      </>
    ) : (
      <>
        <button
          onClick={() => setEditComment({ id: comment.id, payload: comment.payload })}
          title="Edit comment"
        >
          <PencilIcon className="w-6" />
        </button>
        <button onClick={() => confirmDelete(comment.id)} title="Delete comment">
          <TrashIcon className="w-6" />
        </button>
        <button onClick={() => setReplyOf(comment.id)} title="Reply to comment">
          <ReplyIcon className="w-6 rotate-180" />
        </button>
      </>
    )}
  </div>

...

What has been changed?

We replaced three texts in our comment item - Edit, Delete, and Reply.
We removed the unnecessary color variation between buttons cause our icons already are distinguishable.
We added a title property to show what this icon means when user's mouse pointer hovers on the button.
- I strongly advice to do this, since the infographic that we know as common sense might not be the same in other culture.
We rotated the Reply icon to 180 degrees. I did it because it felt right with this angle, but you can change it if you want.

Let's keep adding more icons.




...

      {replyOf && (
        <div className="flex gap-4 my-2 items-center justify-start">
          <div className="flex items-center justify-start gap-2">
            <ReplyIcon className="w-4 text-gray-600 rotate-180" />
            <p className="font-extralight italic text-gray-600 text-sm">
              {commentList.find((comment) => comment.id === replyOf)?.payload ?? ""}
            </p>
          </div>
          <button onClick={() => setReplyOf(null)} title="Cancel">
            <XIcon className="w-4 text-gray-600" />
          </button>
        </div>
      )}

...

      {comment.reply_of && (
        <div className="flex items-center justify-start gap-2">
          <ReplyIcon className="w-3 text-gray-600 rotate-180" />
          <p className="font-extralight italic text-gray-600 text-xs">
            {commentList.find((c) => c.id === comment.reply_of)?.payload ?? ""}
          </p>
        </div>
      )}

...

      <div className="flex gap-2">
        {editComment.id === comment.id ? (
          <>
            <button
              type="button"
              onClick={confirmEdit}
              disabled={editComment.payload === comment.payload}
              title="Confirm"
            >
              <CheckCircleIcon
                className={`${
                  editComment.payload === comment.payload ? `text-gray-300` : `text-green-500`
                } w-6`}
              />
            </button>
            <button type="button" onClick={() => setEditComment({ id: "", payload: "" })} title="Cancel">
              <XCircleIcon className="w-6 text-gray-600" />
            </button>
          </>
        ) : (
          <>

...

We've changed Reply of to our Reply icon, and changed Confirm and Cancel too.
We didn't change much, but looks way better!

Implementing SWR

Finally, we will gonna fix the data fetching part, which right now user needs to reload everytime they modify(create, edit, delete) the comments.
By using amazing library called SWR, we will gonna fix this problem and it will take our comment section's user experience into whole another level.

A brief overview of SWR

There are numerous data-fetching libraries for Next.js, but one of the most popular and easiest to use is SWR.
Here's a simple example from their official document page(modified a little bit for better understanding).



import useSWR from 'swr';

const fetcher = (url: string) => fetch(url).then((res) => res.body);

function Profile() {
  const { data, error } = useSWR('/api/user', fetcher);

  if (error) return <div>failed to load</div>;
  if (!data) return <div>loading...</div>;
  return <div>hello {data.name}!</div>;
}

This simple looking code does something beautiful.

It uses a hook called useSWR, which takes 2 arguments:
- An url to fetch a data.
- An fetcher function that'll fetch from the given url.
Then you can just use the the data, like you use a React state.

See? It's so simple! Say goodbye to the hard days where you had to use several useStates and useEffects to manipulate and update the
remote date - which is complicated easy to make mistakes.

As the name propose, the mechanism for this comes from a HTTP cache invalidation strategy called stale-while-revalidate.
Explaining the details about it is beyond our article, so better check out
this link if you're interested.

Setting SWR, and refactor APIs

Now let's install SWR with the command below.



$ yarn add swr

And we will replace our old method of fetching data to new one, using useSWR.

But first I am pretty sure our code need some refactoring, since we already have too much API-related code in our client-side file index.tsx.
Thankfully, Next.js provides us a api directory inside pages directory, which you can put all kinds of API codes.

Let's make new file pages/api/comments.ts, with the code down below.



import { createClient } from "@supabase/supabase-js";
import { NextApiRequest, NextApiResponse } from "next";

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL + "";
const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_KEY + "";

export const supabase = createClient(supabaseUrl, supabaseKey);

const CommentsApi = async (req: NextApiRequest, res: NextApiResponse) => {
  switch (req.method) {
    // Get all comments
    case "GET":
      const { data: getData, error: getError } = await supabase.from("comments").select("*");
      if (getError) {
        return res.status(500).json({ message: getError.message });
      }
      return res.status(200).json(getData);
    // Add comment
    case "POST":
      const comment = req.body;
      const { data: postData, error: postError } = await supabase.from("comments").insert(comment);
      if (postError) {
        return res.status(500).json({ message: postError.message });
      }
      return res.status(200).json(postData);
    // Edit comment
    case "PATCH":
      const { commentId: editcommentId, payload } = req.body;
      const { data: patchData, error: patchError } = await supabase
        .from("comments")
        .update({ payload })
        .eq("id", editcommentId);
      if (patchError) {
        return res.status(500).json({ message: patchError.message });
      }
      return res.status(200).json(patchData);
    // Delete comment
    case "DELETE":
      const { comment_id: deleteCommentId } = req.query;
      if (typeof deleteCommentId === "string") {
        const { data: deleteData, error: deleteError } = await supabase
          .from("comments")
          .delete()
          .eq("id", deleteCommentId + "");
        if (deleteError) {
          return res.status(500).json({ message: deleteError.message });
        }
        return res.status(200).json(deleteData);
      }
    default:
      return res.status(405).json({
        message: "Method Not Allowed",
      });
  }
};

export default CommentsApi;

Now that's a lot of code all of a sudden! Don't worry, I'll explain one-by-one.

CommentsApi function takes req which is a request from the caller of this API, and res which is a response that we'll modify according to the request.
Inside the function, we encounter a switch condition filter with 5 cases:
- case "GET": This will be called for getting comments.
- case "POST": This will be called for adding a comment.
- case "PATCH": This will be called for editing a comment.
- case "DELETE": This will be called for deleting a comment.
- default: This will omit error for unsupported methods.

So what we've done is just moving the API related stuffs to this file.
Each implementation inside the case block is identical to ones we've written in index.tsx.
It uses await supabase.from("comments").something(...) for every case.

Now we've made our decent looking API code, how do we access to it? It's super-easy - Just fetch "/api/comments".

Replacing 'get comments'

Now we are going to use our well organized comments.ts API with useSWR hook.
First let's replace the old implementation of getting all the comments.

Edit & Delete codes in index.tsx with the code below.




...

const fetcher = (url: string) => fetch(url, { method: "GET" }).then((res) => res.json());

const Home: NextPage = () => {
  const { data: commentList, error: commentListError } = useSWR<CommentParams[]>("/api/comments", fetcher);
  /* Deleted
    const [commentList, setCommentList] = useState<CommentParams[]>([]);
    */
  const [comment, setComment] = useState<string>("");

...

    /* Deleted
    const getCommentList = async () => {
        const { data, error } = await supabase.from("comments").select("*");
        if (!error && data) {
            setCommentList(data);
        } else {
            setCommentList([]);
        }
    };

    useEffect(() => {
        getCommentList();
    }, []);
    */

...

<div className="flex items-center justify-start gap-2">
    <ReplyIcon className="w-4 text-gray-600 rotate-180" />
    <p className="font-extralight italic text-gray-600 text-sm">
        {commentList?.find((comment) => comment.id === replyOf)?.payload ?? ""}
    </p>
</div>

...

    {(commentList ?? [])
        .sort((a, b) => {
            const aDate = new Date(a.created_at);

...

<div className="flex items-center justify-start gap-2">
    <ReplyIcon className="w-3 text-gray-600 rotate-180" />
    <p className="font-extralight italic text-gray-600 text-xs">
        {commentList?.find((c) => c.id === comment.reply_of)?.payload ?? ""}
    </p>
</div>

...

Here's what happened:

Removed commentList React State, getCommentList function and useEffect which was used to update comments when data is refetched.
Replaced that part with a single line of code(or maybe 2 or 3 lines of code depending on your formatter), using useSWR hook.
- Same as an example from above, it contains url("/api/comments") and fetcher.
- Since we are using GET method with fetch, our GET case in comments.ts is executed, which fetches the full comment list.
Added little ? and ?? [] to commentList when it's used for finding or sorting something.
- A reason for this is because our data fetched from useSWR is fallible, so it counts for the chance to being a undefined for fetch failure.
- So we should inform the find function with ? typing that it might contain the undefined data.
- For sort function, which doesn't tolerate undefined, we have to hand over at least the empty array.

We changed our code a lot, in a good way! Our comment section should work just the same.

Replacing "add comments"

Next we'll replace 'add comment' feature. To do that we have to add another fetching function which will send a post request to our comments.ts.

Add addCommentRequest function right after fetcher.




...

const fetcher = (url: string) => fetch(url, { method: "GET" }).then((res) => res.json());

const addCommentRequest = (url: string, data: any) =>
  fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data),
  }).then((res) => res.json());

const Home: NextPage = () => {

...

We stringify the comment data and post it. No difficult things to be explained.

Now we'll use an interesting feature of SWR, called mutate.
Using mutate we can modify the local cache of comment list before we even refetch the updated list from Supabase server.

Let's discover the behaviour by just implementing it. Update the onSubmit function, and edit our add comment form.




...

  const onSubmit = async (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    const newComment = {
      username: "hoonwee@email.com",
      payload: comment,
      reply_of: replyOf,
    };
    if (typeof commentList !== "undefined") {
      mutate("api/comments", [...commentList, newComment], false);
      const response = await addCommentRequest("api/comments", newComment);
      if (response[0].created_at) {
        mutate("api/comments");
        window.alert("Hooray!");
        setComment("")
      }
    }
  };

...

    <input
        onChange={onChange}
        value={comment}
        type="text"
        placeholder="Add a comment"
        className="p-2 border-b focus:border-b-gray-700 w-full outline-none"
    />

We removed our old await supabase... and replaced it with someting else:

We added two mutate functions, which will refetch comment list that has added a new comment. But why two?
- The first one won't actually refetch the data. Instead it will assume that adding a comment has succeeded, and pretend that it refetched it by modifying the local cache of comment list.
- Now the second one will actually refetch the data, and compare between data modified and data refetched. When it's equal, it does nothing. While there's any difference, it will rerender for the correct comment list.
There's a await addCommentRequest function call in between two mutate functions. This will send a POST request to comments.ts API, and return the response for the request.
- Once succeeded adding a comment, it will return an array with single comment item.
- So if the response is an array, and the first element has created_at field, the request is confirmed to be successful so we'll use second mutate function to compare with modified cache, and initalize the comment form with setComment by setting an empty string.

Now with our powerful cache-modifying code, we can see updated comment list without reloading the page!

Replacing "edit, delete comments"

Let's practice using mutate one more time, replacing old code for editing comment.
Add & Replace code like down below.




...

const editCommentRequest = (url: string, data: any) =>
  fetch(url, {
    method: "PATCH",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data),
  }).then((res) => res.json());

...

  const confirmEdit = async () => {
    const editData = {
      payload: editComment.payload,
      commentId: editComment.id,
    };
    if (typeof commentList !== "undefined") {
      mutate(
        "api/comments",
        commentList.map((comment) => {
          if (comment.id === editData.commentId) {
            return { ...comment, payload: editData.payload };
          }
        }),
        false
      );
      const response = await editCommentRequest("api/comments", editData);
      console.log(response);
      if (response[0].created_at) {
        mutate("api/comments");
        window.alert("Hooray!");
        setEditComment({ id: "", payload: "" });
      }
    }
  };

...

The flow is the same as we've done for onSubmit function.

We first added a editCommentRequest fetcher function.
We added two mutate, the pretending one, and the real one in confirmEdit.
Before executing 2nd mutate, we check if our request has succeeded with response[0].created_at.
Finally we reset the editComment state.

Let's do the same work for deleting comments.




...

const deleteCommentRequest = (url: string, id: string) =>
  fetch(`${url}?comment_id=${id}`, { method: "DELETE" }).then((res) => res.json());

...

  const confirmDelete = async (id: string) => {
    const ok = window.confirm("Delete comment?");
    if (ok && typeof commentList !== "undefined") {
      mutate(
        "api/comments",
        commentList.filter((comment) => comment.id !== id),
        false
      );
      const response = await deleteCommentRequest("api/comments", id);
      if (response[0].created_at) {
        mutate("api/comments");
        window.alert("Deleted Comment :)");
      }
    }
  };

...

No explaination needed! It's the same as we did for editing comment.

Try editing & deleting comment, and check if the comment list changes properly without reloading.

And we are done!

Congratulations! We successfully built a comments section with feature of:

CRUD(Create, Read, Update, Delete)ing the comments, with Supabase node library.
Mutate UI without reloading with SWR
Clean & understandable design, powered by TailwindCSS and Hero Icons.

Although our comment section is awesome, there are some improvements to be made (do it by yourself!):

Replace browser's alert/confirm window to toast UI. It will look better.
Implement user login, to make it usable in community service. You can make it from scratch, or...
- Use Supabase's native user table
- Use Magic.
- Use NextAuth.
Transform the replying system into threads.

And that's all for this series! Thank you so much for following up this far, and I hope to see you on my next blog post/series!

Until then, happy coding!

DEV Community: Hoon Wee

Every Neovim, Every Config, All At Once

Neovim is hot 🔥 right now

You can build your own IDE, or should I say, own IDEs(plural)

Example: Using LunarVim and NvChad at the same time

Example: Make aliases for each config

Conclusion

How to cast & validate map-typed Ecto schema field

Problem

Solution: Ecto.Changeset.cast_embed/3

What if we want to make location type reusable?

Summary

Top 3 Elixir books that will make you love Elixir even more

Introduction: Beyond the basics

Real-Time Phoenix by Stephen Bussey

Metaprogramming Elixir by Chris McCord

Concurrent Data Processing in Elixir by Svilen Gospodinov

Conclusion

What's the use of zero-sized types in Rust?

A struct type without any fields

Rust's modern type system

Zero-sized type

Usage of Zero-sized type - a state machine

Building food delivery state machine with ZST

1. States and Default

2. Green/Red paths - State transitions

3. Shared methods

4. Test scenarios

Conclusion

Rust structs - How well are you using it?

How well are you using structs?

Method 1: Public struct with public fields

Pros: Super Simple

Cons: Too easy to access

Method 2: Using Getter and Setter

Pros: Nicely encapsulated

Cons: Verbose

For the lazy developers - use getset

Method 3: Builder Pattern

Pros: Complete Segregation

Cons: Even longer code

Ergonomic Builder Pattern

Conclusions

Build comments section with Next.js and Supabase

Let's build our own comments section because... why not?

Our goal

What do we need?

Local Settting: Next.js and TailwindCSS

Create Next App

Add TailwindCSS for NextJS

Remote Setting: Supabase

Create an organization and a project

Create comments table

Create comment

Add input form and Supabase client library

Make our messenger for Supabase

Understanding environment variables

Send an insert request

Read comments

Create a comment list

Send a select request

Sort comments by created order

Update and Delete Comments

Plan a feature

Create edit input form

Constructing update request

Disable Confirm button when comment is not edited

Indicate edited

Delete comment

Replying to Comments

How our reply will work

Adding Reply of: ....

Restyling using Icons

Problems with text-only UI

Text → Icons

Implementing SWR

A brief overview of SWR

Setting SWR, and refactor APIs

Replacing 'get comments'

Replacing "add comments"

Solution: `Ecto.Changeset.cast_embed/3`

How well are you using `struct`s?

For the lazy developers - use `getset`

Create `comments` table

Send an `insert` request

Send a `select` request

Constructing `update` request

Disable `Confirm` button when comment is not edited

Indicate `edited`

Adding `Reply of: ....`