DEV Community: Iacovos Constantinou

How to import CSV Files with React

Iacovos Constantinou — Sat, 11 May 2024 06:48:43 +0000

In this article we are going to explore how we can use importOK to embed an import wizard into a React application. When we are done, we will be able to upload both CSV and Excel files, map the columns, review and fix any validation errors and finally submit the uploaded data to our API.

importOK is a reusable custom web component — you can control where it goes and how the mapping works. There are zero dependencies to any third party services and it can be hooked directly to your API.

Setup your fields

For the sake of simplicity, we will be importing a list of Contacts. Our app will be expecting four fields: first name last name email and phone.
First, we need to install the React component for importOK.
npm install @importok/react
Then to embed the import wizard, we can add the following into our page.

import ImportokWizard from '@importok/react';

function App() {
  /**
    * Import fields to be mapped
    * Check https://importok.io/docs/fields.html for more details
    */
  const fields = {
    first_name: {
      label: 'First Name'
    },
    last_name: {
      label: 'Last Name'
    },
    email: {
      label: 'Email'
    },
    phone: {
      label: 'Phone'
    }
  };

  return (
    <div className="App">
      <ImportokWizard
        title="importOK Example for React"
        fields={fields}
      />
    </div>
  );
}

The above also defines a list of fields which more or less describe our resource schema. Providing only the labels is sufficient and more than enough to get you started. Give it a go! At this stage you should be able to upload a CSV File and map the columns. Sweet eh?

Normalize and Cleanup your data

More often than not, the data provided by your end-users is not in perfect shape. Extra trailing spaces, incorrectly formatted phone numbers, and other frequent irregularities that take time and effort to resolve.

To improve this, we can use transformers to apply common fixes. The transformation happens right after the file is uploaded and before the validation. importOK provides a handfull of built-in transformers but if necessary you can also add your own.

Let’s extend our example to trim any spaces, and capitalize both first and last name.

import ImportokWizard from '@importok/react';

function App() {
  /**
    * Import fields to be mapped
    * Check https://importok.io/docs/fields.html for more details
    */
  const fields = {
    first_name: {
      label: 'First Name',
      transformers: 'trim|capitalize'
    },
    last_name: {
      label: 'Last Name',
      transformers: 'trim|capitalize'
    },
    email: {
      label: 'Email',
      transformers: 'trim'
    },
    phone: {
      label: 'Phone',
      transformers: 'trim'
    }
  };

  return (
    <div className="App">
      <ImportokWizard
        title="importOK Example for React"
        fields={fields}
      />
    </div>
  );
}

Validate your data

While transformers can help auto-heal your data, and bring consistency, they don’t cover all the cases. What if the email provided is invalid or the last name is blank?

Validators have been designed to address this problem and provide instead feedback to your end-users, so that they can fix these errors. Similar to transformers, there are some build-in validators and you can add your own as well.

Let’s improve further our example to make the last name required, and ensure that both email and phone are in the right format.

import ImportokWizard from '@importok/react';

function App() {
  /**
    * Import fields to be mapped
    * Check https://importok.io/docs/fields.html for more details
    */
  const fields = {
    first_name: {
      label: 'First Name',
      transformers: 'trim|capitalize'
    },
    last_name: {
      label: 'Last Name',
      transformers: 'trim|capitalize',
      validators: 'required'
    },
    email: {
      label: 'Email',
      transformers: 'trim'
      validators: 'email'
    },
    phone: {
      label: 'Phone',
      transformers: 'trim'
      validators: 'phone'
    }
  };

  return (
    <div className="App">
      <ImportokWizard
        title="importOK Example for React"
        fields={fields}
      />
    </div>
  );
}

Here is how it looks like at this point. Please note that you can filter by error type and that you can adjust your data without leaving the import wizard.

Push data to your API

There are a couple of options available to push the normalized and validated data to your API. You can either choose to send individuals records in parallel or send the full data set.

Let’s use the latter option for our example.

import ImportokWizard from '@importok/react';

