DEV Community: Mohamad Harith

The Difference between sync.Mutex and sync.RWMutex in Golang Explained in Simple Terms

Mohamad Harith — Mon, 20 Nov 2023 08:11:42 +0000

What is Mutex?

Mutex (mutual exclusion) is an object used to synchronise concurrent threads accessing a shared resource to prevent race conditions, which is a situation that happens when multiple concurrent threads access a shared resource and try to modify it, leading to an incorrect data or an unexpected behaviour.

Race Condition Example in Go

The below program demonstrates a race condition where we start with a shared resource variable of type integer initialised to zero, and we increment it in one loop and decrement it in another, both happening at the same time concurrently using goroutines. We use sync.WaitGroup to wait for all the goroutines to finish before terminating the program. At the end of the execution, we expect resource to be back to 0, but it does not. This is known as race condition as multiple goroutines tries to access and modify the resource at the same time which leads to incorrect data.



package main

import (
    "fmt"
    "sync"
)

var resource int32 = 0

func Increment(wg *sync.WaitGroup) {
    resource = resource + 1
    wg.Done()
}

func Decrement(wg *sync.WaitGroup) {
    resource = resource - 1
    wg.Done()
}

func main() {
    const ITERATIONS = 500
    wg := &sync.WaitGroup{}

    for i := 0; i < ITERATIONS; i++ {
        wg.Add(1)
        go Increment(wg)
    }

    for i := 0; i < ITERATIONS; i++ {
        wg.Add(1)
        go Decrement(wg)
    }

    wg.Wait()

    fmt.Println(resource) // does not print 0
}

Using Golang's `sync.Mutex`

To fix the race condition in the code above, we can use a mutex. A mutex is like a lock that we could acquire before allowing the program control to the critical section of the code to the shared resource. This allows only one goroutine to access the resource at a time, ensuring no conflicts occur. We lock it when one goroutine is using it, and unlock it when it's done, so the next one can use it. This ensures that the operations on resource happen one at a time, preventing conflicts and giving the expected result. Golang provides mutex in the sync package. As such, we can use sync.Mutex to implement a mutex as follows:



package main

import (
    "fmt"
    "sync"
)

var resource int32 = 0

func Increment(wg *sync.WaitGroup, mu *sync.Mutex) {
    mu.Lock()
    defer mu.Unlock()

    resource = resource + 1
    wg.Done()
}

func Decrement(wg *sync.WaitGroup, mu *sync.Mutex) {
    mu.Lock()
    defer mu.Unlock()

    resource = resource - 1
    wg.Done()
}

func main() {
    const ITERATIONS = 500
    wg := &sync.WaitGroup{}
    mu := &sync.Mutex{}

    for i := 0; i < ITERATIONS; i++ {
        wg.Add(1)
        go Increment(wg, mu)
    }

    for i := 0; i < ITERATIONS; i++ {
        wg.Add(1)
        go Decrement(wg, mu)
    }

    wg.Wait()

    fmt.Println(resource) // prints 0
}

By implementing a mutex as shown above, we are able to prevent the race condition that we saw earlier and the value of the resource variable does indeed become zero at the end of the execution.

The Shortcomings of `sync.Mutex`

sync.Mutex provides an exclusive lock, also known as write lock where only one thread can access the shared resource at a time before we modify the resource. However, what if we would like to have read lock where we can have multiple threads reading a shared resource and while it is being read, we prevent any other threads from modifying the resource? This is where sync.RWMutex comes into picture.

sync.RWMutex is similar to sync.Mutex where it provides write lock, i.e., sync.RWMutex.Lock. In addition to that, sync.RWMutex also provides read lock, i.e., sync.RWMutex.RLock. Let's see these locks in action below:



package main

import (
    "fmt"
    "sync"
    "time"
)

var resource int32 = 0

func Read(rwm *sync.RWMutex, wg *sync.WaitGroup) {

    rwm.RLock()
    fmt.Println("read lock acquired")

    time.Sleep(time.Second * 3)

    fmt.Println("read lock released")
    rwm.RUnlock()
    wg.Done()
}

func Write(rwm *sync.RWMutex, wg *sync.WaitGroup) {

    rwm.Lock()
    fmt.Println("write lock acquired")

    resource = resource + 1
    time.Sleep(time.Second * 3)

    fmt.Println("write lock released")
    rwm.Unlock()
    wg.Done()

}

func main() {
    rwm := &sync.RWMutex{}
    wg := &sync.WaitGroup{}

    for i := 0; i < 5; i++ {
        wg.Add(2)
        go Write(rwm, wg)
        go Read(rwm, wg)
    }

    wg.Wait()
}

