Forem: Alexis Moody

Sustainable string enums in Typescript

Alexis Moody — Tue, 18 May 2021 16:28:59 +0000

So you've got an enum type in your database table. The user needs to be able to set that property via a dropdown in your web application. But it's possible the table will require more enum types in the future. How do we write a dropdown that remains as flexible as the enum type itself?

Step 1: Define our database

For this example we'll use a Post as our database table.

CREATE TYPE post_status AS ENUM ('published', 'draft', 'review');

CREATE TABLE Posts (
  Id int,
  Title varchar(255),
  Status post_status
);

A post starts as a draft, then moves to a review stage, and is finally published. Authors/editors of this post can move the post through these steps at any time through our UI.

Step 2: Define our types

Let's start to map out our schema in the client side application.

// types.ts
export enum PostStatus = {
  PUBLISHED = 'published',
  DRAFT = 'draft',
  REVIEW = 'review',
}

export interface Post {
  id: number;
  title: string;
  status: PostStatus;
}

Step 3: Post management form

I'll skip typing out the full form. But let's assume you have a semantic form component that takes post information and allows the user to interact with it. The following would be the dropdown for changing the status:

<select>
  <option>Published</option>
  <option>Draft</option>
  <option>Review</option>        
</select>

This is fine for our first iteration but what are some ways to make this more maintainable going forward?

Option 1

Assuming all of the options have similar output we could do something like the following in react:

// index.tsx
const StatusDropdown = () => {
  const renderOption = (text: string) => {
    return <option key={text}>{text}</option>
  }

  const options: string[] = ['Published', 'Draft', 'Review']

  return (
    <select>{options.map(renderOption)}</select>
  )
}

export default StatusDropdown;

To add a new option we just add a new string to the options array. That's not bad, but we still have to update the PostStatus type whenever the data schema is adjusted, along with adjusting this component. Is there a way to update the PostStatus type and have that propagate to this dropdown?

Option 2

import { PostStatus } from './types';
import { capitalize } from 'lodash';

const StatusDropdown = () => {
  ...

  const options = Object.values(PostStatus).map(
    (value: string) => capitalize(value))

  ...
}

Now we've got a dropdown that is always in sync with the current definition of PostStatus. Our overall change surface area is reduced and future developers have an easier time making changes.

But why can we use the Object primitive and its functions? Well when an enum is evaluated at runtime it turns out to be an object! More details can be found here.

While typescript can be a bit of a learning curve at first, I hope techniques like this help you keep your applications up to date. And who knows, maybe one day enums will have a way to return all of the string value types without using the Object primitive. Only time will tell!

Javascript Closures: The Readability Magic Wand

Alexis Moody — Thu, 30 Jul 2020 17:59:34 +0000

Next up in this series on practical React strategies we are going to focus on one of the unsung heroes of the JS world, closures. Before we dive into the practical applications of closures in React lets define what a closure is!

Breaking Down Closures

The most straightforward definition of a closure is a function that returns a function. For example, you might want a function to multiply two values, one of which is static and the other could be dynamic. Let's take a look at what that means:

function multiplyValues(staticNum) {
  return function(dynamicNum) {
    return staticNum * dynamicNum
  }
}

// times2 is now the function that was returned in multiplyValues
const times2 = multiplyValues(2) 

console.log(times2(5)) // prints 10
console.log(times2(100)) // prints 200

So our closure function, multiplyValues, takes an argument for a static number that will always be used as the multiplier for the dynamic number passed to the inner function. The applications of this technique are numerous, but admittedly are less straightforward when we're thinking through our logic trees. The same result could be done without a closure like this:

const multiplyValues = (numA, numB) => {
  return numA * numB
}

console.log(multiplyValues(2, 5)) // prints 10
console.log(multiplyValues(2, 100)) // prints 200

The main difference is that we are repeating the pseudo-constant value of 2 to the generic multiplyValues function. If we know that we want to multiply by 2 in various sections of our code, it is easier understand that relationship by assigning the "static" value to a function variable and using that variable throughout the codebase.

Closures in React

Now that we have a solid understanding of what closures are in general let's talk about the ways we can use them in React.

Setting State

Local state management is integral to most React components. One way we can use state is to determine what kind of content is rendered. For example, let's say we have a component that renders 3 tabs, each with its own content. We've decided to set which tab is open in state and will render the appropriate content based on which tab is currently selected. The following is a non-closure version of handling the state for this component.

import React, { useState } from 'react'

