DEV Community: Fareez Ahamed

Datastructures in Go using Generics

Fareez Ahamed — Sun, 26 Feb 2023 12:05:33 +0000

I started a new series of videos explaining how to create Datastructures in Go using Generics. Go is a simple language that has low level features like pointers and yet simple due to its garbage collection and noise free syntax which is very similar to pseudocode. It makes the algorithms appear clear and concise.

These videos are in-detail live hands on videos where you get to see every line of code done to achieve the results. So these videos are a bit long but helps you to understand the process of coding it very well.

Check it out and share your feedback. If you want me to do any particular data-structure let me know. I'll do it

Stack

Queue

Goroutine-Safe Queue

Singly Linked List

useImperativeHandle: A New Perspective in Making React Components

Fareez Ahamed — Sat, 11 Jun 2022 07:36:08 +0000

useImperativeHandle hook is an unusual hook in React, to an extent that it is discouraged to use in the React's official documentation. React is a declarative framework and as the hook's name suggests, it is giving a break from React's declarative style by letting parent component call functions within the child component.

This is not something new to React, we have the useRef/createRef to access a DOM Elements API and call their functions. But in the case of a child component, you can't access functions within it and call them to make changes in it using useRef.

Let's look at some code.

const App = () => {
  const [isVisible, setVisible] = useState(false);

  const showDialog = () => setVisible(true);

  return (
    <>
      <button onClick={showDialog}>
        Show Dialog
      </button>
      <Dialog isVisible={isVisible}>
        Content within dialog
      </Dialog>
    </>
  )
}

This is the declarative way of implementing a dialog component. You have to pass visibility as a property to the component. This is the default way in which we all work.

Let's look at an alternative but imperative way.

const App = () => {
  const dialogRef = useRef();

  return (
    <>
      <button onClick={() => dialogRef.current.show()}>
        Show Dialog
      </button>
      <Dialog isVisible={isVisible}>
        Content within dialog
      </Dialog>
    </>
  )
}

Here we are accessing the component as if it's an object and call functions on it. State of the component is maitained within itself. We don't see such code often in React projects but it's certainly possible using useImperativeHandle.

Following is the implementation of such a Dialog component.

const Dialog = React.forwardRef((props, ref) => {

  const [visible, setVisible] = useState(false);

  useImperativeHandle(ref, () => {
    return {
      show() {
        setVisible(true);
      },
      hide() {
        setVisible(false);
      },
      toggle() {
        setVisible(v => !v);
      }
    }
  } );

  return (
    <div class="dialog-style">
      This is a dialog box
    </div>
  );
});

We have to use forwardRef to take the ref from parent and assign it to the object that is returned from the second argument of useImperativeHandle. That's it. Now we have exposed our component with a custom API to the parent component.

State of the dialog's visibility is kept within the component and this relieves us from defining the state everytime we have to use this component. But this doesn't mean we should use useImperativeHandle more often.

I chose Dialog component as an example, because showing dialogs is one of the cases which happen mostly on an event like button click. So imperative API may be easier to consume in this case. But React is designed as a declarative framework and popular packages like Redux maintain the state and the UI is just a representation of state maintained somewhere else. So for most cases, if you use imperative API, you have to use a lot of useEffects to trigger these imperative APIs which is not good.

There are some cases where it suits better. Whenever you want expose functions from more than one DOM Element to a parent component, you can go for useImperativeHandle.

Imagine that you build a credit card input component where you have four input boxes and at times first or last input has to be focussed. In such a case, useImperativeHandle is a good choice. Check out the code below.

const CreditCardInput = React.forwardRef((props, ref) => {

  const firstInputRef = useRef();
  const lastInputRef = useRef();

  useImperativeHandle(ref, () => {
    return {
      focusFirst() {
        firstInputRef.current.focus()
      },
      focusSecond() {
        secondInputRef.current.focus()
      },
    }
  });

  return (
    <div class="style">
      <input type="number" ref={firstRef} />
      <input type="number" />
      <input type="number" />
      <input type="number" ref={lasttRef} />
    </div>
  );
});

useImperativeHandle is a nice tool which has to be rarely and cautiously used. Otherwise you could easily end up inventing Angular in React. Think about the use case you have in hand before coming to a conclusion.

Testing React Components with API Calls (Video)

Fareez Ahamed — Sat, 15 Jan 2022 07:49:34 +0000

Testing React Components that is fetching data from external API is always a challenge. Luckily react-testing-library and Jest makes it super easy. In this video, I'm explaining the how to test a react component that accesses data from external API using Fetch.