Sample Output:



read lock acquired
read lock acquired
read lock released
read lock released
write lock acquired
write lock released
read lock acquired
read lock acquired
read lock acquired
read lock released
read lock released
read lock released
write lock acquired
write lock released
write lock acquired
write lock released
write lock acquired
write lock released
write lock acquired
write lock released

In the output above, we can observe that we were able to acquire multiple read locks (sync.RWMutex.RLock) at the same time, in contrary to the write locks (sync.RWMutex.Lock) which we were only able to acquire one lock at a time. As such, the following are true for sync.RWMutex:

sync.RWMutex.Lock(write lock) can only be acquired if the write lock has not already been acquired AND sync.RWMutex.RLock (read lock) has not been acquired.
sync.RWMutex.RLock (read lock) can only be acquired if sync.RWMutex.Lock (write lock) has not been acquired.
Both sync.RWMutex.Lock (write lock) and sync.RWMutex.RLock (read lock) are blocking. As such, sync.RWMutex.Lock (write lock) waits for all the sync.RWMutex.RLock (read lock) or a sync.RWMutex.Lock (write lock) that were acquired earlier to be released before being able to acquire a lock. On the other hand, sync.RWMutex.RLock (read lock) waits for a sync.RWMutex.Lock (write lock) that was acquired earlier to be released before being able to acquire a lock.

Conclusion

In conclusion, both sync.Mutex and sync.RWMutex are Golang primitives that provide mutex. sync.Mutex only provides a read lock mutex. On the other hand, sync.RWMutex provides both read lock and write lock mutex. The decision as to which one to use depends on the use case. If the application mostly does reads and occasional writes, then sync.RWMutex would be suitable. Contrarily, if the application mostly does writes and occasional reads, then sync.Mutex would be suitable.

Test your Understanding

The following programs demonstrate how the order of acquiring read or write locks results in successful lock acquirement. Some of these programs may panic due to deadlock. Which of the following programs may or may not panic?

```golang

package main

import (
"fmt"
"sync"
"time"
)

func main() {

m := &sync.Mutex{}

m.Lock()

m.Lock()

}


2.
```golang


package main

import (
    "sync"
)

func main() {

    m := &sync.Mutex{}

    m.Lock()
    m.Unlock()

    m.Lock()
}



package main

import (
    "sync"
)

func main() {

    m := &sync.RWMutex{}

    m.Lock()
    m.Unlock()

    m.RLock()

    m.Lock()
}



package main

import (
    "sync"
)

func main() {

    m := &sync.RWMutex{}

    m.Lock()
    m.Unlock()

    m.RLock()
    m.RUnlock()

    m.Lock()
}



package main

import (
    "sync"
)

func main() {

    m := &sync.RWMutex{}

    m.RLock()
    m.RLock()
    m.RLock()

    m.RUnlock()

    m.Lock()
}



package main

import (

    "sync"

)

func main() {

<span class="n">m</span> <span class="o">:=</span> <span class="o">&amp;</span><span class="n">sync</span><span class="o">.</span><span class="n">RWMutex</span><span class="p">{}</span>

<span class="n">m</span><span class="o">.</span><span class="n">RLock</span><span class="p">()</span>
<span class="n">m</span><span class="o">.</span><span class="n">RLock</span><span class="p">()</span>
<span class="n">m</span><span class="o">.</span><span class="n">RLock</span><span class="p">()</span>

<span class="n">m</span><span class="o">.</span><span class="n">RUnlock</span><span class="p">()</span>
<span class="n">m</span><span class="o">.</span><span class="n">RUnlock</span><span class="p">()</span>
<span class="n">m</span><span class="o">.</span><span class="n">RUnlock</span><span class="p">()</span>

<span class="n">m</span><span class="o">.</span><span class="n">Lock</span><span class="p">()</span>



}

Reference

https://programmer.ink/think/go-mutex-sync.mutex-and-read-write-lock-sync.rwmutex.html

Understanding Unicode and UTF-8 with Golang

Mohamad Harith — Tue, 03 Oct 2023 08:36:37 +0000

For a very long time since I started my programming journey few years ago, character encoding schemes has always puzzled me. I simply did not understand what is Unicode, what is UTF-8 and other programming jargon thrown at us in this programming world. However, recently, after a little research and reading, I think I have somewhat better understanding of them which I would like to share, particularly on Unicode and UTF-8, in this article. I have tried to write this article in the simplest way possible based on my understanding of these two concepts.

What is Unicode?

Unicode is a character encoding scheme.