function App() {
  /**
    * Import fields to be mapped
    * Check https://importok.io/docs/fields.html for more details
    */
  const fields = {
    first_name: {
      label: 'First Name',
      transformers: 'trim|capitalize'
    },
    last_name: {
      label: 'Last Name',
      transformers: 'trim|capitalize',
      validators: 'required'
    },
    email: {
      label: 'Email',
      transformers: 'trim'
      validators: 'email'
    },
    phone: {
      label: 'Phone',
      transformers: 'trim'
      validators: 'phone'
    }
  };

  /**
    * Push the normalized and validated records to the API
    * Check https://importok.io/docs/webhooks.html for more details
    */
  const importRecords = async function (records, meta) {
    return await fetch('https://your-api.com', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json'
        },
        body: JSON.stringify(records)
      });
  };

  return (
    <div className="App">
      <ImportokWizard
        title="importOK Example for React"
        fields={fields}
        onImportReady={importRecords}
      />
    </div>
  );
}

Add a CSV importer in your React app

importOK can be used to import data into your application, by embedding a powerful import wizard and leverage your existing API.

As a guideline, first you need to define the fields, so that your end users can map their data. Then you will need to define some transformers to normalize and clear the data to be imported. Next, you will need to define some validation rules so that you users can get instant feedback when something is wrong. Last, but not least, you will need register your webhooks so that you can actually import the data into your backend system.

importOK is available as a trial so that you can give it try before purchasing the pro license. At the moment of writing, you can join early and benefit from a 67% discount, for early adopters.

Make sure to follow me on dev.to, Medium or Twitter to read more about importOK or visit the website for more details.

Create a WeTransfer clone with AWS S3 😎

Iacovos Constantinou — Sat, 12 Mar 2022 16:08:25 +0000

In this post we are looking at how we can create a clone of WeTransfer, so that we can upload and share our files with others.

To keep things simple, we are not looking to create the actual user interface. Instead, we are leveraging AWS S3 to upload and share our files via AWS CLI.

Create S3 Bucket

First, we need to create a new S3 Bucket. To avoid storing the files indefinitely or cleaning up the bucket manually, we can configure a new S3 Lifecycle to automatically cleanup files after 7 days.

Here is how you can do the above using AWS CLI. Make sure to provide a unique name for your S3 bucket.

aws s3api create-bucket \
    --bucket wetransfer-clone \
    --region us-east-1 \
    --create-bucket-configuration LocationConstraint=us-east-1
aws s3api put-bucket-lifecycle \
    --bucket wetransfer-clone \
    --lifecycle-configuration file://lifecycle.json

The configuration for S3 lifecycle (used in the above commands).

{
  "Rules": [
    {
      "ID": "Delete files after 7 days",
      "Prefix": "",
      "Status": "Enabled",
      "Expiration": {
        "Days": 7
      }
    }
  ]
}

Upload and share files

Next, we can upload our files and create pre-signed URLs for S3. This will allow to us to share the file without making it public.

It is a good idea to set the URL expiring before we actually delete the file. In the following example, we expire the URL in two days (172800 seconds).

If necessary, we can create a new pre-signed URL without re-uploading the file. As mentioned above, the file is automatically deleted in 7 days.

aws s3 cp your-large-file.zip s3://wetransfer-clone
aws s3 presign s3://wetransfer-clone/your-large-file.zip \
    --expires-in 172800

The last command will provide the URL that you can share.

Large files

Thanks to AWS CLI we don't need to worry about large files.

When running aws s3 cp, Amazon S3 automatically performs a multipart upload for large objects. In a multipart upload, a large file is split into multiple parts and uploaded separately to Amazon S3.

After all the parts are uploaded, AWS S3 combines the parts into a single file. A multipart upload can result in faster uploads and lower chances of failure with large files.

More details about S3 large file uploads

Conclusion

I hope you enjoyed the article and it's something that you can use in real life.

Make sure to follow me on dev.to, or Twitter to read more about web development and how you can automate more stuff!

Photo by Volodymyr Hryshchenko on Unsplash.

Automatically generate services and models for your API consumers 🪄

Iacovos Constantinou — Sun, 16 Jan 2022 13:43:29 +0000

If you have a look at my previous articles here at dev.to you would see that I enjoy automating the little things. Especially the boring, tedious stuff that can lead to errors.

In this article we will be looking on how you can generate code from the OpenAPI spec so that your application is always in sync with the API.

There are many reasons why you may want to do that, but the main one is that your backend and frontend will adhere to the same schema.