A Recap on My Articles in 2021

Fareez Ahamed — Sat, 01 Jan 2022 07:16:20 +0000

In retrospect, I think it has been a good year for me on my blog (fareez.info). I was able to write more frequently than the previous years. Thanks to a full year of remote working which allowed me to spend some more time to focus on writing than usual. Also, I made the work flow a lot simpler with Hugo and Netlify, so I'm able to publish quicker.

I spent a lot of time experimenting with new tech which eventually lead to writing articles on multiple technologies such as Go, React, Svelte, Angular, Laravel, Javascript and C#. I'll share links of those articles below.

Go

Thread Safe Lazy Loading Using sync.Once in Go

Embedding a React Application in Go Binary

Why Interfaces in Go Are Not Explicitly Implemented

Svelte

Creating a Tree Component using Svelte.js

Why I'm Adding Svelte.js to My Toolkit

Angular

Setting Up Tailwind in Angular

Laravel

Authenticate Users from Multiple Tables in Laravel

C

Emulating Discriminated Unions in C# using Records

Javascript

Depth First Traversing using Generators in Javascript

There are still many topics pending in my todo list. I wish I get to write about them in the coming months. You can share your opinion on my articles. If you want me to write about something specifically, please feel free to suggest.

Photo by Wilhelm Gunkel on Unsplash

Understanding Memoization in Javascript

Fareez Ahamed — Sat, 30 Oct 2021 12:40:18 +0000

In this video, I'm explaining Memoization and how to create a memoized function with an example.

Emulating Discriminated Unions in C# using Records

Fareez Ahamed — Thu, 30 Sep 2021 09:49:15 +0000

Discriminated Union / Sum Type is one of the common features found amoung strong typed functional languages like F#, Haskell etc. Ever since I started using them in F#, I can't stop wondering why such an useful feature is not available on the popular languages. C# has been adding a lot of functional features over the last few years. So, we are going to achieve something close to that in C# using Records and Inheritance.

In F#, we can create a Discriminated Union for Shape as shown below.

type Shape = Circle of int
            | Square of int
            | Rectangle of int * int
            | Triangle of int * int * int
            | Line of int

Discriminated Unions alone cannot be beneficial without powerful Pattern Matching constructs built into the language. In the case of F#, calculating area for any shape is easy as writing a function with Pattern Matching.

let getArea s = 
    match s with
    | Circle(r) -> Math.PI * float(r) * float(r)
    | Square(x) -> float(x*x)
    | Rectangle(l, b) -> float(l*b)
    | Triangle(a, b, c) 
        when a = b && b = c 
            -> Math.Pow(float(a), 2.0) * Math.Sqrt(3.0)/4.0
    | Triangle(a, b, c) 
        when Math.Pow(float(c), 2.0) = 
            Math.Pow(float(a), 2.0) + Math.Pow(float(b), 2.0) 
            -> float(a * b) / 2.0
    | _ -> 0.0

Now lets see how we can express this in terms of Records in C#.

Records are introduced in C# 9.0 which are special classes with value equality
and simpler syntax. It takes a constructor with parameters and all the parameters mentioned in the constructor are automatically promoted into Properties with {init; get;}. Records are immutable and compared by values by default, just like any F# type. (However, there are some differences like deep equality is not guaranteed when reference types are used within Records which we are not going to give attention now.)

public record Shape{};
public record Circle(int Radius) : Shape;
public record Square(int Side) : Shape;
public record Rectangle(int Width, int Height) : Shape;
public record Triangle(int A, int B, int C) : Shape;
public record Line(int Length): Shape;

So here we create an empty Shape record which is being inherited by all the other shapes but with different set of parameters. Inheritance is the only relationship among these types which enables us to pass different shape objects like Circle or Square in the place of Shape. As I said earlier, Discriminated Unions are not useful on its own without Pattern Matching and C# has been adding good Pattern Matching support over last few versions. This allows us to compare type of the Record and evaluate an expression based on that.

So the getArea function would like the one below in C# 9.0.

static double Area(Shape s) =>
    s switch {
        Circle c => Math.PI * c.Radius * c.Radius,
        Square square => square.Side * square.Side,
        Rectangle r => r.Width * r.Height,
        Triangle t // Equilateral Triangle
            when Math.Pow(t.C,2) == 
                Math.Pow(t.A, 2) + Math.Pow(t.B, 2) 
                => t.A * t.B / 2,
        Triangle t // Right angled Triangle
            when t.A == t.B && t.B == t.C 
                => Math.Pow(t.A, 2) * (Math.Sqrt(3)/4),
        Line or _ => 0,
    };

