DEV Community: Alberto De Agostini

HTML only image fallback

Alberto De Agostini — Tue, 30 Nov 2021 08:03:06 +0000

Some days ago I was doing something to personalize my Github profile page and I needed a way to display an image in case the loading of one from a service was failing (if you are curious you can read it here).
So I needed a basic fallback for an image, should not be an issue, right?

That is pretty easy to achieve using Javascript, if you google it you will find lots of solutions using jquery but also using a super simple javascript line like this:

<img src="https://not-existing-url/not-existing-image.jpeg" onerror="this.src = 'error.jpg';"

HTML only

The problem for me is that I needed an HTML pure solution because Github strips every script from the readme (for security reasons).

Fun fact: I've found a solution but that doesn't work anyway in Github profile page because this solutions uses a tag that is removed too, always for security reasons

So after some search and digging I've found this solution (thanks to Patrick McElhaney)

<object data="https://not-existing-url/not-existing-image.jpeg" type="image/jpg">
  <img src="fallback-image.jpeg" />
</object>

That's it. You can see it (and play with it) in the codepen below

How it works

The solutions involves the object tag as you may have noticed. This is a pretty unknown HTML element that can be used to display multimedia content, like videos, images, PDFs and so on.. It can be used also to display other webpages, so it may be though as the brother of iframe. It will display what you pass in the data attribute, instead the HTML you put 'inside' the tag is going to be used as a fallback in case the browser does not support the tag or if the source is not correctly loaded. So this works great for both old browsers and for content that fails to load (like in my case).
As always if you want to dig deeper MDN docs are always the first place to go.

Conclusion

So this is the only solution I've found really working with just HTML.
There are solutions also with CSS but they involves knowing the image dimensions, and that was not ok in my case because the embedded image was dynamic.
If you know a better approach please comment here or reach me on my twitter

Learn Golang basics by creating a file counter

Alberto De Agostini — Thu, 02 Sep 2021 13:47:38 +0000

Intro

Beware, this post is something I'm writing down while learning the basics of Golang, so this are just some kind of "learning notes".

I did not expect to learn much just by creating a simple script like this, but there are always hidden pitfalls where we don't expect it.

The code can be found here

So I'm going to start a new job soon and I'll be using Golang. As of today I always made frontend, mostly in javascript (typescript just for some toy projects).
So I looked at the golang tour to get the basics and also followed this amazing tutorial that I suggest everyone.

Making the script

To try out something I've decided to create a script that counts the number of files in a filesystem in 2 ways:

synchronously
asynchronously This should let me get my hands dirty with some of the core concepts of the language.

Synchronous solution

Following the 'learn go with tests' approach, via TDD, I'm first going to write a test for my function:

package filecounter

import (
    "io/fs"
    "testing"
    "testing/fstest"
)

var (
    fakeFS = fstest.MapFS{
        "root-folder":                                  {Mode: fs.ModeDir},
        "root-folder/file-1.md":                        {Data: []byte("I'm a file in the root")},
        "root-folder/sub-folder-1":                     {Mode: fs.ModeDir},
        "root-folder/sub-folder-2":                     {Mode: fs.ModeDir},
        "root-folder/sub-folder-2/file-1.md":           {Data: []byte("I'm a file in folder2")},
        "root-folder/sub-folder-2/file-2.md":           {Data: []byte("I'm another file in folder 2 ")},
        "root-folder/sub-folder-3":                     {Mode: fs.ModeDir},
        "root-folder/sub-folder-3/sub-sub-1":           {Mode: fs.ModeDir},
        "root-folder/sub-folder-3/sub-sub-1/file-1.md": {Data: []byte("file")},
    }
)