The article covers mainly frontend applications based on React, Vue or even Angular. However the concept is quite generic and it can be used in backend also regardless using PHP, NodeJS or something else.

There are a couple of option to achieve this. Before getting started make sure to have a valid OpenAPI spec on your hands.

OpenAPI Generator

The first and perhaps the most popular option is to use the OpenAPI generator.

OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)

Even the solution is based on Java, there is a package wrapper that you can use and install it via npm. Alternatively you can run it directly via docker.

There are many generators available so depending on your case you can choose to generate code for Typescript with Fetch, or Typescript with Axios or even plain vanilla javascript.

For each generator, there are different options available that you can use to adjust the generated code to your needs. For example, you can control things like the naming convention for enums and parameters, add a prefix and many more.

Here is how you can generate the code for a Typescript project with Axios, by using Docker:

docker run --rm \
    -v $PWD:/local openapitools/openapi-generator-cli generate \
    -i /api-specy.aml \
    -g typescript-axios \
    -o /output

React, Vue and Angular

OpenAPI Generator is a great tool. However, someone might find that it does not fit very well to the NodeJS ecosystem. All of a sudden you have a Java dependency that you need somehow to manage.

Apart from the OpenAPI generator, there are other solutions available via NPM. Such solutions are based on Javascript of course and they target a particular framework/library.

React, Vue & OpenAPI

This package can be used to consume the API directly without pre-generating the services. If necessary though, you can generate typescript type files (.d.ts) .

openapistack / openapi-client-axios

JavaScript client library for consuming OpenAPI-enabled APIs with axios

Angular & OpenAPI

This package generates an Angular module which includes services, configuration and the schema models. It's quite powerful and there are some handy options to adjust the generated code.

cyclosproject / ng-openapi-gen

An OpenAPI 3.0 codegen for Angular

Shall we commit the generated code?

While it's possible to commit the generated code, I usually avoid that. I prefer instead to commit only the OpenAPI spec file and then generate the necessary code right before the build.

This helps to ensure that the generated code is intact and it has not modified manually. It usually takes a few seconds even for quite large specs so time shouldn't be a problem.

To do that, you can modify npm run and npm build to always execute the code conversion before actually building the app.

If you would like to commit the code anyway, you could have Github action that runs, generates the code and then create a PR with all the changes made.

Conclusion

I hope you enjoyed the article and it's something that you can use to save you some time!

Make sure to follow me on dev.to, or Twitter to read more about web development and how you can automate more stuff!

Photo by Raimond Klavins on Unsplash.

Synchronize Postman collections with the API

Iacovos Constantinou — Mon, 10 Jan 2022 15:29:58 +0000

Working with Postman and APIs can be painful when you don't synchronize Postman collections automatically with the API.

A common approach to get started with Postman is to import the API schema. This works absolutely fine until the first update on the API spec happens.

While importing the updated API spec works, it creates a new Collection from scratch. Obviously this doesn't scale well.

Apart from creating a new Collection each time, any customisation done (tests, scripts, etc) are not transferred to the new Collection.

In this post we will be looking on how we can automate this and properly update the existing Collection, so that we don't loose our customisation and keep our Postman collections lean.

Manually synchronize Postman with API

The first option is to manually update the API Schema directly, without importing. This approach is ideal when we have the URL or the actual file for the updated spec.

I found that this feature in Postman, even quite powerful is well hidden and quite difficult to discover.

Here are the steps:

In the left sidebar, click on the APIs tab and then the API that you would like to update.
If you are seeing the same API multiple times, go through the list and find the right one by checking the associated collection under the Develop tab.
Click on the Define tab and paste the updated spec and hit Save
Then move to the Develop tab. Under the Documentation section hit 'Validate'. This will try to sync the API spec with the Collection.
In case there any issues like breaking changes you will need to review the issues (press Issues found). Once you do that, you will be redirected to your browser where the changes will be listed one by one.
You can choose which changes to apply and how to sync with Collection.

Link Postman with an existing repository

Another option is to link the API Spec with an existing repository. This is of course ideal when the API Spec is part of your code-base and you have already access to the right repository.

Here are the steps:

In the left sidebar, click on the APIs tab and then the API that you would like to update.
If you see the same API multiple times, go through the list and find the right one by checking the associated collection under the develop tab.
Click on the Define tab, hit "Connect Repository" and provide the necessary details. You will need to that once.
Every time there is an update, you will need to move to the Develop tab and hit "Validate" under the Documentation section. This will try to sync the API spec with the Collection.
In case there any issues like breaking changes you will need to review the issues (press Issues found). Once you do that, you will be redirected to your browser where the changes will be listed one by one.
You can choose which changes to apply and how to sync with Collection.

Conclusion

I hope you find this little trick useful and hopefully it will save you from some time from manual actions.

Have also a look on how you can automate authorization in Postman

Make sure to follow me on dev.to, or Twitter to read more about web development and other development topics.

Photo by Tim Mossholder on Unsplash.

Access and update local files, from your browser!

Iacovos Constantinou — Mon, 27 Dec 2021 13:57:40 +0000

Consider a web based image editor. You upload the photo, edit whatever is necessary and then download a copy of the modified image.

Wouldn't be better if we could simplify the process and directly update local files, like native apps?

In this post we will be examining how we can achieve this by using the File System Access API.

File System Access API

The File System Access API allows web apps to read or save changes directly to files and folders on the user's device.

In particular, here is what we can do:

Read a local file
Specify file types and a starting directory
Open a directory and enumerating its contents
Update the contents of a local file
Create a new file
Delete files and folders
Move files around

Note that this feature is not available to all browsers.

Markdown editor

To illustrate some of the FileSystem API features we will be building a Markdown editor to read and write Markdown files from/to the local disk.

Let's go!

Read local files

First let's see how we can read a local file. The following shows a file picker dialog box, and prompts the user to select any markdown file.

A file handle is returned which can be used to read the file contents. Also, we can use the same handle to update its contents later on.

let fileHandle = null;
const options = {
  types: [
    {
      description: 'Markdown Files',
      accept: {
        'text/markdown': ['.md'],
      },
    },
  ],
};

[fileHandle] = await window.showOpenFilePicker(options);

const file = await fileHandle.getFile();
const contents = await file.text();

Update local file

Now let's see how we can update a local file and overwrite its contents. The following uses the file handle returned while reading the file to update its contents.

const contents = '...';
const writable = await fileHandle.createWritable();
await writable.write(contents);
await writable.close();

Demo!

Glue the above code snippets with a Markdown editor and you should be able to load markdown from you local disk, make and persist changes.

Check out this Markdown editor, made using SimpleMDE.

For a better experience, click on the "Open in new Window".

Conclusion

Throughout this post we went through the basics of FileSystem API and examined how it can be used to access and manipulate our local files.

Make sure to follow me on Twitter or dev.to to read more about web development.

Improve collaboration across teams with VSCode

Iacovos Constantinou — Sat, 27 Nov 2021 11:18:41 +0000

VSCode is definitely one of the most popular code editors. In this post, we will be looking on how you can use VSCode to improve collaboration and consistency across team members.

The following can be applied to any project, regardless the language being used. The only assumption is that you are using VSCode, Git and maybe Docker.

EditorConfig

EditorConfig is not VSCode specific but helps maintaining consistent coding styles for multiple developers working on the same project across various editors and IDEs.

It is one of the easy wins but for some strange reason you will find this missing from many code repositories.

In short you can define various config styles like charset, end-of-line and indentation styles.

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset and indent style/size
[*.{js,json,php}]
charset = utf-8
indent_style = space
indent_size = 2

Check EditorConfig website and EditorConfig extension for more details.

Workspace recommended extensions

VSCode allows you to define a list of recommended extensions under .vscode/extensions.json. Then developers will be prompted automatically to install these extensions.

Keep in mind that this is only a recommendation and the extensions will be installed only if the developers accept.

I find this very useful across large teams but also for on-boarding new team members.

While you can go crazy and add almost any extension possible here, it's better to keep this to the absolute necessary extensions.

Check Workspace recommended extensions for more details.

Remote pair programming

VSCode Live Share is an excellent option for remote pair programming and collaboration in general. The process to setup it is fairly simple and straightforward.

Apart from installing the extension, you only need to press a button to share your workspace with other team members.

The remote party can view the same code as you, even if you haven't pushed your changes yet. However, this happens from their own setup - which means both parties can use completely different VSCode Themes and Extensions without a problem!

Check Collaborate with Live Share for more details.

Developer with Docker

