DEV Community: Boluwatife Fakorede

Composition in React

Boluwatife Fakorede — Sun, 18 Apr 2021 18:58:43 +0000

React implements a unidirectional pattern for data flow for building components. The pattern itself is not unique to react but followed strictly in react.

Unidirectional data flow means that data can only flow in one way alone.

Following the definition and if experienced with react, you would have noticed that the child component cannot pass data to the parent component; hence, data only flows in one way, “FROM the parent TO the child.”

If we need to modify the child that influences the parent or share state between two child components, we use props.

Let’s see a trivial example.

import React from "react";

import { Header } from "./components/header";

export default function App() {
  const [loggedIn, setLoggedIn] = React.useState(false);

  const handleSetLoggedIn = () => {
    setLoggedIn(!loggedIn);
  };

  return <Header loggedIn={loggedIn} handleSetLoggedIn={handleSetLoggedIn} />;
}

In the example above, we make some assumptions that the App function is responsible for handling login, and it passes the “loggedIn” state and the “handleSetLoggedIn” function to Header.

Let’s investigate the Header component and see how it makes use of these props.

import React from "react";
import { Profile } from "./profile";

function Header({ loggedIn, handleSetLoggedIn }) {
  return (
    <>
      <Profile loggedIn={loggedIn} handleSetLoggedIn={handleSetLoggedIn} />
    </>
  );
}

export { Header };

Above, we can see that the Header component doesn't make use of the props but passes them to the Profile component that makes use of them. This situation is known as props drilling.

Props drilling

Props drilling is passing props to a child component that doesn’t need the props but helps to pass it down to its own child component, which might pass it to its own child component because it doesn’t need it as well till it gets to the child that really needs the props.

The problem with props drilling is that things get messy, and debugging might become difficult quickly.

A good solution might be to reach out for the context API or Redux, but that is not needed to solve this problem.

We could use composition (component composition) to our advantage. In fact, the React team says:

If you only want to avoid passing some props through many levels, the component composition is often a simpler solution than context.
— React Team

What is composition?

Composition is the act of assembling components or elements to build a whole.

React gives a powerful tool that helps with composition, which is children-props.

We can easily refactor our Header component like this.

import React from "react";

function Header({children}) {
  return (
    <>
      {children}
    </>
  );
}

export { Header };

The children’s prop is available on every component. It contains the content between the opening and closing tags of a component.

Now, our Header component is a wrapper for the children we choose to render in it.

This gives us the power to refactor our App component render in “App.js.”

import React from "react";

import { Header } from "./components/header";
import { Profile } from "./components/profile";

export default function App() {
  const [loggedIn, setLoggedIn] = React.useState(false);

  const handleSetLoggedIn = () => {
    setLoggedIn(!loggedIn);
  };

  return (
    <Header>
      <Profile loggedIn={loggedIn} handleSetLoggedIn={handleSetLoggedIn} />
    </Header>
  );
}

We have solved the issue with props drilling by making use of composition.

This pattern also gives us the power to build more scalable reusable components, especially when building a tool, a library, or components used by a large number of people with varying needs.

The next article will build a card component and see how composition can be an exciting pattern to think about and use often.

Thank you for reading.

Testing API calls in React

Boluwatife Fakorede — Tue, 30 Mar 2021 08:45:25 +0000

You can get part one of this article here. It focuses on Mocking APIs for frontend developers.

In the words of Kent C. Dodds.

The more your tests resemble the way your software is used, the more confidence they can give you. — Kent C. Dodds.

While writing tests, it is best to focus on the use cases of our applications. This way, our tests mimic our users, and we are not focused on the implementation details.

Since we are testing for our application use cases, it is important to test for the interaction with data (Hence API requests).

Previously, to test API requests, we would probably have to mock “window.fetch” or “Axios,”, but our users won’t do that, would they? Hence there should be a better approach.

Mocking API requests with msw

Considering the limitations of mocking out fetch or Axios, it is bliss with a tool like msw, allowing the same mock definition for testing, development, and debugging.

msw intercepts the request on the network level; hence our application or test knows nothing about the mocking.

In the previous article, I demonstrated how to use msw to mock APIs. The good news is, we can use the same mocks for our tests!

Refactoring mock APIs