As we all know, characters are represented as binaries in computers.

Having said that, we need to know the encoding scheme beforehand to interpret a set of encoded binaries. For example, the binary pattern 01011101 could represent anything known only to the person encoded it using an encoding scheme.

There are various encoding schemes that were developed over the years among which, the popular ones, include the 7-bit US-ASCII, 8-bit Latin-1 and Unicode.

The encoding schemes that came before Unicode was not able to represent all characters in every writing systems.

Contrarily, Unicode, developed by The Unicode Consortium, aims to provide a standard and universal encoding scheme that can represent all characters in every writing system including emojis!.

Unicode does this by assigning a unique code point to every character in every writing system.

Unicode currently uses 21 bits (about 2 million characters) to represent every characters in every writing system.

Unicode is backward compatible with the 7-bit US-ASCII and 8-bit Latin-1, that is, the first 128 characters in Unicode are the same as the 7-bit US-ASCII and the first 256 characters in Unicode are the same as the 8-bit Latin-1 (8-bit Latin-1 is also backward compatible with 7-bit US-ASCII).

Unicode is actually an encoding system rather than an encoding scheme because it defines the unique code point for every characters in every writing systems and defines several encoding schemes under it such as UCS-2, UCS-4, UTF-8, UTF-16 and UTF-32.

Among these Unicode encoding schemes, UTF-8 is the most widely used encoding scheme which will be the focus of this article.

The diagram above shows a segment of the Unicode code points, from U+0000H to U+FFFFH (65,536 characters) known as the Basic Multilanguage Plane (BMP) which covers all the major languages in use today:

What is UTF-8?

UTF-8 is a variable-length encoding scheme, unlike other encoding schemes such as UCS-2, UCS-4,and UTF-32 which are fixed length.

UTF-8 can represent a character in 1 to 4 bytes depending on its Unicode code point.

Fixed length encoding schemes are inefficient because they may take more bytes than necessary to represent a character that may not require that much bytes.

For example, to encode the letter 'a', which has a unique code point of U+0061, in UCS-2, it would take 2 bytes. Whereas, to encode the same character in UTF-8, it would only take 1 byte as shown below:

Letter 'a' (U+0061) encoded in UCS-2: 00000000 01100001 (2 bytes)
Letter 'a' (U+0061) encoded in UTF-8: 01100001 (1 byte)

To encode a text that mostly contains ASCII characters, it would be highly inefficient to use any fixed-length encoding scheme such as the UCS-2.

Therefore, UTF-8 was devised which aims to be a more efficient variable-length encoding scheme.

UTF-8 has a mechanism to encode the Unicode code points to UTF-8 encoding based on the number of bits the Unicode code point initially occupies.

The transformation between Unicode and UTF-8 is as follows:

For example, the encoding of the character '💻' in UTF-8 is as follows:

a. Determine the Unicode code point of the character you want to encode. The Unicode code point of '💻' is U+14FBB

b. Determine the number of bytes needed to represent the character in UTF-8:

If the code point is within the range 0x0000 to 0x007F (7-bit range), it can be represented in one byte.
If the code point is within the range 0x0080 to 0x07FF (11-bit range), it can be represented in two bytes.
If the code point is within the range 0x0800 to 0xFFFF (16-bit range), it can be represented in three bytes.
If the code point is within the range 0x10000 to 0x10FFFF (21-bit range), it can be represented in four bytes.

c. Encode the Unicode code point into the appropriate number of bytes following the UTF-8 encoding rules:

For a one-byte character (0x0000 to 0x007F), the UTF-8 representation is the same as the code point.
For multi-byte characters, specific bit patterns as shown in the table above are used to indicate the number of bytes and store the bits from the code point in each byte. The most significant bits indicate the number of bytes used.

The code point U+1F4BB ('💻') will be represented as 0xF09F92BB in UTF-8 because it falls within the 21-bit range and can be encoded using 4 bytes.

The diagram below shows the step by step process of encoding U+1F4BB ('💻') to UTF-8:

Seeing the Unicode and UTF-8 in Action In Go



package main

import "fmt"

func main() {
    char := '💻'

    // prints Unicode code point of 💻
    fmt.Printf("The Unicode code point of 💻: U+%X\n", char)

    byteArr := []byte(string(char))

    fmt.Printf("No. of bytes 💻 takes: %d bytes\n", len(byteArr))

    // prints in UTF-8 encoding of  💻 in binary form
    fmt.Print("The UTF-8 encoding of 💻 in binary: ")
    for _, v := range byteArr {
        fmt.Printf("%08b ", v)
    }

    fmt.Println()

    // prints in UTF-8 encoding of  💻 in hexadecimal form
    fmt.Print("The UTF-8 encoding of 💻 in hexadecimal: ")
    for _, v := range byteArr {
        fmt.Printf("%X", v)
    }
}