const TabRenderer = () => {
  const [selectedTab, setSelectedTab] = useState('first')

  const handleFirst = () => setSelectedTab('first')
  const handleSecond = () => setSelectedTab('second')
  const handleThird = () => setSelectedTab('third')

  const renderTabContent = () => {
    switch(selectedTab) {
      case 'first':
        return <div>First</div>
      case 'second':
        return <div>Second</div>
      case 'third':
        return <div>Third</div>
      default:
        return <div>First</div>
    }
  }

  return (
    <div>
      <div>
        <button onClick={handleFirst}>First</button>
        <button onClick={handleSecond}>Second</button>
        <button onClick={handleThird}>Third</button>
      </div>
      <div>{renderTabContent()}</div>
    </div>
  )
}

This works and is fairly straightforward to read. But we're allocating 3 separate functions to set the same state. We could forego declaring these functions earlier in the code and just do it in each button like onClick={() => setSelectedTab('first')}. I'd argue you actually lose a bit of readability by declaring functions in the JSX and I generally advocate against that practice. Let's take a look at how could we refactor this with a closure.

const TabRenderer = () => {
  const handleClick = (newTab) => () => {
    setSelectedTab(newTab)
  }

  return (
    ...
    <div>
      <button onClick={handleClick('first')}>First</button>
      <button onClick={handleClick('second')}>Second</button>
      <button onClick={handleClick('third')}>Third</button>
    </div>
    ...
  )
}

By defining one function we've reduced the amount of memory being allocated by our application and set ourselves up to more easily change the internals of our click handler. This is by far the most common case for closures in React, although it is certainly not the only one.

Event Handling

Another complex piece of code in React is often form event handling. Generally we need to update the changed state of the object we are interacting with along with doing some sort of error validation or additional data parsing. Most of the time you can deal with this by accurately setting your name/value attributes on the input or select elements. But what happens when you need to map a user selected value to a dynamic value via a select element?

const OPTIONS = ['url', 'name']

const ComplexForm = (props) => {
  const { onChange, mappedData, dataStringArray } = props

  const handleChange = (userColumn) => (event) => {
    const mappedValue = event.target.value

    onChange({ ...originalData, [userColumn]: mappedValue })
  }

  const renderColumn = (userColumn) => {
    return (
      <div>
        <p>{columnName}</p>
        <select onChange={handleChange(userColumn)}>
          {OPTIONS.map((opt) => (
            <option value={opt}>{opt}</option>
          ))}
        </select>
      </div>
    )
  }

  return (
    <div>
      {dataStringArray.map(renderColumn)}
    </div>
  )
}

The user defined strings are completely dynamic but the goal is to relate them to a string that is expected by our backend. By using a closure we're able to dynamically associate the column/dropdown option pairs that will get mapped by the user.

Wrapping up

With our friend the closure we are able to more efficiently use memory in our applications and consolidate the surface area of potential changes. If you've used closures before, comment with some of your prior experiences. I'd love to keep the conversation going by sharing examples!

Advanced State Management With Dynamic Input Elements and Hooks

Alexis Moody — Sat, 27 Jun 2020 19:17:44 +0000

In this series we will be talking about the practical applications of common patterns in React. I've always found 'getting started' tutorials to be too abstract so I wanted to put together examples of problems I've solved in React.

Today we'll be talking about advanced state management through multiple input elements that are completely dynamic. And when I say dynamic I mean that we can't make an assumption on the availability of these inputs, and they can be adjusted at any time. We'll be using typescript in our components but the overall focus will be on the React patterns.

If you want to skip straight to the solution you can check it out here: https://codesandbox.io/s/dynamic-inputs-example-gsdbc

Mo Money, Mo Problems

Let's say we are tasked with creating a create/edit form for an account that can have multiple social media links attached to it. All of these links are optional and can be added/removed/updated at will. Our designer has come back with a design that may look something like this:

The blue plus button adds a new row of inputs and the red minus icon removes the input. There should always be at least one input available in the form and each input should be able to be updated at the same time.

Breakin' It Down

So let's take a moment to identify the functional components that make up this design.

A container that renders the inputs
The inputs themselves
The 'remove' button
The 'add' button

We can disregard the 'Social Media' label as it's just presentational and doesn't really effect the functionality of these inputs. We'll move through this tutorial one step at a time, starting with the container that renders all of the inputs.

One Container to Rule Them All