It is pretty close to the F# version of the code. Honestly I didn't expect C# would catch up with such good Pattern Matching so soon. But it's not quite common yet to see C# code similar to this as it will take time for the developers to adopt to the new way of thinking to solving problems.

Project Showcase: React Native with Typescript, Mobx and TDD Using Jest

Fareez Ahamed — Sun, 05 Sep 2021 07:17:42 +0000

Sometime back I got to develop a small Android app using React Native. Since it was experimental, I went ahead giving a try with Mobx and developed the core logic in Test Driven approach using Jest.

I was fascinated how Mobx is really giving a clean code approach compared to Redux or Hooks based solutions. Its more Object-Oriented but gives us the ability to do Domain Driven Design.

Here in the video, I giving a tour of the entire codebase and my experience developing the project

React State Management without Third Party Libraries

Fareez Ahamed — Sat, 04 Sep 2021 10:09:15 +0000

React doesn't require any third party libraries like Redux for managing state. Context and Hooks can take you a long way. In this video, I'm explaining how to use Context and Hooks for State Management.

Setting Up Tailwind in Angular

Fareez Ahamed — Sat, 21 Aug 2021 06:50:53 +0000

Thanks to Angular team for making it so easy to integrate Tailwind with Angular 12 and above to a point that I really thought if I should write a post for it. Finally convinced myself to document it, since there were not many good references I could find related to this.

Lets first create a new Angular application. When new application is created, make sure you use CSS as the styling option.

ng new tailangular && cd tailangular

Now we have to add Tailwind as a dependency to our application

npm install --save-dev tailwindcss

Once you have it installed, its time to create the tailwind config file, so that Angular can pick it up when its building or running the application.

npx tailwindcss init

This will create the tailwind.config.js file with the following content.

module.exports = {
  purge: [],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
};

Now you can include the tailwind directives to the src/styles.css as shown
below

/* src/styles.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

That's it, now you can use Tailwind in your components. I don't think other frameworks have such easy integration as Angular. From Angular 12's release notes, it appears this is supported from Angular 11.2 but I tried it only with Angular 12.

Enjoy using Tailwind with Angular's template system!

Embedding a React Application in Go Binary

Fareez Ahamed — Fri, 13 Aug 2021 15:52:44 +0000

Go 1.16 has come out with a feature which I waited for quite some time. With Embed we will be able to add static files into the go binary at build time. It also makes accessing the files as simple as dealing with File System APIs.

This has opened up a whole new world on building and deploying web applications. Now we can embed static web apps along with the API server built in Go. In this article, we are going to explore how we can embed a React application in Go binary at build time.

First, let us create a React application using Create-React-App.

npx create-react-app react-app

Once the application is created, we will have the default App component which shows the React icon. We are not going to change it. We are just going to use it as it is and embed. So let's build the app, so that we can get the static files from the build folder.

npm run build

Create a folder in which we are going to code the Go application. Copy the build folder into the newly created folder.

/
|-build
| |- React build files here
|-main.go

package main

import (
    "embed"
    "fmt"
    "io/fs"
    "net/http"
)

//go:embed build
var embeddedFiles embed.FS

func main() {
    fmt.Println("Starting Server")
    http.Handle("/", http.FileServer(getFileSystem()))
    http.ListenAndServe(":9000", nil)
}

func getFileSystem() http.FileSystem {

    // Get the build subdirectory as the
    // root directory so that it can be passed
    // to the http.FileServer
    fsys, err := fs.Sub(embeddedFiles, "build")
    if err != nil {
        panic(err)
    }

    return http.FS(fsys)
}

Notice the directive go:embed build. The variable embeddedFiles will be initialized with a reference to the File System containing
the build folder as a subdirectory.

go build main.go

Now build the Go application, get the binary and run it wherever you want and go to http://localhost:9000, you will see the React appliation. It is a single binary containing all the static assets. Easy to deploy or distribute.

This open's up a lot of possibilities. We can embed multiple small frontend applications into a Go binary and they can work together. Everything that can be done on nginx can be very well done using Go while still having all assets packed together.

Why Interfaces in Go Are Not Explicitly Implemented

Fareez Ahamed — Mon, 09 Aug 2021 14:19:22 +0000

Languages that came after Java, had great influence of it irrespective of static-typed or dynamic---especially the Object-Oriented features. Interfaces, popularized by Java was taken straight into other languages like C# and even dynamically typed languages like PHP! But Go has questioned every existing solution thoroughly before inheriting those features. No while loops, no do-while loops, no ternary operators, no constructors, nothing was brought in Go just because it existed earlier.

Similarly, interfaces in Go were designed different from Java purposefully. It has one simple change---you don't explicitly 'implement' your interface. Which means, you will not explicitly mention that this class implements this interface when defining the class/type. When I read this initially, it looked like chaos. 'How will I know what (list of) interfaces my object implements?!', 'What if I get the parameters wrong while implementing?', 'And what about the shiny helping light bulb which will implement all the methods automatically for me with a NotImplementedException?'. It took a while for me to get convinced, that its actually helpful not to implement interfaces explicitly and opens new possibilities.

First, let's address our insecurity about compromises to type-safety due to not explicitly mentioning the intefaces when creating a type/class. Imagine you have a type and interface as shown below with a conflict in types of the parameter.

type DbLogger struct {}

func (db *DbLogger) Log(errNo string, msg string) {/*...*/}