Containerized development environments are really useful to establish consistency and on-boarding new developers to the team. However, learning Docker can be cumbersome for some people. VSCode builds on top of this concept and goes a few steps further.

In particular:

You can spin off a container (or a set of containers) without leaving VSCode.
You can define various settings like which terminal shell to use by default, commands to run after the container is created.
You can also define the extensions, like described in the first section.

All the above go into devcontainer.json which is basically a config file that determines how your dev container gets built and started.

Check Development inside a Container for more details.

Conclusion

Throughout this post we went through a few ways where VSCode can be used to improve collaboration and consistency across the team.

Make sure to follow me on dev.to, Medium or Twitter to read more about web development.

Create a PR to automatically fix code linting errors

Iacovos Constantinou — Thu, 18 Nov 2021 18:36:51 +0000

This Github workflow aims to automatically fix as many lint errors as possible.

In particular, it executes eslint with --fix argument, so that we report and fix lint errors. Note that not all lint errors can be fixed automatically.

If any errors were fixed by eslint, a new PR is created including the changes made. The base is always the current branch while the assignee is the PR author.

This allows the PR author to review the changes and if needed merge them into the initial PR.

On top of that, the PR is marked with the label autofix.

My Workflow

The repository can be found here.

On purpose there is a lint error in index.js and you can review the PR created here to fix this. .

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

softius / actions-auto-improve-code-style

Create a PR automatically to fix code linting errors.

actions-auto-improve-code-style

This GitHub workflow executes eslint with --fix argument, so that we can not only capture but also automatically fix as many as possible.

If any errors were fixed by eslint, a new PR is created including the changes made. The base is always the current branch while the assignee is the PR author.

This allows the PR author to review the changes and if needed merge them into into the initial PR.

View on GitHub

Additional Resources / Info

While this workflow uses eslint, the same approach can be used with phpcs/phpcbf and other linters.

To customize the workflow further, you can refer to this action.

Make sure to follow me on dev.to, Medium or Twitter to read more about PHP, Docker and other dev topics.

Photo by Ken Suarez on Unsplash

Deploy to AWS ECS with Github actions 🚀

Iacovos Constantinou — Thu, 11 Nov 2021 18:48:33 +0000

Consistency and automations are key to every project. In this article we will be looking on how we can automate deployments to AWS ECS.

It is a very simple solution which requires almost zero coding. Yet, it's quite powerful as it allows you to deploy automatically every time there is a change in your code.

We will be using Github actions to achieve that. In particular, we will cover the following steps:

Build and deploy a new docker image to ECR
Retrieve and update the task definition with the new image tag
Update the corresponding services and force redeployment

Get started

First, you will need to register your AWS credentials as Secrets in your Github project. Assuming that you create two new Secrets AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, you should be able to configure AWS in your Github action as per below:

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-2

The above registers AWS credentials so that they are available for the next action.

Deploy docker image to ECR

Next we need to build and deploy our image. Most likely, this will be a time consuming action, especially if you have a large number of third party dependencies.

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1
    - name: Build, tag, and push image to Amazon ECR
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        ECR_REPOSITORY: your-ecr-repot
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

There a couple of things that you will need to adjust here. First you will need to provide the repository to deploy to for env ECR_REPOSITORY.

Then you might need to change how the IMAGE_TAG should look like. By default it will include only the commit SHA. Personally, I prefer to include also the date the image was build.

Update ECS task definition and Deploy!

Once the image is build and pushed to ECR, it is time to update the task definition and specify the new image tag. Depending on your setup you may have one or more tasks for the same image tag. In that case, you will need to repeat these steps.

Ideally, you should have the the task definition as part of your code base. In the following examples, we are assuming that the file is called task-definition.json

In case you don't, you can retrieve the task definition dynamically as per below. However, you might need to remove some parts of the definition, before pushing back to AWS - in that case jq is quite helpful.

    - name: Download task definition
      run: |
        aws ecs describe-task-definition --task-definition my-task-definition-family --query taskDefinition > task-definition.json

The following actions specify the new image tag in our task definition and force a deployment to our service. The last option wait-for-service-stability is important since it ensures that the service will reach a stable stage before proceeding further.

    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: task-definition.json
        container-name: my-container
        image: ${{ steps.build-image.outputs.image }}

    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: my-service
        cluster: my-cluster
        wait-for-service-stability: true