An important aspect of state management in React is understanding where state should be managed in the first place. Every component, especially now with hooks, can manage its own state. But the age old adage of just because you can do something, doesn't mean you should do something is important to remember. We know that the container will be the source of truth for how many inputs will be rendered, but should we be managing state there? Let's get started with the basics of this component:

import React, { ChangeEvent } from 'react';

interface MultiInputProps {
  values?: string[];
  onChange: (newValues: string[]) => void;
}

const MultiInputContainer = (props: MultiInputProps) => {
  const { values, onChange } = props;

  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    onChange([...values, e.target.value])
  }

  return (
    <div>
      {
        values.map((value) => {
          return (
            <input
              key={value}
              value={value} 
              placeholder="https://dev.to"
              onChange={handleChange}
            />
          )
        })
      }
    </div>
  )
}

So this looks alright. We have a container rendering multiple inputs based on values being passed to it. We just need to add a couple more buttons and we're done, right? Well, not so fast. There are a couple of problems with how this component works at the moment.

First in our handleChange function we are taking the current values, spreading them into a new array along with the inputted value, and passing that along to our onChange function prop. The issue there is that every new input by the user will be a new entry in the array. You'll end up with something like: ['www.first.com', 'w', 'ww', 'www', 'www.', ...]. Also, because we are directly rendering the values as inputs we will wind up with a new input for every letter that was entered by the user. That's not really what we want. So we need a way to identify which input is being updated. Enter our friends useState and useEffect! Let's take a look at improvements with these hooks.

import uniqueId from 'lodash/uniqueId'

type InputConfig = {
  value: string;
  id: string;
}

const emptyInput = (): InputConfig => ({
  id: uniqueId('input'),
  value: '',
})

const generateInputConfig = (values: string[]): InputConfig[] => {
  return values.map((value) => {
    return {
      id: uniqueId('input'),
      value
    }
  })
}

const MultiInputContainer = (props: MultiInputProps) => {
  const { values, onChange } = props;
  const [inputConfigs, setInputConfigs] = useState<InputConfig[]>()

  useEffect(() => {
    if (inputConfigs.length) return

    let initialInputs: InputConfig[]
    if (!values || !values.length) {
      initialInputs = [emptyInput()]
    } else {
      initialInputs = generateInputConfig(values)
    }

    setInputConfigs(initialInputs)    
  }, [values, inputConfigs])

  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    const { name, value } = e.target
    const newValues: string[] = []
    const newInputs = inputConfigs.map((input) => {
      newValues.push(input.value)
      if (input.id !== name) return input;

      return { ...input, value }
    })

    onChange([...newValues, value])
    setInputConfigs(newInputs)
  }

  return (
    <div>
      {
        inputConfigs.map((config) => {
          return (
            <input
              key={config.id}
              value={config.value}
              name={config.id} 
              placeholder="https://dev.to"
              onChange={handleChange}
            />
          )
        })
      }
    </div>
  )
}

Awesome! So by managing the state of input "configurations" with a custom type we can more reliably change the value of an input without effecting the state of the other inputs. We've added a few helper functions to generate these configurations, emptyInput and generateInputConfigs, but let's break down what is happening in each part of the component lifecycle.

First, when the component is rendered, the useEffect hook looks at all of the values that have been passed as a prop. If values don't exist or there are no strings in the array we generate a new emptyInput and set that as the input configs. Otherwise we look at all of the values and generate the initial inputs based on those values. We skip all of this logic if there are already inputConfigs set.

Second, when an input value is changed, the handleChange function only updates the value associated with the correct id while keeping everything in place by using map. If we just pushed the new config to an array the input could move spots on the screen. We also ensure the component that is using these inputs gets the updated values by calling the onChange prop. The placement of these values doesn't matter quite as much as they are not being directly rendered on the screen.

But why did we do this in the container component? Could we have accomplished the same thing by managing state in the Input component that we are about to implement? Sure, we could manage an html input's state within the Input component. But we would need to be able to add and remove the inputs so you still need to know the current unique ids within the container. So you would be increasing the surface area of state in this component structure and not really buying yourself gains in readability or performance. Going back to my initial point, just because you can do something doesn't mean you should.

We've now got a really solid structure for rendering multiple string inputs that can be updated. But what about adding or removing the inputs? Let's move on to the input component!

In-N-Out

Right now we just have an html input element, but we'll need to add a button to remove that input from the DOM. Let's move this input element and its 'remove' button to a new function component so we can separate our concerns a little better, and make it a littler easier to read in the long run.

import React, { ChangeEvent } from 'react'