func TestFileCounter(t *testing.T) {
    t.Run("should read the number of files in a fileSystem", func(t *testing.T) {
        got, err := FileCounterSync(fakeFS)
        want := 4

        if err != nil {
            t.Errorf("Didnt expected an error, but got one %s", err)
        }

        if got != want {
            t.Errorf("got %d wanted %d", got, want)
        }
    })

Let's see what we got here...
Basically we are creating a fake FileSystem (using the fstest package) with some subfolders and a total of 4 files, this way we can test our script as many times as we want without worring that the filesystem may change. That's it.

If we try to run the test

go test

we are going to receive

undefined: FileCounterSync

So let's define this function in our file

package filecounter

import (
    "io/fs"
)

func FileCounterSync(fileSystem fs.FS) (int, error) {
    return 0, nil
}

Running now should give us a different message, something like

FAIL: got 0 wanted 4

This is expected, we didn't write the body of the function yet, so let's do it in the easiest way possible:

func FileCounterSync(fileSystem fs.FS) (int, error) {
    var numOfFiles int
    err := fs.WalkDir(fileSystem, ".", func(path string, d fs.DirEntry, err error) error {
        if err != nil {
            fmt.Println(err)
            return err
        }

        if !d.IsDir() {
            numOfFiles++
        }

        return nil
    })

    if err != nil {
        return 0, nil
    }

    return numOfFiles, nil
}

This is the easiest way that came to my mind, we are just using the WalkDir API of the 'fs' package, that let us define a function that are run for each file/folder of the given filesystem. There we can just check if the given parameter is a directory, if it's not, increment the result 🎉.

This did not teach me much, I'm writing this script to learn something about the language, not just to count files. So let's rewrite this but this time without taking advantage of the built-in WalkDir API.

func FileCounterSync(fileSystem fs.FS) (int, error) {
    dir, err := fs.ReadDir(fileSystem, ".")
    if err != nil {
        return 0, err
    }

    var numOfFiles int
    for _, f := range dir {
        if !f.IsDir() {
            numOfFiles++
        } else {
            dirs, err := fs.ReadDir(fileSystem, f.Name())
            if err != nil {
                return 0, err
            }

            for _, file := range dirs {
                if !file.IsDir() {
                    numOfFiles++
                } else {
                    n, err := countFilesRecursively(fileSystem, f.Name(), file)
                    if err != nil {
                        return 0, err
                    }
                    numOfFiles += n
                }
            }
        }
    }

    return numOfFiles, nil
}

// Helper function
func countFilesRecursively(fileSystem fs.FS, prevPath string, dir fs.DirEntry) (int, error) {
    var n int
    newPath := prevPath + "/" + dir.Name()
    dirs, err := fs.ReadDir(fileSystem, newPath)

    if err != nil {
        return 0, err
    }

    for _, file := range dirs {
        if !file.IsDir() {
            n++
        } else {
            num, err := countFilesRecursively(fileSystem, newPath, file)
            if err != nil {
                return 0, err
            }

            n += num
        }
    }

    return n, nil
}

This is a synchronous (and the dumbest) solution, basically we cycle through every file/folder, increment a counter everytime we encounter a file, call the recursion otherwise.

This was very simple and did not teach me much (apart from some syntax and the fact that I should probably handle errors better).

Try to run the tests and everything should work just fine.

Asynchronous solution

Golang is known especially for concurrency, infact the language provides some constructs to help the develpers.

I decided to try to build the script following this "rules":
Read the root folder:

count each file in it
for each subfolder calls a goroutine that:
- call the same goroutine for each subfolder
- increment the number of files for each file
wait for all the spawned goroutines to end
return the counter

The test case is still the same, so we can just rewrite the function. My first bet was:

func FileCounterAsync(fileSystem fs.FS) (int, error) {
    dir, err := fs.ReadDir(fileSystem, ".")
    if err != nil {
        return 0, err
    }

    var numOfFiles int

    for _, f := range dir {
        if !f.IsDir() {
                // count files in the root folder
            numOfFiles++
        } else {
            go countFiles(fileSystem, f.Name())
                // somehow retrieve info from the spawned goroutine
        }
    }

    return numOfFiles, nil
}

First define an helper function that given the filesystem and the path to "scan", returns the number of files AND calls itself for each subfolder

func countFiles(fileSystem fs.FS, path string) {
    dirs, err := fs.ReadDir(fileSystem, path)
    if err != nil {
        fmt.Printf("Error while reading %s", path)
    } else {
        for _, f := range dirs {
            if !f.IsDir() {
                fmt.Println("Found file " + f.Name())
                // do something to count
            } else {
                fmt.Println("Found a folder: " + f.Name())
                // spawn a dedicated goroutine
                go countFiles(fileSystem, path+"/"+f.Name())
            }
        }
    }
}

This function differentiate between files and subfolders, spawn goroutines for each subfolders, but we need a way to "return" to the called the number of files.

The right construct (and I hope I'm right) to address this issue is to create a channel, we can then use that to "return" data from the goroutines.
Also we need a way to tell the script when to end, for this I'm going to use a waitgroup.
This way the script will know when to finish.

func FileCounterAsync(fileSystem fs.FS) (int, error) {
    // previous stuff

    var numOfFiles int
    var wg sync.WaitGroup
    c := make(chan int)

    for _, f := range dir {
        if !f.IsDir() {
            numOfFiles++
        } else {
            wg.Add(1)
            go countFiles(fileSystem, &wg, f.Name(), c)
        }
    }

    go func() {
        wg.Wait()
        close(c)
    }()
    for v := range c {
        numOfFiles += v
    }

    return numOfFiles, nil
}

func countFiles(fileSystem fs.FS, wg sync.WaitGroup, path string, c chan int) {
    defer func() {
        fmt.Println("closing group for " + path)
        wg.Done()
    }()

    dirs, err := fs.ReadDir(fileSystem, path)
    if err != nil {
        fmt.Printf("Error while reading %s", path)
    } else {
        for _, f := range dirs {
            if !f.IsDir() {
                c <- 1
            } else {
                wg.Add(1)
                go countFiles(fileSystem, wg, path+"/"+f.Name(), c)
            }
        }
    }
}

Now we are "returning" the number of files counted by the goroutines with the channel and we are telling the main function "how long to wait".

Benchmarks

I wanted to confirm and see how much faster the async version is compared to the sync one so I've done some basic benchmarkings:

So using the benchmarking feature of the go test this are the results:

cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
BenchmarkFileCounterSync-8        159486              6456 ns/op
BenchmarkFileCounterAsync-8        69724             16638 ns/op

as we can see, the async version is a lot faster.

I've also tested the implementations towards a folder on my PC, this time I recorded also the sync version that used the WalkDir built-in API:

Using built-in WalkDir
Count: 34381 
Ealapsed time: 347.5736ms 

Sync version
Count: 34381 
Ealapsed time: 327.1953ms 

Async version
Count: 34381
Ealapsed time: 117.6043ms

This is the main function to accept the path as CLI parameter and to make some dumb benchmarks:

package main

import (
    filecounter "filecounter/filecounter"
    "fmt"
    "os"
    "time"
)

func main() {
    if len(os.Args) < 2 {
        panic("Path must be specified as command line argument")
    }
    path := os.Args[1]
    fs := os.DirFS(path)

    start1 := time.Now()
    res1, _ := filecounter.FileCounterEasy(fs)
    elapsed1 := time.Since(start1)

    fmt.Printf("\nEasy\nCount: %d \n", res1)
    fmt.Printf("Ealapsed time: %s \n", elapsed1)

    start2 := time.Now()
    res2, _ := filecounter.FileCounterSync(fs)
    elapsed2 := time.Since(start2)

    fmt.Printf("\nSync\nCount: %d \n", res2)
    fmt.Printf("Ealapsed time: %s \n", elapsed2)

    start3 := time.Now()
    res3, _ := filecounter.FileCounterAsync(fs)
    elapsed3 := time.Since(start3)

    fmt.Printf("\nAsync\nCount: %d \n", res3)
    fmt.Printf("Ealapsed time: %s \n", elapsed3)
}

Conclusions

the solution is probably very dumb, but it actually teach me something, especially the asynchronous because while writing it I've done a lot of small mistakes.
If you have any opinion or tips let me know!

Ellipsis on flexbox items

Alberto De Agostini — Fri, 07 Feb 2020 12:15:01 +0000

In this article I will explain how to add ellipsis on flexbox child elements.

I had this problem a while ago and I've found a solution surfing the web, I've prepared also some codepen to show examples and let you understand better.
Jump to the last codepen if you are in eagerto see the solution

What do we want

Let's see immediately what we want to achieve.

Ideally we want to create a flexbox row with one (or more) "fixed" element on the left and a long element on the right and if the flexbox container shrinks (due to a user resizing the window for example) I want the long child on the right to be truncated with ellipsis.
(The fact that the child elements are on the left or right doesn't really matter, what I will explain works also if you want to truncate the child on the left and set the one on the right as fixed)

Let's try this out

"Well... That was pretty easy... what is the problem you are talking about?"
I can hear you saying this, so I will immediately show a very similar example and we'll see if you catch what's the difference

Did you catch the difference?
The change is that in this example the flex children has some elements inside (a p element), so it's actually a more common case rather than having simple text.

Below there is the codepen with the solution, after the example I will explain what the solution is and why it works like that (because at first glance it looks like magic).

Again, did you spot the differences? (spoiler, there are two)

1) The css ellipsis properties are now applied to the p inside the flex child
2) min-width: 0 is applied to both the flex children (and this is what looked magical, at least to me)

If you are asking yourself "What? Why is a min-width: 0 solving this problem?" you are like me so I dived deep into this and I've found the reason behind this.

The solution can be found in this spec.
I suggest you to read it, but to be synthetic the min-width by default is auto, and with that value Flexbox set the min-width as the minimum content size, thus when the container is not going to shrink that child more than that width. Infact the solution is setting a min-width, can be also different than 0, try experimenting in my codepen above.

I tested this in Chrome, Firefox, Edge and Opera. I don't have a safari to test it out but I'm pretty sure it will work, let me know if you can try that out too.

1 thing to know when using js default function parameters, 'arguments' keyword behaviour

Alberto De Agostini — Tue, 28 Jan 2020 11:48:13 +0000

Some days ago at work I encountered an unexpected (unexpected for me at least) behaviour when using the default function parameters. I'm going to explain what and I hope this will help some folks out there.

Default function parameters

You can skip to the next chapter if you already know well default function parameters added with es6 javascript.

For those who are not 100% familiar with this functionality, it was introduced with es6 features and it allow you to give a default value to function parameters like a normal human being would do. Let's see some examples:

Pre es6:

var fun = function(param1, param2) {
  param1 = typeof param1 !== "undefined" ? param1 : 1;
  param2 = typeof param2 !== "undefined" ? param2 : 2;
  // the two previous line was one of the many ways we were setting a default value

  // ... do function stuff ...
}

With es6:

var fun = function(param1 = 1, param2 = 2) {
  // ... do function stuff ...
}

MUCH MUCH better right?

Yep, I agree. I would strongly suggest you to start using this if you are not already.
You can read more in the official MDN documentation, also keep in mind that if you want to support old browsers (ie11 for example) you will need to transpile your code, using something like Babel. I won't dive deeper into this because we could write a book about it and there are many many great articles out there about this.

Interaction between arguments and default parameters

This is where the behaviour I wasn't expecting hit me like a fist in the face.
Let's take this code:

const fun = function(p1 = 1, p2 = 2, p3 = 3) {
  console.log(arguments.length);
}
fun(1);

What do you think the snippet will log in console?
a) 0
b) 1
c) 2
d) 3
e) undefined