type Logger interface {
    Log(errNo int, msg string)
}

If you notice, I have written the type definition first and the interface definition below to break our notions of types/classes being always dependent on intefaces. In Go, it doesn't. In Go, interface is a window through which you are trying to see/access an external object. You not having a window, doesn't make the external object not to exist --- it will be there.

In a language like Java, you would have got the compiler catch it by now with the following message.

Class 'DbLogger' must either be declared abstract or implement 
abstract method 'Log(int, String)' in 'Logger'

But Go waits till you actually use it. So lets use it in a function.

func DoSomething() {
    var logger Logger
    logger = &DbLogger{}
    logger.Log(234, "Message")
}

And now Go catches it as we are trying to assign the object to the interface. Following will be the error from compiler.

cannot use &(DbLogger literal) (value of type *DbLogger) as Logger 
value in assignment: wrong type for method 
Log (have func(errNo string, msg string), want func(errNo int, msg string))

This error message is even more clear and points out the actual issue compared to the one from Java. Credits to Go not having Method Overloading. Now we can rest assured that type safety is guaranteed with a proper message from the compiler.

Not having to explicitly implement an interface has an important purpose. Assume you are working with a third party package. To avoid tight coupling and to keep the code testable without depending on the third party package, you have to have an interface to communicate to the object from the third party library. You acheive this through a Repository/Service pattern in other languages. What if the third party object can comply with the interface that you create in your package? It means you don't have to write a wrapper service or repository.

But it is not possible in languages like Java or C# because your package provider can't explicitly implement all the interfaces that his clients wants. Making the interface work without implementing explicitly enables Go to create the interface at the consuming end and not the providers end.

Let's look at an example where you have a Store which takes care of some operations at the database.

package store

type User struct{ Name string }

type Store struct{}

func (s *Store) CreateUser(u User)      {}
func (s *Store) DeleteUser(u User)      {}
func (s *Store) UserExists(u User) bool { /* return value */ }
func (s *Store) UpdateUser(u User)      {}

We are going to have a function which takes a Store as a dependency and going to have signup logic.

package app

import "store"

func SignUp(s *store.Store, u User) bool {
    if !s.UserExists(u) {
        s.CreateUser(u)
        return true
    }
    return false
}

Let's swap store.Store with an interface.

type UserCreator interface {
    CreateUser(u User)
    UserExists(u User) bool
}

func SignUp(s UserCreator, u User) bool {
    if !s.UserExists(u) {
        s.CreateUser(u)
        return true
    }
    return false
}

Here UserCreator has a subset of the methods available in store.Store type. It simply means UserCreator can point to store.Store. you will be able to pass an object of type store.Store to the SignUp function.

You could argue that, we may not want to keep the signature of the method same as the third party package. Agreed. In that case, you can always make your own implementation. But in most cases, we just call a method or two from the package and just having an interface to imitate is perfect.

If you take a look at the standard library of Go, most of the interface definitions are small, carrying only a couple of methods. The best examples are from the io package. Reader, Writer, Closer, Seeker--- all of these have just one method and ReadWriter, ReadWriteCloser interfaces are made by composing the single method interfaces.

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type ReadWriter interface {
    Reader
    Writer
}

This is how Go's interfaces are meant to be used.

There could be concerns about naming a lot of small one time used interfaces. Certainly, naming is the most difficult problem in programming. We can address that with anonymous interface declarations.

func SignUp(s interface {
    CreateUser(u User)
    UserExists(u User) bool
}, u User) bool {
    if !s.UserExists(u) {
        s.CreateUser(u)
        return true
    }
    return false
}

As an effect of having smaller interfaces, testing this code becomes easier. We don't need complex mocking frameworks to create mocks for these simple interfaces.