interface InputProps {
  value: string;
  onChange: (value: string, id: string) => void;
  id: string;
  onRemove: (id: string) => void;
  placeholder?: string;
}

const Input = (props: InputProps) => {
  const { value, onChange, id, onRemove, placeholder } = props

  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    onChange(e.target.value, id)
  }

  const handleRemove = () => {
    onRemove(id)
  }

  return (
    <div>
      <input
        placeholder={placeholder}
        value={value} 
        onChange={handleChange} 
      />
      <button type="button" onClick={handleRemove}>
        Remove
      </button>
    </div>
  )
}

So this is pretty straight forward. We've just moved the input element to its own component that renders its own remove button and has a couple of handlers for input change and removal. The other change you'll notice is that we are no longer using name in the input element. That's mostly just a personal choice, you could use the id prop as name and look for that in the event target. I would just argue that by doing that you're duplicating information that is already available.

Now that we've split this component out what do we need to do with our MultiInputContainer? Let's take a look at those adjustments:

import Input from './Input'

const MultiInputContainer = (props: MultiInputProps) => {
  ...

  const handleRemove = (id: string) => {
    const filteredInputs = inputConfigs.filter((input) => (
      input.id !== id
    ))
    setInputConfigs(filteredInputs)
  }

  const renderInput = (input) => (
    <Input 
      key={input.id}
      value={input.value}
      id={input.id}
      onChange={handleChange}
      onRemove={handleRemove}
      placeholder="https://example.com"
    />
  )

  return (
    <div>
      {inputConfigs.map(renderInput)}
    </div>
  )
}

Great! In the handleRemove function we're taking the id of the input we want to remove and filtering the input config array to only include inputs that are not equal to the id passed to the function. This is a common technique for removing elements in an array, especially for arrays of objects like inputConfigs. You could also use splice to delete the element like this, but in my opinion it's a little too verbose for this use case:

const handleRemove = (id: string) => {
  const copiedArr = [...inputConfigs]
  const indexToRemove = copiedArr.findIndex((el) => el.id === id)
  copiedArr.splice(indexToRemove, 1)
  setInputConfigs(copiedArr)
}

We've got one last portion of this functionality to add...the add button!

Adding It All Together

The last piece of this puzzle is the ability to add a new input. Thankfully we've already done a big portion of the work when we implemented the emptyInput function earlier. Now we can place the button in the component and when it's clicked we append a new emptyInput to the array of inputConfigs.

const MultiInputContainer = (props: MultiInputProps) => {
  ...

  const handleAdd = () => {
    setInputConfigs([...inputConfigs, emptyInput()])
  }

  return (
    <div>
      {inputConfigs.map(renderInput)}
      <button onClick={handleAdd}>Add</button>
    </div>
  )
}

And that's it! We now have a system of inputs that can be added, removed, and edited in any form throughout your application. You can view the working component here. I'd love to hear your thoughts on these components. What if we had inputs that had slightly different rendering requirements, like addresses or types associated to an account? Could we make this structure a little more reusable? Let's discuss in the comments!

Replacing master with main in Github

Alexis Moody — Tue, 16 Jun 2020 14:55:48 +0000

As a black software engineer I have often felt uncomfortable with a variety of terms used throughout the industry. Terms like master/slave, blacklist/whitelist, and black hat/white hat enforce this country's belief that white is good and black is not. We can and should be better than this.

I am the product of slaves and sharecroppers from Louisiana/Tennessee so using the term master to define the default source of truth in my repos has always caused me pain. But I got used to it because it was such a pervasive term, and every time I brought up how hurtful it was to coworkers I was met with resistance. I refuse to do so any longer. Today, I have begun the process of moving to the use of main as my default branch in all of my owned repos. So i'm here to show you how to make a change that will take 3 minutes or less and make your teams more inclusive.

Step 1 - Update Local

While on the master branch input the following:

$ git branch -m master main
$ git push -u origin main

So what are we doing here? First with the -m command we are moving the git history from master to a new branch called main. Next we're pushing the main branch up to the origin remote, and establishing an upstream connection with the -u command.

Step 2 - Update Repo

Navigate to your repository > Settings > Branches
Select main as your default branch
Update your branch protection rules
Navigate to Code > Branches and delete master

That's literally it. I hope this guide helps you and your teams become more inclusive!

Clean Go Code (Part 1)

Alexis Moody — Wed, 11 Dec 2019 21:46:08 +0000