If you guessed d you answered like I did the first time, thus you were wrong.
The correct answer is b.
This is because arguments always contains the actual provided parameters, ignoring the defaults.
Infact we can see that arguments ignore also the function definition:

const fun = function(p1, p2, p3) {
  console.log(arguments.length); // this will log 5
}
fun(1, 2, 3, 4, 5);

So be careful when using arguments keyword combined with default parameters.

I hope this was helpful, feel free to contact me on twitter

How to implement only css responsive elements with a certain aspect ratio

Alberto De Agostini — Wed, 15 Jan 2020 20:57:41 +0000

If you just want the solution skip to the bottom of the article.

Why this tutorial

Some time ago I was developing a webapp when the design team manager comes by and tell me that there was a piece of the application that needed to maintain a 16:9 aspect ratio and be responsive, no matter the content inside.
Immediately I said "ok mate, not a problem", but after a while I was like "wait, how do I do that?".
I asked some colleagues and surprisingly I've found that noone already knew how to do it without using Javascript (I always try to avoid using js if possible, especially if I have to add some listener to scroll or resize).

As any developer would do I started searching on Google and yes I've found some answers but I've also found a lot of people asking for it and a lot of questions were not actually working or were not ideal.

That's why I'm writing this tutorial now, I hope it will be the simplest tutorial to understand how to do it.