Let’s get started by refactoring our setup workers since we want to share our mock APIs (API handlers).


import {rest} from 'msw'
import * as todosDB from '../data/todo'

const apiUrl = 'https://todos'

interface TodoBody {
  body: todosDB.ITodo
}

interface TodoId {
  todoId: string
}

interface TodoUpdate extends TodoId {
  update: {
    todo?: string
    completed?: boolean
  }
}

const handlers = [
  rest.get<TodoId>(`${apiUrl}/todo`, async (req, res, ctx) => {
    const {todoId} = req.body
    const todo = await todosDB.read(todoId)
    if (!todo) {
      return res(
        ctx.status(404),
        ctx.json({status: 404, message: 'Todo not found'}),
      )
    }

    return res(ctx.json({todo}))
  }),

  rest.get(`${apiUrl}/todo/all`, async (req, res, ctx) => {
    const todos = await todosDB.readAll()
    return res(ctx.json(todos))
  }),

  rest.post<TodoBody>(`${apiUrl}/todo`, async (req, res, ctx) => {
    const {body} = req.body
    const newTodo = await todosDB.create(body)
    return res(ctx.json({...newTodo}))
  }),

  rest.put<TodoUpdate>(`${apiUrl}/todo/update`, async (req, res, ctx) => {
    const {todoId, update} = req.body
    const newTodo = await todosDB.update(todoId, update)
    return res(ctx.json({todo: newTodo}))
  }),

  rest.delete<TodoId>(`${apiUrl}/todo/delete`, async (req, res, ctx) => {
    const {todoId} = req.body
    const todos = await todosDB.deleteTodo(todoId)
    return res(ctx.json({todos: todos}))
  }),
]

export {handlers}

Now the handlers are alone in a new file, and we can share them between our dev-server and test-server. Let’s update the dev-server.

import {setupWorker} from 'msw'
import {handlers} from './handlers'

export const worker = setupWorker(...handlers)

Our dev-server is a lot shorter now, and everything still works, but we are not ready yet to writing tests; we need to set up a test server. Let’s do that.

Setup test server

import {setupServer} from 'msw/node'
import {handlers} from './handlers'

export const server = setupServer(...handlers)

If you notice, the test-server is different from the dev-server as the “setupServer” is gotten from “msw/node.”

It is good to note that you have to install “whatwg-fetch” as Node.js does not support fetch if you are using the fetch API. For our use-case, we bootstrap our application with create-react-app, which handles this automatically.

We would establish API mocking on the global level by modifying the setupTests.ts file (provided by create-react-app) as shown below.

import '@testing-library/jest-dom';
import { server } from './server/test-server';


// Establish API mocking before all tests.
beforeAll(() => server.listen())

// Reset any request handlers that we may add during the tests,
// so they don't affect other tests.
afterEach(() => server.resetHandlers())

// Clean up after the tests are finished.
afterAll(() => server.close())

NB: You can establish a global level for API mocking if you are not using create-react-app by following the docs.

Testing React API calls.

Let’s test our todos rendering and adding a new todo.


import {TodoPage} from '../todo.screen'
import * as todosDB from '../../data/todo'
import {fireEvent, render, screen, waitFor} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import {act} from 'react-dom/test-utils'

test('should renders all todos', async function () {
  const testTodos = await todosDB.readAll()
  render(<TodoPage />)
  const todosContent = await waitFor(() =>
    screen.getAllByTestId('todo-details').map(p => p.textContent),
  )
  const testTodoContent = testTodos.map(c => c.todo)
  expect(todosContent).toEqual(testTodoContent)
})

test('should add a new todo', async function () {
  render(<TodoPage />)
  const input = screen.getByLabelText(/add a todo/i)
  const form = screen.getByRole('form')
  userEvent.type(input, 'add todo')
  act(() => {
   fireEvent.submit(form)
  })

  const allTodos = await waitFor(() => screen.getAllByTestId('todo-details'))
  const newTodo = allTodos.find(p => p.textContent === 'add todo')

  expect(newTodo).toHaveTextContent('add todo')
  expect(allTodos.length).toBe(3)
})

In the above test, we don’t have to mock out “fetch” or “Axios.” We are testing exactly how our users will use the application, a real API request is made, and we get the mock response which is great and gives us much more confidence.