The program above prints the Unicode code point of '💻' and its UTF-8 encoding. From the program above, we can indeed verify the Unicode code point of '💻' is indeed U+14FBB and it's Unicode encoding is 11110000 10011111 10010010 10111011.

As a conclusion, Unicode is character encoding system that defines a unique code point for every characters in every writing system. UTF-8 is a variable length character encoding scheme under Unicode that is widely used today. Although UTF-8 takes extra overhead to encode and decode an Unicode code point, it overall improved the efficiency of texts that mostly contains ASCII characters.

Reference:

https://www3.ntu.edu.sg/home/ehchua/programming/java/datarepresentation.html

Explain Javascript as a Single Threaded Non-blocking Asynchronous Programming Language Like I'm Five

Mohamad Harith — Sun, 07 Aug 2022 12:27:00 +0000

When I first started to learn Javascript in depth, this is the description of Javascript that I stumbled upon:

A single threaded non-blocking asynchronous programming language.

In this article, I would like to attempt to explain the above description of Javascript.

Based on the description above, if Javascript is single threaded, meaning it could only perform one task at a time, how could it be non-blocking when performing asynchronous tasks - tasks that takes longer time to complete, without blocking the execution of the main thread? Mustn't Javascript be doing multithreading if it were to perform such asynchronous tasks?

Let's look at the example below and see whether Javascript is really single threaded like how it claims to be:

function getData() {
  setTimeout(function print() => {
    console.log("hello");
  }, 1000);
}

function main() {
  getData();
  console.log("world");
}

main();

// output1:
// hello
// world

// OR

// output2:
// world
// hello

Based on the code snippet above, try to guess which output the program would produce - output1 or output2?

Most of us would easily guess it is output2 and yes, it is correct. From an amateur programmer point of view, output2 makes perfect sense, because getData takes 1 second to resolve, hence the program would log world followed by hello once the 1 second has passed. So what is the catch here? Well, the catch is that Javascript is single threaded!

If Javascript is really single threaded, like how it claims to be, it would have produced output1 instead of output2. This is because, for single threaded languages, it would need to wait for the getData to be resolved first and would block the execution of the subsequent lines, hence logging hello followed by world.

But as you can see above, this wasn't the case because calling getData did not block the execution of the subsequent lines (this is what they mean when they say Javascript is non-blocking) and the program logged world first and once getData got resolved after sometime (this is what they mean by asynchronous - something that takes longer time to complete), it then logged hello.

So, is Javascript really single threaded like how it claims to be? The answer is yes. But, how does Javascript achieves this non-blocking asynchronous nature while being single threaded?

You see, although Javascript itself is a single threaded language, Javascript engines such as the V8 engine provides components such as the call stack, callback queue, event loop and makes use of the web APIs provided by the web browser and augments Javascript to create its multithreading illusion.

Below are the comprehensive definition of these components:

Call Stack - a stack data structure that keeps track of where in the program we are. While the Javascript engine interprets the code, when it runs into a function, it would be put on the stack and when a function is returned, the top of the stack would be popped off.
Web APIs - a set of APIs such as the setTimout, fetchAPI and DOM Event Listeners APIs provided by the browser which would be consumed by the Javascript engine. These APIs would run on a separate thread in the browser. A Javascript callback would be required to be provided in order to call these APIs.
Callback Queue - a queue data structure that keeps track of the callbacks. When any of the calls to the Web API completes, it's callback function would be pushed into the Callback Queue.
Event Loop - an observer that looks at the Call Stack and Callback Queue. Whenever the Call Stack is empty, it would pop the first item from the Callback Queue and pushes it into the Call Stack. This process would run forever in loop.

In regards to the above program, the following is what happens under the hood:

Function call main() gets pushed into the Call Stack.
Function call getData() gets pushed into the Call Stack.
Function call setTimeout() gets pushed into the Call Stack.
A call to the Web API's setTimeout() function is made with print() as its callback and the Web API starts a timer. Once 1 second has passed, the Web API would push the print() callback to the Callback Queue.
Function call setTimeout() returns and it is popped off the Call Stack.
Function call getData() returns and it is popped off the Call Stack.
Function call console.log("world") get pushed into the Call Stack.
Function call console.log("world") prints world and returns.
Function call console.log("world") is popped of the Call Stack.
Function call main()is popped of the Call Stack.
The call stack is now empty, the Event Loop looks at the Callback Queue to see if there are any callbacks present to be pushed into the Call Stack.
If 1 seconds had already passed by now, the print() callback would have been passed to the Callback Queue. The event loop pops the print() callback off the Callback Queue and pushes it into the Call Stack.
Function console.log("hello") get pushed into the Call Stack.
Function console.log("hello") prints hello and returns.
Function console.log("hello") is popped of the Call Stack.
Function print() is popped of the Call Stack.

