Proxy components

Jonathan — Sat, 23 Jan 2021 09:58:54 +0000

Refactorability is.. not a word, but it should be, it should be defined as

To which degree or factor a piece of code or application is able to be changed with minimal impact on the code/application as a whole.

Refactorability and maintainability are closely related but separate concepts in my mind.
maintainable code is something that can you write and make an effort to keep maintainable, and of course all of us should strive to write
maintainable code, but what is refactorable code ?

Well, I don't think there is one answer to this, i found myself thinking about this on a recent project i was working on.
If we take the above made up definition, refactorable code should make it easy to change without having much of an impact on other code using that code,

I was working on a legacy application, well it was using 6 month old packages witch is legacy in the frontend world..
having old packages is not a problem in it self, but the application that was basically a large dynamic form, and it had grown so much since its first inception
that we where experiencing some problems with sluggish inputs due to using the otherwise excellent formik library.
So, I decided to try out the react-final-form library, that has more fine grained control to optimize rendering.
after some initial testing, it looked promising, so when i decided to replace formik I had import { Field } from 'formik' sprinkled throughout the various components..

sigh

but I'll just do a quick search & replace for

import { Field } from 'formik' -> import { Field } from 'react-final-form'

and everything should be fine right ?

well no so fast, The Field from formik does not have exactly the same props as the one from react-final-form
so for each place where i used Field i need to change it so the props are the ones that the Field component from react-final-form expects.

I decided that it would be nice to have a local components/Field component, where i transform the props into the appropriate shape for the react-final-form Field

import { Field as FinalFormField } from "react-final-form"
export default function Field(props) {
  //... tranform the props
  return <FinalFormField {...transformedProps} />
}

and I lived happily ever after... almost, at the last moment we decided to update the version of our internal component library, where a breaking change to the Input component, made it so that
everywhere where we had imported it like

import FormInput from "componentlib/lib/FormInput"

i now had to do a

import { FormInput } from "componentlib"

hey this looks familiar, an "third party" component/library, needed to be changed, I know what to do..

I create a component/FormInput component which I use the application, I can then transform the props if the new version of the component requires it, all in one place.

import { FormInput as XFormInput } from "componentlibX"
export default function FormInput(props) {
  //... tranform the props
  return <XFormInput {...transformedProps} />
}

this repeated a couple of more times and it got me thinking, could this be a good pattern ?

The Pattern

For each component imported from a external library, create a local proxy component, so that if changes to the external library needs to be adapted
you can do it in one place

In any non trivial application you will always need to use third-party components. but when writing your actual component structure do we need to care that we are using Input from material-ui or from uilibX ?
I think there is a point to always importing all components from components/*, so if you have an Input from material-ui you should create a Proxy component that you then use in you app.

PROs

abstracts the third party library, so that you can make changes or update the underlying lib in one place.
from the applications point of view you only ever import from local components, which makes it less tied to any specific library, if you want to change the Input component to a custom input you make the change in the local component, and not in 100 places throughout the codebase.

CONs

There is some overhead in every time you want to use a third party component, you have to create a corresponding component in your app, which can feel a bit redundant.
Hiding what library that is used is not always wanted, although once inside of the Input component it will be clear where it is imported from.

What makes code refactorable ?

The ease to change the underlying implementation without impacting all of the components using it, or at least being able to make changes in a controlled way.
with the above pattern we can update the underlying library or change it outright, and make temporary transformations to the props so that we can take our time and update the where it is used in a more controlled way.

Closing thoughts

This is nothing new, we are used to creating more specific components that use third-party components in our application, like we might have a Login component that uses Auth0 and other helpers, this is just my thoughts of how I could make my applications more resilient to fundamental changes of libraries etc.

Building and serving gatsbyjs with docker

Jonathan — Sat, 23 Jan 2021 09:14:11 +0000

On a recent project I have been working on, I had to find a way to host a gatsbyjs project in a docker container.
After a quick search for gatsbyjs docker, most of the result pointed me to the fact that gatsbyjs have official docker images,
but when using it like shown in the README

FROM gatsbyjs/gatsby:onbuild as build

FROM gatsbyjs/gatsby
COPY --from=build /app/public /pub

I could not get it to work, after searching through the issues i found out that the docker images needs to be updated but its still open so i decided to take matters into my own hands.

Multistage docker builds

Docker has this awesome feature called multistage build which allows us to basicly structure our dockerfile
in a way to minimize the size of the final image. A traditional dockerfile would look something like this

FROM node:14.11.0
#
# Install and setup nginx to serve static files, removed for brevity.
#
WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

COPY . ./
RUN npm run build

RUN mv /app/public /usr/share/nginx/html

this would work, but you see that FROM node:14.11.0 line at the top of the Dockerfile, that means that the final image will have node included, and all the dependencies that the application needs to build.
there is a better way.

Enter multistage

FROM node:14.11.0 AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . ./
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/public /usr/share/nginx/html

As you can see it starts of similarly,we have one stage that uses the node:14.11.0 image, it sets everything up and builds the public folder with the generated gatsby site,
but at the end of the file we have a new FROM nginx:alpine and we then copy in only the public folder, This means that our final docker image will only contain our finished built site, and the bare minimun nginx to serve those files.

DEV Community: Jonathan