For most of my full stack career I've been a Ruby/JS dev working in Rails and React. But over the past 10 months I've dived head first into Golang due to my startup's acquisition. I've always been a big believer in human readable code that follows SOLID principles but I found the Go community tended towards short namespacing and single files with loosely coupled functions. To help improve my understanding of Golang I've decided to document some handy techniques I've learned that help keep your code easy to read and performant. These techniques are in no way one size fits all, but they have helped me in maintaining old and new microservices used by a 200+ engineering team. I hope you find value from this series as well!

SOLID Principles made easy

Dhurim Kelmendi ・ Nov 25 '17

#oop #solid #tutorials #bestpractices

Converting Data From One Type To Another

Imagine you are maintaining a social, long form text, posting platform. And let's say you're putting together an API that ingests a filter for a post's status.

Your SQL schema would look something like this:

CREATE TYPE posts.post_status_type AS ENUM (
    'DRAFT',
    'PUBLISHED',
    'UNDER_REVIEW'
);

CREATE TABLE posts.posts (
    id bigint NOT NULL,
    author_id bigint NOT NULL,
    title character varying(24) NOT NULL,
    content text,
    status posts.post_status_type NOT NULL   
);

Your database layer Go struct would look something like this:

package db

type DatabasePost struct {
    ID       *int64
    Title    *string
    Content  *string
    Status   *string
    AuthorID *int64    
}

type DatabasePostFilter struct {
    Title  *string
    Status []*string
}

func FetchAllPosts(
    ctx context.Context, 
    authorID string, 
    f *DatabasePostFilter,
) ([]*DatabasePost, error) {
   // Query the database by formatting SQL 
}

And your api layer structs would look like:

package api_models

type ApiPostStatus int32 
const (
    ApiPostStatusDraft       ApiPostStatus = 0
    ApiPostStatusPublished   ApiPostStatus = 1
    ApiPostStatusUnderReview ApiPostStatus = 2
)

type ApiPost struct {
    ID       *int64
    Title    *string
    Text     *string
    Status   *ApiPostStatus
    AuthorID *int64
}

type GetPostsRequest struct {
    AuthorID *int64
    Filter   *GetPostsRequestFilter
}

type GetPostsRequestFilter struct {
    Title  *string
    Status []*ApiPostStatus
}

You could have that filter be a single select, but for the sake of this example we'll make it a little more flexible by allowing multiple statuses at the same time. On the SQL side of this filter the single select would result in SQL like:

SELECT * FROM posts WHERE (posts.status = $1);

where the multiple status filter would look like:

SELECT * FROM posts WHERE (posts.status = $1 OR posts.status = $2);

Now that we have a firm understanding of our data let's take a stab at converting our API layer status into our database layer status in an API function.

package api

// import a database package that contains all of the functions related // to interacting with the database
import (
    "src/posts/db"
    "src/posts/api_models"
)

type PostsAPI struct {
    DB db.PostsDB
}

func (a *PostsAPI) GetPosts(
    ctx context.Context, 
    r GetPostsRequest,
) ([]*ApiPost, error) {    
    // Convert the ApiPostStatus type to a string type
    var dbStatusStrings []*string
    for _, s := range r.Filter.Status {
        if s == api_models.ApiPostStatusDraft {
            dbStatusStrings = append(dbStatusStrings, "DRAFT")
        }
        if s == api_models.ApiPostStatusPuplished {
            dbStatusStrings = append(dbStatusStrings, "PUBLISHED")
        }
        if s == api_models.ApiPostStatusUnderReview {
            dbStatusStrings = append(dbStatusStrings, "UNDER_REVIEW")
        }
    }

    // Add the converted type to the filter struct
    dbPostFilter := DatabasePostFilter{
        Title: &r.Filter.Title,
        Status: &dbStatusStrings,
    }

    // Make the db level fetch for all of the author's posts
    dbPosts, err := db.FetchAllPosts(r.AuthorID, dbPostFilter)
    if err != nil {
        return nil, err
    }

    // Convert db posts to api posts
    var posts []*ApiPost
    for _, dbPost := range dbPosts {
        apiPost := &api_models.ApiPost{
            ID: &dbPost.ID,
            Title: &dbPost.Title,
            Text: &dbPost.Text,
            AuthorID: &dbPost.AuthorID
        }
        if dbPost.Status == "DRAFT" {
            apiPost.Status = api_models.ApiPostStatusDraft
        }
        if dbPost.Status == "PUBLISHED" {
            apiPost.Status = api_models.ApiPostStatusPublished
        }
        if dbPost.Status == "UNDER_REVIEW" {
            apiPost.Status = api_models.ApiPostStatusUnderReview
        }

        posts = append(posts, apiPost)
    }

    return posts, nil
}