Thank you for reading.

DRY, WET, OR AHA?

Boluwatife Fakorede — Thu, 18 Mar 2021 06:19:02 +0000

Software engineering is an ever-evolving industry with various challenges faced by engineers or programmers. One of such is writing scalable and maintainable code.

One of the approaches taken towards a maintainable codebase is the abstraction and reusability of code to prevent duplications everywhere in our code. This is commonly referred to as DRY (DON'T REPEAT YOURSELF).

Let's consider an example:

This function is a simple one. It takes in an object and an array of keys, and if the object holds any of the keys, remove that object entry.

This function belongs closely to this use case and can be used anywhere in our codebase to filter objects. GREAT!.

What if we need to add another use case where the function needs to filter and return a new object where the obj key is present in the keys array? In the spirit of DRY, we might do something like this (sure can be improved, but you get the gist).

Hurray!!, our function is still DRY and reusable, but is it maintainable?

We have added another layer of complexity to a simple function; hence, it is not doing one thing well. You might say, but it is a simple "if-else statement." The reality is, it is not "a simple if-else statement."

Considering additional use cases still revolving around these functions, we start having conditionals everywhere, and we create a monster function that is a nightmare for everyone.

In the words of Sandi Metz;

Duplication is far cheaper than the wrong abstraction. - Sandi Metz

This leads us to WET (Write Everything Twice).

Considering the above example, the above function, even though they are similar, would be better off if written where they are needed hence removing the unnecessary abstraction and can be easily maintained.

And

This way, we have two functions that can easily be maintained and understood without adding extra complexity.

A good abstraction reveals a pattern without adding so much complexity.

As a Thumb rule for me, once an if statement is present in my abstraction, I "Write Everything Twice."

What about AHA? It simply stands for "Avoid Hasty Abstraction."

If we followed this simple term in the example above, we would have discovered quickly that we were hasty with our abstraction, which would have led to a monster function overtime.

Let's consider an example: (Credit to Kent C. Dodds)

Assuming we have this typical state used everywhere in our codebase or file. Considering we have two other functions that update the state to Pending and Success.

We have written these functions, and as I said above, a good abstraction reveals a pattern.

We could abstract the states returned and have this below:

We avoided any hasty abstraction and allowed the pattern to reveal itself in this use case.

Hopefully, the next time you are writing your reusable function, you would consider DRY, WET, or AHA?

Thanks for Reading.

Mocking APIs for frontend developers

Boluwatife Fakorede — Mon, 15 Mar 2021 13:56:22 +0000

Considering how loosely coupled web development is these days, leading to a separation of the frontend (mostly SPA) and backend(API driven) of our applications and often handled by different teams, one major thing to consider is the " blocked factor."

The blocked factor is how long a developer spends waiting on external API dependencies, hence preventing a feature development on the frontend or a project altogether.
Mocking is a way out of this blocked factor. They are easy to write, flexible, and stateless (hence testing scenarios repeatedly is easier) and ultimately provide a way out of external API dependencies.

Mocking allows us to simulate the backend API by specifying endpoints and the responses it gives.

The mocking framework

In this article, I would demonstrate how to use MSW (Mock Server Worker) to mock APIs for a todo react application.

Mock Service Worker is an API mocking library that uses Service Worker API to intercept actual requests. - mswjs.io

N.B: MSW is fully framework agnostic and also supports GraphQL. You should check it out!

Let's get started!

We need to install MSW.

$ npm install msw --save-dev
# or
$ yarn add msw --dev

Next would be to set up mocks. I do separate the API actions such as create, read, e.t.c from the mock servers themselves just for convenience.

Let’s do that.

[
  {
    "id": "BJSON65503",
    "todo": "Write a new article",
    "completed": false
  },
  {
    "id": "BJSON44322",
    "todo": "Work on side project",
    "completed": true
  }
]

A test sample of Todo Data. We could have used fakers also.

import todosData from './todoDB.json'

let todos: ITodo[] = [...todosData]

export interface ITodo {
  id: string
  todo: string
  completed: boolean
}

export interface TodoUpdate {
  todo?: string
  completed?: boolean
}

export interface TodoUpdate {
  todo?: string
  completed?: boolean
}

async function create(todo: ITodo): Promise<ITodo> {
  todos.push(todo)
  return todo
}

async function readAll(): Promise<ITodo[]> {
  return todos
}

async function read(todoId: string): Promise<ITodo | undefined> {
  return todos.find(todo => todo.id === todoId)
}

async function update(
  id: string,
  update: TodoUpdate,
): Promise<ITodo | undefined> {
  todos.forEach(todo => {
    if (todo.id === id) {
      return {...todo, update}
    }
  })
  return await read(id)
}

async function deleteTodo(todoId: string): Promise<ITodo[]> {
  return todos.filter(todo => todo.id !== todoId)
}

async function reset() {
  todos = [...todosData]
}

export {create, read, deleteTodo, reset, update, readAll}

API actions

We can create our mock now.

If you are familiar with the express framework of node.js, the way to write the REST API Mock with MSW is similar.

import {setupWorker, rest} from 'msw'
import * as todosDB from '../data/todo'

interface TodoBody {
  todo: todosDB.ITodo
}

interface TodoId {
  todoId: string
}

interface TodoUpdate extends TodoId {
  update: {
    todo?: string
    completed?: boolean
  }
}

const apiUrl = 'https:todos'

export const worker = setupWorker(
  rest.get<TodoId>(`${apiUrl}/todo`, async (req, res, ctx) => {
    const {todoId} = req.body
    const todo = await todosDB.read(todoId)
    if (!todo) {
      return res(
        ctx.status(404),
        ctx.json({status: 404, message: 'Book not found'}),
      )
    }

    return res(ctx.json({todo}))
  }),

  rest.get(`${apiUrl}/todo/all`, async (req, res, ctx) => {
    const todos = await todosDB.readAll()
    return res(ctx.json(todos))
  }),

  rest.post<TodoBody>(`${apiUrl}/todo`, async (req, res, ctx) => {
    const {todo} = req.body
    const newTodo = await todosDB.create(todo)
    return res(ctx.json({todo: newTodo}))
  }),

  rest.put<TodoUpdate>(`${apiUrl}/todo/update`, async (req, res, ctx) => {
    const {todoId, update} = req.body
    const newTodo = await todosDB.update(todoId, update)
    return res(ctx.json({todo: newTodo}))
  }),

  rest.delete<TodoId>(`${apiUrl}/todo/delete`, async (req, res, ctx) => {
    const {todoId} = req.body
    const todos = await todosDB.deleteTodo(todoId)
    return res(ctx.json({todos: todos}))
  }),
)

Server worker used for client-side mocking with all the rest endpoints

Above, we have defined all the REST APIs with their responses, and if you notice, our REST endpoints all point to an HTTPS server (the apiUrl prefix). This is because service workers are to be served over HTTPS and not HTTP (Always note that).
We could attach the response status, JSON, e.t.c, which is great and similar to how our APIs behave normally.

The setupWorker or the handler has not yet started; hence the Service worker API will intercept no request.

We will start the worker in a development mode because we don’t want to hit a mock in production or even staging.

Let’s do that

if (process.env.NODE_ENV === 'development') {
  const {worker} = require('./dev-server')
  console.log(worker)

  worker.start()
}

export {}

All we need to do is import the above file into the entry point of our application.

//index.ts

import './server'

Now, when we start our react application, we should see the following in the browser console.

Terrific!

If we make an API request to the “/todo/all” endpoint and look at the Network tab, we will see an actual request and the corresponding response served by the service worker API.

We will also get the todos from our todoDB.json as our response data.

This is great as we don’t have our backend ready and much more; we are not experiencing any blockage in our development process as frontend developers.

One of the major concerns regarding using mocks is maintenance, as the backend behavior might change rapidly, and we have to maintain the mocks. This is a valid point, but if we are to write tests (we will do in the second part of this article) for this APIs consumptions on the frontend, we would still need to maintain our mocks considering that our users won’t mock fetch or Axios hence our test shouldn’t as well, what if there is a way to share the handlers between the dev server and the test server hence maintaining just one handler and API actions.

We will explore the power of MSW much more in the next article.

Thank you for reading.

How I setup golang on docker and deploy it to Heroku

Boluwatife Fakorede — Mon, 06 Jan 2020 00:52:25 +0000

Hello dear reader,

This post came as a result of my recent pain point which was figuring out how to set up golang on docker and deploying the backend service to Heroku.

Sometimes last year, I came across golang and I have been playing with it ever since. I came from a Node.Js background and found the features of golang intriguing.

I have so far overcome certain obstacles such as structuring the project and now I am a big fan of domain-driven development.

Always in love with docker, it was my initial go-to for setting up my project since it gives me build in one place, run on any platform solution.

Firstly, how I set-up for development.


# Start from golang base image
FROM golang:alpine as builder

# Add Maintainer info
LABEL maintainer="Fakorede Boluwatife"

# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache git

# Set the current working directory inside the container 
WORKDIR /app

# Copy go mod and sum files 
COPY go.mod go.sum ./

# Download all dependencies. Dependencies will be cached if the go.mod and the go.sum files are not changed 
RUN go mod download 

# Copy the source from the current directory to the working Directory inside the container 
COPY . .

# Build the Go app
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main ./cmd

# Start a new stage from scratch
FROM alpine:latest
RUN apk --no-cache add ca-certificates

WORKDIR /root/

# Copy the Pre-built binary file from the previous stage.
COPY --from=builder /app/main .
COPY --from=builder /app/.env .
COPY --from=builder /app/templates ./templates
COPY --from=builder /app/pkg ./pkg
COPY --from=builder /app/migrations ./migrations
# COPY --from=builder /app/tls ./tls


# Expose port to the outside world
EXPOSE 4000

#Command to run the executable
CMD [ "./main" ]

The above code is my default Dockerfile.dev and it is a multi-stage build docker file and it is well commented to understand each step. I name it Dockerfile.dev simply because I need to use the Dockerfile itself for production with just a tiny change.

For the second stage of the build, you can easily remove (or comment out) the file you don't have in your initial working directory to prevent a build fail.

Now, I am also working with PostgreSQL and I needed a way to use it alongside my golang application in a docker container.

Docker-compose came to my rescue.

I would also love to set up automatic Migrations once I run my docker-Compose file.

My docker-compose file looked like this.

version: '3'
services:
  postgres_database:
    environment:
      - POSTGRES_USER=${DATABASE_USER}  
      - POSTGRES_PASSWORD=${DATABASE_PASSWORD}
      - POSTGRES_DB=${DATABASE_NAME}
      - DATABASE_HOST=${DATABASE_HOST}
    build: ./migrations/postgres
    ports:
      - 5432:5432
  app:
    container_name: test-app
    build:
      context: .
      dockerfile: Dockerfile.dev
    volumes:
      - api:/usr/src/app/
    ports:
      - "4000:4000"
    depends_on:
      - postgres_database

If you notice, my build for postgres_database service is using a Dockerfile in a migration folder.

Image below:

Okay, let me explain.

The folder also contains a tables folder that holds some SQL commands for each table.

The tables command are then included in a deploy_schemas.sql file.

Image below:

We are not done yet.

The Dockerfile (used by our docker-compose) actually holds certain command as shown below:

It simply gets the latest Postgres from docker hub, adds the table SQLs to docker-entrypoint-initdb.d/tables then adds the deploy_schemas.sql file to docker-entrypoint-initdb.d.

P.S:

The `docker-entrypoint-initdb.d` will only run the first time when it is not set, hence you have to run a docker-compose down command then `docker-compose up --b` to create the latest table migrations

Also, don't forget to set the proper environment variables alongside DATABASE_USER, DATABASE_PASSWORD, DATABASE_NAME and DATABASE_HOST.

After all that, simply run the docker-compose up --b and you are set for development.

Let's talk about the production deployment on Heroku:

I couldn't find a suitable way to copy the production environment variables for production usage and it became quite difficult for me to figure out how to do this.

On Heroku, I simply set the environment variables there, before deploying and I simply copied and paste my Dockerfile.dev into a new Dockerfile but removing the .env file to prevent the test or development environment variables from running in production.

This way, my Dockerfile looks like:


# Start from golang base image
FROM golang:alpine as builder

# Add Maintainer info
LABEL maintainer="Fakorede Boluwatife"

# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache git

# Set the current working directory inside the container 
WORKDIR /app

# Copy go mod and sum files 
COPY go.mod go.sum ./

# Download all dependencies. Dependencies will be cached if the go.mod and the go.sum files are not changed 
RUN go mod download 

# Copy the source from the current directory to the working Directory inside the container 
COPY . .

# Build the Go app
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main ./cmd

# Start a new stage from scratch
FROM alpine:latest
RUN apk --no-cache add ca-certificates

WORKDIR /root/

# Copy the Pre-built binary file from the previous stage.
COPY --from=builder /app/main .
COPY --from=builder /app/templates ./templates
COPY --from=builder /app/pkg ./pkg
COPY --from=builder /app/migrations ./migrations
# COPY --from=builder /app/tls ./tls


# Expose port to the outside world
EXPOSE 4000

#Command to run the executable
CMD [ "./main" ]

Exactly my Dockerfile.dev without the .env been copied on the second-build stage.

MAKE SURE YOU USE CMD instead of ENTRYPOINT to run the executable as this is mandatory for your application to run on Heroku (I just saved you hours of google search).

Also, make sure your port in main.go is using a ":" + $PORT. This is set automatically by Heroku and you need not worry about it. In your development environment though, don't forget to set the $PORT variable in your .env file.

You need to set up a project on Heroku (You can also use Heroku create to do this).

I didn't use docker to migrate my database on Heroku because, what if I bring down my application on Heroku, I am going to lose all the data in my database and that is way too risky.

Hence, my database is separate from my Dockerfile in production.

You must not forget to set up all the environment variables on Heroku including the database credentials (can be found on the add-ons section of your database then click on Heroku Postgres (if you are using it) and add then settings).

The beauty of Heroku with docker is the ease of deployment.

With 4 simple commands, your application is up and running in production.

At the directory of your application,


1. `Heroku login` (you need to login into the Heroku-cli) 

PS: If you don't have the heroku-cli installed, you need to install following:

`https://devcenter.heroku.com/articles/heroku-cli`

2. `heroku container:login` This allows you to login into the heroku container.

3. `heroku container:push web -a <name-of-your-heroku-project>`

On the success of step 3,

4. `heroku container:release web -a <name-of-your-heroku-project>`.

That is all!

Your project is running on Heroku perfectly.

Incase you experience any bug, run:

`heroku logs --tail -a <name-of-your-heroku-project>`

 This helps you to identify the issue and gives you the first step to debugging.

I know there are many ways to improve this process and I will write another article on the improvements. Your suggestions are welcome.

Thank you for reading.

How I write Media-Queries with Sass

Boluwatife Fakorede — Mon, 25 Nov 2019 16:40:34 +0000

Responsiveness is not a luxury but a necessity these days in web development. The percentage of usage of mobile devices is increasing largely making support for mobile devices a must.

It can be difficult to write media-queries especially when not using libraries like bootstrap, tailwind but required to write them from scratch.

Just like everything good in frontend development, it can be done in different ways with different pros and cons and media queries aren't left out.

We have basically two approaches that can be followed:

Mobile-first approach.
Desktop-first approach.

The mobile-first approach means we style the web application with mobile devices in mind that is our default style will be mobile-driven and no media queries are required to support mobile devices.

This might sound like the perfect way to build but it comes with certain cons like watered-down design which is not necessarily bad but might be over simple when you scale to desktop.

The desktop-first approach means the web application is styled with the desktop first in mind. This is a more traditional way to build and allows for more freedom in styling applications.

Either one you choose to use, like Jonas Schmedtmann said Always keep both the mobile and the desktop in mind.

In a mobile-first approach, we make use of min-width in defining our application media query as demonstrated below:

@media (min-width: 660px) {};

This means to apply this media query when the width is 660px or above.

In a desktop-first approach, we make use of max-width in defining our application media query as demonstrated below:

@media (max-width: 660px) {};

This means to apply this media query when the width is 660px or below.

In writing either of the above approaches, we can do so in different ways (I will use the desktop-first approach here):

A common approach will be to write your queries with the tags within it as demonstrated below:

html {
    font-size: 12px;
}

@media (max-width: 600px) {
    html {
        font-size : 10px;
    }
};

The issue with this approach is, you have one gigantic media-query with all the Html tags defined in it. Also, imagine you have two to three media-queries for different screen sizes and you have close to a thousand lines of CSS code requiring this media-queries, it is a very tedious process of copying everything into each media-query and things start getting messy and not well maintained quickly.

There must be a better approach.

I will be using sass from here and assume you have some knowledge with sass. (A quick read up should be sufficient).

In sass, I can simply define a mixin (a reusable block of code) for each of my desired media-queries and use them in the tag itself as demonstrated below:

@mixin mobileScreen {
    @media  (max-width: 600px) { @content };
}

@mixin tabletScreen {
    @media  (max-width: 900px) { @content };
}

The mixin is defined for the media-queries, and the @content passed into the media query definition to allow css syntax and value possible to be passed in when called as shown below:

html {
    font-size: 12px;

    @include mobileScreen {
        font-size: 10px;
    }

    @include tabletScreen {
        font-size: 11px;
    }

}

we simply use @include to include the mixin in the code.

Now we don't need to copy the codes everywhere and it is reusable but imagine there is a way a single mixin can handle all the breakpoints and all we should worry about are variable names?

Let's do that.

@mixin responsive($breakpoint) {
    @if $breakpoint == mobile {
        @media  (max-width: 600px) { @content };
    }

    @if $breakpoint == tablet {
        @media  (max-width: 900px) { @content };
    }
}

We are simply defining a function here and a media query is returned based on the breakpoint name we pass.

Let's make use of it.

html {
    font-size: 12px;

    @include responsive(mobile) {
        font-size: 10px;
    }

    @include responsive(tablet) {
        font-size: 11px;
    }
}

I prefer this approach and think it is much more readable. I declare my mixin once, I don't have to worry about it anymore and simply make use of it passing in a readable name. I will call it the preferred approach.

I would conclude by saying, I will recommend either the good approach or the preferred approach, both very similar but you know the one I prefer.

Thank you for reading.

How I validate user input in golang

Boluwatife Fakorede — Fri, 22 Nov 2019 22:11:59 +0000

Every application needs some way to validate the user inputs, this prevents the wrong kind of inputs been entered before ever reaching the database.

Coming from a Node.Js background for API service development, I always do some validation on the backend with JOI, I wanted something great to work with also in golang.

Using golang has a lot of advantages and I found been strongly typed one of the many useful features of golang.

The strongly typed built-in feature of golang already provided some sort of validation for the application, let's dive into some code.

Let's say you want to build an application, with the model defined below:

With the code above, the type of each field has been defined with some tags

In the route handler function, we will decode the request into the struct defined above.

Let us try to send a request but with a different type for the phoneNumber field (type int).

The response gotten is below:

This shows that there is some form of validation already in Go because it is strongly typed.

But there is so much we can do with this, some listed below:

What if the right type was entered or it was ignored totally and not sent?
What if I want to set a minimum amount of entry to be entered for maybe a password or a phone number not to exceed a particular length?

So I needed to find a way to validate each field and not re-invent the wheel.

I came across a validation package (https://godoc.org/gopkg.in/go-playground/validator.v9) amongst many out there and it is quite easy to use.

You add to the tags already defined as shown below:

That way, we have some constraints defined already for each field required been the minimum.

We need to do just a little bit more.

Import the validation package into our application.
Define a way for the errors to be returned.
Use it in our route handler function.
Test it!

Let's do that.

2.
I created a helper function that takes a type interface (actually just any type of struct) and returns a bool (true) and errors (a map of key string and value string holding the field that failed validation and the corresponding error fail) or it returns false and nil if it passed the validation as shown below:

PS: All just one code. You can find a very good explanation of the code above in the link below.

(https://stackedco.de/validating-rest-input-fields-using-golang-structs)

3.
Let's make use of our validator helper in our handler.

4.
Let's go for a ride with our code.

Notice we left out the phoneNumber field, the validator returned the field and the error.

Now we have a working validation process for our application.

Let's deal with another case.

I struggled with really, Imagine you have to embed another struct in your model struct and this can be required for many reasons one of them been you are performing a left join in your database query and need to return this new struct fields alongside the initial query, but you want to avoid validating this field since it is not required for the user to input the fields.

There is also a way to avoid this, all you have to do is in the embedded struct, add a validate with "-" as shown below:

This way, it is ignored when validating even if validations are required on the struct definition.

Thanks for reading!!

PS: This is my first post.