Below is the visualisation of the process mentioned above and this visualisation can be found here.

As a conclusion, I think we have made justice that Javascript is a single threaded non-blocking asynchronous programming language. Javascript engines, such as the V8 engine augments Javascript and creates an illusion that it is multithreaded using various components such as the call stack, callback queue, event loop and web APIs.

I would like to end this article with a quiz to test our understanding of Javascript internals, please free to answer them in the comments below.

// What would be the output when main is called?
// Wiil it output output1 or output2?

function main() {
  console.log("1");
  setTimeout(function callback() {
    console.log("2");
  }, 0);
  console.log("3");
}

main();

// output1:
// 1
// 2
// 3

// output2:
// 1
// 3
// 2

Reference:

What the heck is the event loop anyway? | Philip Roberts | JSConf EU

Trying Out Go v1.18 Generics

Mohamad Harith — Sat, 19 Mar 2022 20:05:17 +0000

Generics allow us to write functions that can be used with arguments of any data type. The latest version of Go has introduced generics into the language. Therefore, in this article I'd like to explore the usage of generics in Go.

Before Go v1.18

The were no generics in the older versions of Go. However one workaround for generics in older versions of Go is the empty interface, interface{} in combination with type assertion and reflection. For example, lets say we want to write a function that would take an array of any type and sum up the array, in older versions of Go we would have to do something like this:

func sumAnyType(i interface{}) (o interface{}) {

    value := reflect.ValueOf(i)

    if reflect.TypeOf(i).Kind() != reflect.Slice || value.Len() < 1 {
        return
    }

    switch value.Index(0).Kind() {
    case reflect.Int:
        var res int = 0
        for i := 0; i < value.Len(); i++ {
            res += value.Index(i).Interface().(int)
        }
        return res
    case reflect.Float64:
        var res float64 = 0
        for i := 0; i < value.Len(); i++ {
            res += value.Index(i).Interface().(float64)
        }
        return res
    }

    return
}

func main() {

    log.Println(sumAnyType([]int{1, 2, 3})) // prints 6

    log.Println(sumAnyType([]float64{1.2, 2.5, 3.9})) // prints 7.6

    log.Println(sumAnyType([]float32{1.2, 2.5, 3.9})) // prints nil
}

Although the above works, there are some downsides one of which is code repetition. We are writing the summing logic for each data types and if the logic for particular data type is not written, the array of that type cant be summed.

Go v1.18 Generics

With the introduction of generics in the latest version of Go, the above example can be simplified to the following:

func sumAnyType[T int | float64](i []T) (o T) {
    for _, v := range i {
        o += v
    }
    return
}

func main() {

    log.Println(sumAnyType([]int{1, 2, 3})) // prints 6

    log.Println(sumAnyType([]float64{1.2, 2.5, 3.9})) // prints 7.6

    // log.Println(sumAnyType([]float32{1.2, 2.5, 3.9})) // does not compile
}

As you see above, Go generics greatly simplifies the codes and enforces the Don't Repeat Yourself (DRY) principle as we are able to use the same function for multiple data types without having to rewrite the same logic for each data types.

Now that we understand the significance of generics in Go, lets understand the various features introduced for generics in Go v1.18:

1. The any keyword
The any keyword is just an alias to the empty interface, interface{}. That means, anything that we can do with interface{} can also be done with any. For example:

func printType(i any) {
    _, ok := i.(string)
    if ok {
        log.Println("its a string")
    }
    _, ok = i.(int)
    if ok {
        log.Println("its a integer")
    }
}

2. Type parameters, type arguments and type constraints
Type parameters is what allows a function to be generic, allowing it to work with arguments of different types. We'll call the function with type arguments and the ordinary function arguments. Type constraint defines a list of types a function can receive.

3. The comparable type costraint
comparable is a predeclared type constraint in Go v1.18 that denotes the types that can be compared using == or !=.

4. Type constraint as an interface
The type constraint can also be declared as an interface so that it can be reused. For example:


type CustomConstraint interface {
    int | float64
}

func addOne[T CustomConstraint](i T) (o T) {
    o = i + 1
    return
}