Code it

We are going to need just 2 div, no matter the aspect ratio we want.
Time is up, let's code it, I'll explain later what's going on:

<div class="square">
  <div class="content">
    This is a square content
  </div>
</div>

.square {
  border: 2px dotted red;
  width: 250px;
  position: relative;
}
.square:after {
  content: "";
  display: block;
  padding-top: 100%;
}
.content {
  position: absolute;
  width: 100%;
  height: 100%;
}

We create a div square and inside we create another div with class content (class names obviously are arbitrary, those are just semantic to better explain what's the elements purpose).
In the css we add a border on the square just to see it easily and we set a width (the width value can be any value, if you want it to be responsive it will probably going to be 100%) and set the position to relative.
We also add an after pseudoelement to the square and add content property to make it visible, display to block to behave like a block and a padding-top of 100%. This padding-top is THE trick. By adding this property we are saying: "my element (square) is 250px width and has a padding-top (that count for div dimensions) of 100%, so 250px. The resulting square element will be 250 x 250 px.
This is also where the previous position relative enter the game: if we don't set it to relative and the content element position to absolute the result will be that any content will make the square element to grow in height, thus losing the aspect ratio.
Now to create a 16:9 element or any other aspect ratio just change the padding top this way:

.square:after {
  content: "";
  display: block;
  padding-top: calc(100% / (16/9));
}

this way it will be a 16:9 element (square class would be inappropriate then :D).

Playground/demo

I've created a simple Codepen with some easy examples where you can play and try it out by your own including a responsive one with 100% width. check it out.

Vue component

If you are a Vue enthusiast developer like me I've also created a component to handle this easily, check it out here vue-aspect-ratio

Conclusion

For my research this is the best way to address this issue, let me know if you have any questions or tips by commenting or feel free to reach me on my twitter.