Similar to the previous actions there a few things that you will need to adjust here. Replace my-container, my-service and my-cluster with your setup details.

Conclusion

Having automated deployments to ECS is quite easy with Github actions. Yet, it's quite powerful as it allows you to deploy automatically every time there is a change in your code.

You can also use the same approach to deploy from any branch or even deploy manually, if needed.

Make sure to follow me on dev.to, Medium or Twitter to read more about PHP, Docker and other dev topics.

Photo by SpaceX on Unsplash

Automatic authorization in Postman 🔒

Iacovos Constantinou — Thu, 04 Nov 2021 18:04:47 +0000

Working with short lived JWTs can be painful when you don't have an automated mechanism in place to refresh the token. This is quite common when setting up a new collection in Postman.

In this post we will be looking on how we can automate this, so that we retrieve, refresh and use the token right before each API call.

Environment configuration

Before we get started, we need to define a few environment variables in Postman. These are:

baseUrl API URL
username The username to connect with
password The password for the above username

Unfortunately, there's no way to display the password as a ... password field. Postman will store and display everything in clear text, so have that in mind.

Pre-request script

Then, we need to edit the collection and configure the Pre-request script code. To do that, right click on the collection, select edit and then "Pre-request scripts"

Here is an example. As you can see the implementation is quite generic so most likely you will need to adjust a few things to make that work for you.

How it works

Initially we check whether we have a token stored. If not we go ahead and retrieve a new one along with expiration time.

We store both in environment variables. You don't need to create these variables, the script will create them whenever necessary.

If the token exists, we check also whether it has expired. In that case, we refresh the token and similarly to above we store the new token and its expiry date.

In either case, the token will be stored in a new environment variable called accessToken. This can be used to define the default authorization method. To do this right click on the collection, select edit, then Authorisation and use the variable {{accessToken}}.

Conclusion

I hope you find this approach useful and hopefully it will save you from some time from manual actions.

Make sure to follow me on dev.to, Medium or Twitter to read more about PHP, Docker and other dev topics.

Faster Docker builds with composer install ⚡

Iacovos Constantinou — Thu, 28 Oct 2021 08:17:11 +0000

When working with PHP projects and Docker, it is a good practice to include all the third party dependencies coming from composer install.

This really helps to reduce the time needed to spin off a new container. However, when not done right, it can significantly increase the build time.

Throughout this post we will see how we can avoid this and optimize composer install for docker builds.

Consider the following simple example, where we copy our source code before executing composer install

WORKDIR /my-cool-app
COPY . ./
RUN composer install --no-dev --no-interaction --optimize-autoloader

While this works, there is a major flaw; we don't leverage Docker cache. Every time there is a change in our source code, the docker cache for composer install will be invalidated.

In real life, this will happen with almost every build, causing composer install to be executed even when there are no changes in our dependencies.

Not efficient, that's for sure. But how can we avoid this? Consider the following example:

WORKDIR /my-cool-app
COPY composer.json ./
COPY composer.lock ./
RUN composer install --no-dev --no-interaction --no-autoloader --no-scripts
COPY . ./
RUN composer dump-autoload --optimize

Here, we are copying only composer.json and composer.lock (instead of copying the entire source) right before doing composer install. This is enough to take advantage of docker cache and composer install will be executed only when composer.json or composer.lock have indeed changed!

One downside is that we have to skip autoload generation and script execution since the source code is not available yet. Easy fix though. This can be done as the last step and it shouldn't affect the performance anyway.

As part of this post we saw how we can re-structure our Dockerfile for PHP projects and take better advantage of Docker cache. I hope that's helpful for your project!

Make sure to follow me on dev.to, Medium or Twitter to read more about PHP, Docker and other dev topics.

Photo by CHUTTERSNAP on Unsplash

Why we chose Tailwind CSS

Iacovos Constantinou — Thu, 21 Oct 2021 15:55:04 +0000

This is the second part of a three posts series that discuss our switch from Bootstrap to Tailwind CSS.

This post in particular reflects on what problems Tailwind has solved for us. Throughout the first post, a little story was provided as background to our project.

Naming is hard

We all know that there are only two hard things in Computer Science: cache invalidation and naming things. Naming is especially hard in CSS.