func multiply2[T CustomConstraint](i T) (o T) {
    o = i * 2
    return
}

func main() {

    log.Println(addOne[int](1))
    log.Println(multiply2[float64](3.14))
}

5. The ~ keyword

A type constraint can be prefixed with ~ to restrict all the custom types whose underlying type is the same as the constraint.

The following does not compile because CustomConstraint only restrict type int:

type CustomInt int

type CustomConstraint interface {
    int
}

func addOne[T CustomConstraint](i T) (o T) {
    o = i + 1
    return
}

func main() {

    log.Println(addOne[CustomInt](1))
}

The following compiles successfully because CustomConstraint restricts int and all the other custom types whose underlying type is int:

type CustomInt int

type CustomConstraint interface {
    ~int
}

func addOne[T CustomConstraint](i T) (o T) {
    o = i + 1
    return
}

func main() {

    log.Println(addOne[CustomInt](1))
}

As a conclusion, Go generics is really useful especially to enforce DRY and can be used for various use cases. In my opinion, generics in Go is simpler and easier to understand compared to other languages such as Java.

Additional resources:

Workaround for Bubbling Custom Events in Svelte

Mohamad Harith — Sat, 25 Dec 2021 18:59:39 +0000

If you are an avid user of Svelte, you would know by now that we can create custom events in Svelte using the createEventDispatcher method.

However, there is one problem - the current version of Svelte does not bubble the custom events out of the box. As suggested by one of the maintainers of Svelte here, bubbling of custom events in Svelte would probably only be supported in v4 of Svelte. Having said that, event delegation for custom events will not work.

For example, let's say we have a child component, Nested.svelte that dispatches the custom event, my-event and let's say we have a parent component, App.svelte that contains a delegated event listener, listening for the my-event event:

Nested.svelte

<script>
    import {createEventDispatcher} from 'svelte';

    const dispatch = createEventDispatcher();

    const handleClick = ()=>{
        dispatch("my-event", "nested component is clicked")
    }
</script>

<div class="nested" on:click={handleClick}>
    nested component
</div>

<style>
    .nested{
        color:white;
        background-color:blue;
    }
</style>

The following delegated event listener in the App.svelte component would not receive the my-event event because custom events dispatched using Svelte's createEventDispatcher will not bubble.

App.svelte

<script>
    import Nested from "./Nested.svelte";

    document.addEventListener("my-event", (e)=>{
        console.log(e.detail)
    })
</script>

<div class="parent">
    Parent component
    <!--on:my-event is required here so that the event is forwarded-->
    <Nested on:my-event /> 
</div>

<style>
    .parent{
        background-color:yellow;
        padding:10px;
    }
</style>

However, there is a workaround for this issue! We can create our own custom event dispatcher using the Custom Event API like this:

Nested.svelte

<script>
    let ref;

    const handleClick = ()=>{
        const event  = new CustomEvent('my-event', {
            detail: {
                content: 'nested component is clicked'
            }, 
            bubbles: true
        });
        ref.dispatchEvent(event);
    }
</script>

<div class="nested" bind:this={ref} on:click={handleClick}>
    nested component
</div>

<style>
    .nested{
        color:white;
        background-color:blue;
    }
</style>

Using the new CustomEvent() constructor, we can create a native custom event and we can also set the bubbles parameter to true to allow the custom event to bubble.

Better yet, my HOD pointed out the custom_event function from svelte/internal. This function wraps Custom Event API and can also be used to dispatch custom events that can bubble:

Nested.svelte

<script>
    import { custom_event } from 'svelte/internal';

    let ref;

    const handleClick = ()=>{
        const event  = custom_event('my-event', 'nested component is clicked', true);
        ref.dispatchEvent(event);
    }
</script>

<div class="nested" bind:this={ref} on:click={handleClick}>
    nested component
</div>

<style>
    .nested{
        color:white;
        background-color:blue;
    }
</style>

Comparing Memory Consumption of Delegated Event Listeners and Individual Event Listeners in Javascript

Mohamad Harith — Sat, 25 Dec 2021 01:55:43 +0000

This article assumes the reader understands what is event delegation and event bubbling.

While working on a frontend project, being the amateur programmer that I am, I initially did not understand why my HOD insisted that we handle events for long list of items by means of event delegation instead of attaching individual event listeners for each list item. After hearing his explanation and doing some readings, I came to an understanding that event delegation has several benefits in comparison to attaching individual event listeners to a long a list of items. Among the benefits are as follows:-

Memory: More event listeners means more memory consumption as the browser has to listen to more events.
Code maintainability: Event delegation improves code maintainability because events from multiple elements can be handled all in one place in contrary to handling them individually.