So that works. But you've got 6 if statements, and each one bumps up your cyclomatic complexity.

Article No Longer Available

Separate your concerns

What can we do to increase the readability of this function and decrease the cyclomatic complexity? Let's try separating the concerns by pulling these checks into small helper functions in a converter package.

package converters

import "src/posts/api_models"

func apiStatusToDBStatus(
    statuses []*api_models.ApiPostStatus
) []*string {
    var dbStatusStrings []*string
    for _, s := range r.Filter.Status {
        if s == api_models.ApiPostStatusDraft {
            dbStatusStrings = append(dbStatusStrings, "DRAFT")
        }
        if s == api_models.ApiPostStatusPuplished {
            dbStatusStrings = append(dbStatusStrings, "PUBLISHED")
        }
        if s == api_models.ApiPostStatusUnderReview {
            dbStatusStrings = append(dbStatusStrings, "UNDER_REVIEW")
        }
    }

    return dbStatusStrings
}

func dbStatusToApiStatus(status *string) *api_models.ApiPostStatus {
    if status == "DRAFT" {
        return api_models.ApiPostStatusDraft
    }
    if status == "PUBLISHED" {
        return api_models.ApiPostStatusPublished
    }
    if status == "UNDER_REVIEW" {
        return api_models.ApiPostStatusUnderReview
    }
}

Then our api function would look like:

package api

// import a database package that contains all of the functions related // to interacting with the database
import (
    ...
    "src/posts/converters"
)

func (a *PostsAPI) GetPosts(
    ctx context.Context, 
    r GetPostsRequest,
) ([]*ApiPost, error) {    
    dbStatusStrings := converters.apiStatusToDBStatus(r.Filter.Status)

    // Add the converted type to the filter struct

    // Make the db level fetch for all of the author's posts

    // Convert db posts to api posts
    for _, dbPost := range dbPosts {
        apiPost.Status = converters.dbStatusToApiStatus(dbPost.Status)
    }

    // return converted posts
}

You could probably also move the entire apiPost to dbPost conversion to a converter package function. But for the sake of this exercise we'll leave that alone.

Simplify the approach

This approach is fine and your cyclomatic complexity has definitely gone down. But you're still using a function that essentially maps one static value to another. To me the maintainability of this api would be significantly improved by creating a static map between the database enum strings and the api status type. By storing these values in a variable we reduce the memory we need to allocate for our application and make it easier to guard against bad data.

Let's take a look!

package converters

import ...

var ApiStatusMap map[api_models.ApiPostStatus]string := {
    api_models.ApiPostStatusDraft: "DRAFT",
    api_models.ApiPostStatusPublished: "PUBLISHED",
    api_models.ApiPostStatusUnderReview: "UNDER_REVIEW",
}

var DBStatusMap map[string]api_models.ApiPostStatus := {
    "DRAFT": api_models.ApiPostStatusDraft,
    "PUBLISHED": api_models.ApiPostStatusPublished,
    "UNDER_REVIEW": api_models.ApiPostStatusUnderReview,
}

func ApiStatusToDBStatus(
    statuses []*api_models.ApiPostStatus
) []*string {
    var dbStatusStrings []*string
    for _, s := range r.Filter.Status {
        if dbStatus, ok := ApiStatusMap[s]; ok {
            dbStatusStrings = append(dbStatusStrings, dbStatus)
        }
    }

    return dbStatusStrings
}

func DbStatusToApiStatus(status *string) *api_models.ApiPostStatus {
    return DBStatusMap[status]
}

By defining static conversion maps we reduce the complexity of our code while also improving the maintainability. If a new status type is added we can add 2 new lines to our maps instead of upwards of 6 lines to 2 different functions. In fact, we could probably remove the DbStatusToApiStatus function and use the DBStatusMap in our api function like:

    var posts []*ApiPost
    for _, dbPost := range dbPosts {
        apiPost := &api_models.ApiPost{
            ID: &dbPost.ID,
            Title: &dbPost.Title,
            Text: &dbPost.Text,
            AuthorID: &dbPost.AuthorID
        }
        if apiStatus, ok := converters.DBStatusMap[dbPost.Status]; ok {
            apiPost.Status = apiStatus
        }

        posts = append(posts, apiPost)
    }

I hope this technique helps you when converting custom types. Feedback is always welcome and be sure to look out for the next post in this series soon!