You start with a narrow scope class name i.e. .page-header only then to realize that you can use the same CSS properties for .panel-title. You start with a wide scope class name and after a while you start thinking that you need to narrow down the scope or combine it with other utility classes.

There are of course solutions to this problem like BEM, a naming convention standard for CSS class names. I always found BEM a bit too verbose for my taste.

Tailwind takes the naming away in most of the cases, especially when you combine it with a component based solution.

Let's say you are building a new card component and you want to style the card header. You could introduce a new class i.e. .card__header, then define the CSS properties and maybe do same for the child components.

While the above works, the chances are that you are not going to use the same class anywhere else. With tailwind approach you will be ending doing something like <div class="text-xl text-gray-500 mx-5"> and you are done.

Looking back, this reason alone might was enough to reconsider Tailwind CSS.

Code reviews

One of the problems when reviewing front-end code is how the code spans across different locations. For example, a new class is added to a particular element and then you have to check how the corresponding class was defined in another place.

This over-complicates reviewing. Especially when there are changes on existing styles and you are not sure how this could affect the entire application.

Code review is much easier to go through, when using utility classes along with HTML in one place. You can tell from the classes used what has been changed, without moving to the CSS. Also, you don't have to worry that the change had a negative affect somewhere else.

The above benefit was not initially clear. It slowly became obvious as we proceeded with the implementation and adoption of Tailwind CSS.

Built for components

Tailwind CSS is ideal when working with any component based library or framework like Angular and Vue. It helps you to improve how you approach re-usability.

Usually in such cases you have two ways to approach re-usability: via CSS classes and components.

Tailwind CSS, being a utility-first CSS framework, gives a great emphasis on re-usability via CSS classes. The scope of each CSS class is very narrow, which means that it can be re-used very easily. So this part of re-usability is pretty much well covered.

With the above in mind, the mindset is shifted towards component based re-usability. So instead of creating new classes that can be shared across components, we started thinking more about how we could solve this by introducing a new component.

Less rules to follow and one less layer of abstraction.

Conclusion

Throughout this post I analyzed the main three reasons why we eventually went with Tailwind CSS. There are other reasons of course, but these are the main ones.

As part of the next and final post of this series, we will be looking at some challenges and myths around Taiwlind CSS.

Make sure to follow me on dev.to, Medium or Twitter to read more about Angular, Tailwind and other dev topics.

Photo by Ross Findon on Unsplash

Tailwind CSS - A year in review

Iacovos Constantinou — Thu, 14 Oct 2021 18:08:35 +0000

A year ago we made our switch from Bootstrap to Tailwind CSS.

There is a large number of opinionated posts and tweets around this topic. This post series is a reflection on what problems Tailwind has solved for us, what challenges created and how our opinion has shaped after one year of usage.

This is the first part of a three posts series.

Some background

I have been following Tailwind CSS since its early days. I had the chance to try it in some small projects, mostly to experiment with the framework; but never got the chance to try it out in the battle field, until last year.

A new project was around the corner. The team had strong experience with Bootstrap 5, VueJS and Angular. We went with Angular and decided to give Tailwind CSS a try.

The idea was to experiment while building the application layout and a few screens. This should be sufficient to give us an idea what it was like working with Tailwind CSS. The plan was to spend two weeks to do the above and then reflect.

Initial reaction

The initial reaction was negative, like very negative. Here are a few comments that were brought up during the review.

How is this different from inline styles?
How can someone remember all these classes?
Our templates are getting huge!

It was clear that no-one got excited. We briefly discussed that most likely it is another framework hype and decided to re-start using Bootstrap.

At this point the team had to re-create everything using Bootstrap for the next two weeks. And then something unexpected happened!

The unexpected

At the next scheduled demo (end of the first week), team started showcasing progress on some new screens. "Oh, you already re-did everything in Bootstrap?", I asked only to found out that this process didn't even last a few days.

So what happened behind the scenes? While switching to Bootstrap, some of the strong points of Tailwind started to shine. Hence, it felt more natural for the team to continue exploring Tailwind further.

Conclusion

Over the next posts, we will be analyzing why we eventually sticked with Tailwind and what challenges we faced along the way.

Make sure to follow me on dev.to, Medium or Twitter to read more about Angular, Tailwind and other dev topics.

Photo by Danielle MacInnes on Unsplash