However, in order to see the benefits of event delegation in terms of memory consumption before my own eyes, I have conducted an experiment where I wrote two HTML pages that each generated list of 100k items. For one of the lists I attached individual event listeners for each li element and and for the other list I attached a single delegated event listener on the ul element. I then compared the memory consumption of these two pages using Firefox's task manager.

Individual Event Listeners

 <body></body>
  <script>
    function handleClick(e) {
      console.log(e.target.id);
    }
    var ul = document.createElement("ul");
    for (var i = 0; i < 100000; i++) {
      var li = document.createElement("li");
      li.id = `${i}`;
      li.onclick = handleClick;
      li.innerHTML = `Item ${i}`;
      ul.append(li);
    }
    document.body.append(ul);
  </script>

Delegated Event Listeners

<body></body>
  <script>
    function handleClick(e) {
      console.log(e.target.id);
    }
    var ul = document.createElement("ul");
    ul.onclick = handleClick;
    for (var i = 0; i < 100000; i++) {
      var li = document.createElement("li");
      li.id = `${i}`;
      li.innerHTML = `Item ${i}`;
      ul.append(li);
    }
    document.body.append(ul);
  </script>

Memory Consumption

As you can see above, the memory consumption on the page that contains the list with individual event listeners was definitely higher than that of the list with delegated event listener. Therefore, it is proven that delegated event listener is more performant and should be used when listening to events from a large list of items.

Mutating Query Params in SvelteKit Without Page Reloads or Navigations

Mohamad Harith — Fri, 24 Dec 2021 13:19:04 +0000

This article assumes the reader understands the basics of SvelteKit framework.

SvelteKit is a rather new framework for building server-side rendered websites. Because it is new, some of the early adopters of the framework were confused on certain usages of the framework. One such confusion was on the usage of query params as seen in these issues: #2785, #969, #2811 - many people, including myself were confused on how to mutate query params of a page without page reloads or navigations.

Some of us thought mutating the params property of $page store would mutate the query params. But this wasn't the cause because the $page store was a read-only store.

Since SvelteKit does not provide a way to mutate the query params, my HOD and I figured that we use the History API's replace state to mutate the query params.

The function:

export const replaceStateWithQuery = (values: Record<string, string>) => {
  const url = new URL(window.location.toString());
  for (let [k, v] of Object.entries(values)) {
    if (!!v) {
      url.searchParams.set(encodeURIComponent(k), encodeURIComponent(v));
    } else {
      url.searchParams.delete(k);
    }
  }
  history.replaceState({}, '', url);
};

The usage:

  onMount(() => {
    // adds ?foo=bar&john=doe query params to the URL
    replaceStateWithQuery({
      foo: 'bar',
      john: 'doe',
    });
  });

The replaceStateWithQuery is a function that receives an object of query params and uses the History API's to set these values as the query params of the page. Both the keys and values of the query params will be URL encoded by default. If the value of a query param is null or undefined, the query will be deleted from the URL.

Improving SEO of Single Page Applications using Rendertron

Mohamad Harith — Thu, 09 Sep 2021 13:55:01 +0000

The Problem

In this era, single-page applications (SPA) dominate the Internet due to its better user experience compared to the traditional server-side rendered (SSR) pages. However, the added benefits of SPAs come with several costs, one of which is poor search engine optimization (SEO).

Because SPAs are typically rendered on the client-side, aka, client-side rendering (CSR), the contents of a website might not be visible until the Javascript codes are executed on the client-side. This is not good for search engines and social media crawlers because the meta tags required by these crawlers might not exist in the initial HTML file. This would cause the SPA site not getting indexed properly on search engines and would not get displayed properly when the link of the SPA is shared on social medias.

For example, pasting a link of a client-side rendered page on Facebook might look like this:

In contrast, pasting a link of a server-side rendered page on Facebook might look like this:

How can we solve the issues related to SEO and link sharing of SPAs?

The Solution

There are several workarounds to overcome the shortcomings related to link sharing and SEO of SPAs among which are pre-rendering and dynamic rendering. In this article, we will look at the approach of dynamic rendering to improve the SEO of our SPAs due to its easier implementation than pre-rendering. In fact, Google itself recommends dynamic rendering.

Dynamic rendering is good for indexable, public JavaScript-generated content that changes rapidly, or content that uses JavaScript features that aren't supported by the crawlers you care about. Not all sites need to use dynamic rendering, and it's worth noting that dynamic rendering is a workaround for crawlers.

What is Dynamic Rendering?