type mock struct {
    userExistsVal bool
}

func (mock) CreateUser(u User)        {}
func (m mock) UserExists(u User) bool { return m.userExistsVal }

func TestSignupUserExists(t *testing.T) {
    result := SignUp(mock{true}, User{})
    if result == true {
        t.Error("Want: No user creation, Got: user creation")
    }
}

func TestSignupUserNotExists(t *testing.T) {
    result := SignUp(mock{false}, User{})
    if result == false {
        t.Error("Want: User creation, Got: No user creation")
    }
}

In the above code, we have created a very simple mock based on the interface and supplied to the function for testing it --- without any mocking libraries.

All of these benefits are powered by one simple change to the interface that Go brought in: Implicit Interface Implementation.

PS: Originally posted on my blog at https://www.fareez.info/blog/why-interfaces-in-go-are-not-explicitly-implemented/

Why I'm Adding Svelte.js to My Toolkit

Fareez Ahamed — Sat, 07 Aug 2021 15:44:38 +0000

For a long time, I was holding myself from trying out Svelte.js just for the reason that I don't want to wrap my head around one more framework after React, Angular & Vue. Last year, I broke my vow out of curiosity and started checking Svelte. But the fact that typescript support was not so good at that point of time stopped me from considering it seriously.

Few weeks back, I gave a second attempt. And now the typescript support is also really good and so I seriously gave some try by developing some of the complex components that I have developed earlier in React or other frameworks so that I'll really know whether it makes things easy or difficult. Until and unless
you try the same thing in two different frameworks it is hard to see the real benefits of a framework.

I'll explain what are the things that impressed me about Svelte.

JSX vs Templates

Having worked on template based frameworks like Angular and Vue for good amount of time, I really loved the flexibility JSX provides when I started with React. I thought I'll never want to go back to a template based framework until I worked with large team on React projects. It gets difficult when people stack nested
condidtion and nested loops on JSX. (And I don't even want to talk about nested ternary operators on JSX!) For people who suggest eslint as solution, It doesn't always work the way you expect it. When a critical deadline comes, eslint is the first thing that goes out of the window.

When I learnt the reason behind why Golang has dropped a lot of features including ternary operators for the greater benefit, it made sense. And I think Svelte is similar in spirit of Golang. Svelte comes with a minimal set of features and yet it contains all that we will need for making a web application.

JSX is flexible, but you need that much flexibility only 20% of times. We don't write a HOC or Render-Prop every other day. Remaining 80% of the time, you write only conditions and loops. Templates address that 80% very well. It's all trade-offs based on your requirement.

It's Compiled

When I read that Svelte is compiler and not a framework, I was taken aback. I thought it is not my thing. But what I realized slowly is, even JSX is compiled and its not Javascript. Everything is compiled in the frontend world. Babel, Typescript, Elm, Rescript... and the list is quite long. So what matters
is the convenience that the compiler gives us.

Svelte bakes reactivity into the application through the compiler. So it makes the application really fast. As the compiler gets better, your app gets better for free.

Real DOM

Svelte is dealing with the actual DOM, unlike React & Vue which uses Virtual DOM. This makes things simple and easy. It relieves you from a lot of mental overhead, when doing some CSS Animations or DOM manipulations. You can use any DOM libraries like popper.js directly without having to look for a wrapper like react-popper. It just feels like Svelte is just a better a HTML + JS + CSS, nothing more.

Fully loaded: Stores, Transitions and Animations

Svelte has a very good set of features out of the box with which you can go do most of the apps. It has builtin stores which works well with templates and $ reactivity.

When working with React, I haven't bothered much about transitions and animations because of the amount of effort involved. Most of the time you have to pull in an additional dependency. But with Svelte, it's as simple as adding a directive like the one below.

{#if condition}
    <div transition:slide>
        slides in and out
    </div>
{/if}

Downsides

Svelte doesn't have a default router unlike Vue or Angular. Svelte-Kit is pitched as the solution for this, which is still on beta and I think it will be Next.js equivalent for Svelte. But there are plenty of less popular third-party
routers available.

People are afraid of the smaller community and lesser packages. But Svelte has good enough default features to make webapps. Also, you can use any DOM libraries very easily without needing a wrapper package. So this is not a concern for me.

Svelte 3 released two years back and its still stable and moving forward without major changes. So it has more pluses than negatives. I'm planning to use Svelte more in the future.

PS: Originally posted on my blog at https://www.fareez.info/blog/why-am-adding-sveltejs-to-my-toolkit/