Dynamic rendering is a technique where your server serves different contents to requests coming from different user-agents. If the request is coming from a crawler, the server would route the request to a renderer which will then render out the requested page before returning the fully-rendered flat HTML page to the crawler. Otherwise, if the request is coming from a user, the server would serve normally.

What is Rendertron?

Rendertron is a tool built by the Google Chrome team that can be used for dynamic rendering. Rendertron runs as a HTTP server and it renders the requested pages using Headless Chrome. It is built on top of Puppeteer. Rendertron is highly configurable and offers alot of features out of the box. One such very useful feature is caching, which allows the renderer to cache a site on the first request and serve it faster on subsequent requests.

The Implementation

Rendertron can be Dockerised and deployed to your cloud provider. Your web server can then identify requests coming from crawlers using the user-agent header and then route the request to your deployed Rendertron service. Below is a sample Docker file and config file for Rendertron. More configs can be found on their Github repository.

Docker file:

FROM node:14.11.0-stretch

RUN apt-get update \
    && apt-get install -y wget gnupg \
    && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
    && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
    && apt-get update \
    && apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 \
    --no-install-recommends \
    && rm -rf /var/lib/apt/lists/*

# This directoty will store cached files as specified in the config.json.
# If you haven't defined the cacheConfig.snapshotDir property you can remove the following line
RUN mkdir /cache

RUN git clone https://github.com/GoogleChrome/rendertron.git

WORKDIR /rendertron

RUN npm install && npm run build

# If you aren't using a custom config.json file you must remove the following line
ADD config.json .

EXPOSE 3000

CMD ["npm", "run", "start"]

Config file:

{
    "cache": "filesystem",
    "cacheConfig": {
        "cacheDurationMinutes": 7200,
        "cacheMaxEntries": 1000,
        "snapshotDir": "/cache"
    }
}

Once deployed, you can call the /render/<url> endpoint to get the flat HTML page of the requested URL. If you are using GoFiber for your web server, the crawler requests can be routed as follows:

....

func dynamicServer(c *fiber.Ctx) error {
    userAgent := string(c.Context().UserAgent())
    reqUrl := c.Request().URI().String()
    ua := ua.Parse(userAgent)

    switch {
    case ua.Bot:
        {
            resp, err := http.Get("https:<renderer url>/render/" + reqUrl)
            if err != nil {
                log.Println(err)
            }

            defer resp.Body.Close()

            body, err := ioutil.ReadAll(resp.Body)
            if err != nil {
                log.Println(err)
            }

            return c.SendString(string(body))
        }
    default:
        return c.SendFile("dist/client/store/index.html")
    }

    return c.Next()
}

func main() {

    app := fiber.New()

    app.Get("/store*", dynamicServer)

    app.Listen(":3000")
}

We are using this package to parse and identify the user agent in Golang. However, Rendertron also provides middlewares for other languages and tools, you may refer their Github repository page.

Conclusion

The web was not initially designed for SPAs, it was only meant to serve static HTMLs. However, as computers got better, the ways websites served to us have also changed to improve our user experience. As discussed earlier, these changes come with several costs, but the tech community always develop ways to overcome those costs, one of which is dynamic rendering which is very useful to overcome SEO issues when building SPAs.

References
https://developers.google.com/search/docs/advanced/javascript/dynamic-rendering
https://www.deepcrawl.com/knowledge/ebooks/javascript-seo-guide/different-rendering-methods/
https://googlechrome.github.io/rendertron/deploy.html

DEV Community: Mohamad Harith

The Difference between sync.Mutex and sync.RWMutex in Golang Explained in Simple Terms

What is Mutex?

Race Condition Example in Go

Using Golang's sync.Mutex

The Shortcomings of sync.Mutex

Conclusion

Test your Understanding

Reference

Understanding Unicode and UTF-8 with Golang

What is Unicode?

What is UTF-8?

Seeing the Unicode and UTF-8 in Action In Go

Reference:

Explain Javascript as a Single Threaded Non-blocking Asynchronous Programming Language Like I'm Five

Trying Out Go v1.18 Generics

Before Go v1.18

Go v1.18 Generics

Workaround for Bubbling Custom Events in Svelte

Comparing Memory Consumption of Delegated Event Listeners and Individual Event Listeners in Javascript

Mutating Query Params in SvelteKit Without Page Reloads or Navigations

Improving SEO of Single Page Applications using Rendertron

The Problem

The Solution

What is Dynamic Rendering?

What is Rendertron?

The Implementation

Conclusion

Using Golang's `sync.Mutex`

The Shortcomings of `sync.Mutex`