DEV Community: Victor Ocnarescu

The downfall of web development

Victor Ocnarescu — Sat, 04 Mar 2023 12:35:41 +0000

It has begun. The downfall of web development. I don't know how it started, but it seems unstoppable. Layer after layer of unnecessary complexity keeps being added to every part of web development. And it makes the life of modern developers a living hell.

To promote this new trend, I have prepared a list of features that you can add today into your project to make it even more complex.

I am assuming you have an idea for the app you want to build, you have a small agile team and you want to launch it as quickly as possible.

Let's start with the list:

1. Use Docker for everything

I don't care it could work without it

You will enjoy a relaxing delay every time your project starts.

Bonus: you will have to recreate the Docker image every time you install an NPM dependency

2. Use Strapi for labels and texts

I want to be able to change the labels once a year

You will enjoy adding keys to the list of every single one of your inputs and making the frontend code so much more complex (you will reference a key within an object, not just some text, that would be lame and unusable).

Bonus: you will have to keep another exact copy of your labels somewhere in your codebase in case the connection to Strapi fails.

3. Use many Git environments

Only one main branch? No way, let's add staging and dev

Setup a complex Git environment before your new app is live and enjoy the benefits of having multiple environments that have the same purpose.

Bonus: protect your branches so that no developer will be able to quickly fix bugs without going through the peer review process.

4. Use Typescript

I want to know and control EVERY type

You will enjoy looking smug at poor old Javascript and you will write at least 50% more code. More code means it will be easier to manage it in the future, does it not?

Bonus: your code will become much more readable, especially on the frontend, where you usually just want to style a div.

5. Use styled components

I don't want to use the most powerful CSS feature: classes

You will enjoy writing style after style without any reuse. It doesn't even matter that utility CSS frameworks like Tailwind exist, you want to write CSS-in-JS because it's trendy. Good for you!

Bonus: don't even think about CSS media queries. Instead use useMediaQuery hooks to do in React the exact thing you would do in CSS.

6. Use microservices to split your data

I am worried about scalability for my brand new app

You will enjoy splitting and duplicating your code in every microservice without any real benefit. Premature optimization is such a joy!

Bonus: it will also be harder to retrieve data from one microservice to another. You will probably need a private NPM package to tie everything together.

7. Do not use code formatters

It looks the same to me

You will enjoy having to review Git commits that change a single quote into a double quote, different new line formats and all of this valuable changes to your codebase.

Bonus: don't even look at code standards, inline those pesky one-line if statements

And there it is, the 7 deadly sins of modern web development that will consume your time, kill your creativity and make a simple web app into a complex beast.

Hope you enjoy reading the article as much as I enjoyed writing it.

Photo by AJITH S on Unsplash

A simple trick for your dotenv files

Victor Ocnarescu — Sat, 04 Mar 2023 11:08:30 +0000

I'm sure most of you know and use dotenv files. They are great for storing app configs: everything that is likely to vary between deploys

MY_APP_KEY=supersecret

These app configs are stored in a convenient key/value pair in a dotenv file. But what may come as a surprise to you is that every value is a string

DAYS_UNTIL_DATA_DELETION=60
AWS_DISABLE=true

Both are in fact strings. Later on, when you will want to check if AWS is disabled, you will have to write this code (which I have seen over and over again in many projects)

if (process.env.AWS_DISABLE === "true") { ... } // what???

That is just silly! When faced with boolean values I always write them with yes/no instead of true/false.

Furthermore, I quote every value in the dotenv files to make sure that every developer that reads the file knows the values are strings.

Here is the result:

MY_APP_KEY="supersecret"
DAYS_UNTIL_DATA_DELETION="60"
AWS_DISABLE="yes"

Hope you enjoyed reading the article as much as I enjoyed writing it. And please do not store your boolean config values as strings. Give the yes/no option a try.

Photo by Tekton on Unsplash

My secret trick for writing great React components

Victor Ocnarescu — Mon, 29 Nov 2021 18:24:28 +0000

I have a confession to make. I do not write a single test for my React components. Yes, you read that right, not a single one. You might wonder how I keep track of complex React projects with many many components. Here's my trick:

Always write React components that you can read without scrolling.

As a rule of thumb, if you cannot read a React component without scrolling, then I bet it does more than one thing. It has more than one responsibility, more than one single purpose.

Thinking in React

The first thing you’ll want to do is to draw boxes around every component (and subcomponent) in the mock and give them all names.

This is an actual quote from the React docs that apparently everybody forgot to read.

If you follow this advice every component that you write will do one and only one thing, will serve only one purpose. If it ends up growing, it should be decomposed into smaller subcomponents.

What about complex functions that manipulate data? This is also simple: I just create a pure function with all the logic, save it in a file and just use it in my React components.

Let's see some code

Let's assume I want to add React Context to one of my components.

const AwesomeComponent = (props) => {
  const defaults = {
    mode: 'dark',
  };
  const cache = {
    mode: local.get('theme.mode'),
  };
  const initialTheme = merge(defaults, cache);
  const [theme, setTheme] = useState(initialTheme);

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      <div className="awesome-component">
        <div>everything else...</div>
      </div>
    </ThemeContext.Provider>
  );
};

The first part of the component uses the useState React hook. It also initializes the state with some default values taken from some options cached values.

First improvement

The defaults can really grow over time to many other options, not just mode. Let's make a function that initializes the state. This function will have a single purpose: initializing the state.

const AwesomeComponent = (props) => {
  const [theme, setTheme] = useState(themable());

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      <div className="awesome-component">
        <div>everything else...</div>
      </div>
    </ThemeContext.Provider>
  );
};

Second improvement

The component still does more than it should. Let's move the hard-to-read React context code in a separate component and just implement it in our main component. This way we will not care how the context is initialized, we will care only that the context WAS initialized.

const AwesomeComponent = (props) => {
  return (
    <Theme>
      <div className="awesome-component">
        <div>everything else...</div>
      </div>
    </Theme>
  );
};

More improvements

If you start thinking this way in React you will notice these small changes everywhere in your projects. And your projects will become better and better.

Final thoughts

Code clutter

We're all guilty of it. Junior devs, senior devs, fullstack devs. We all have written God classes in OOP or huge React components without splitting them by purpose.

But this has to change, otherwise the complex project you are working on is going to become a complex monster project.

And it has to change fast. So next time you plan to write some React component, hook or just a plain function: why not split it in multiple files, each one with a single responsibility? The world of programming would be a much better place.

Code your own multi language system in React

Victor Ocnarescu — Fri, 10 Sep 2021 12:48:33 +0000

Do you need to support multiple languages in your React app? Thinking about which NPM package to install? What if I told you could develop your own multi language system in 5 minutes or less?

The dictionary

First you will need some file which will store the strings you want to translate and their correspondent translations. Think about this file as a key/value pair of translations.

For this I will use a JSON file:

// languages/es.json
{
  "Hello world": "Hola mundo",
  "Homepage": "Página principal",
  // ... and so on
}

Adding translations to existing components

Let's assume you have this basic component that you wish to add the new translations.

// components/App.jsx
const App = () => {
  return (
    <div>
      <h1>Hello world</h1>
      <a href="#">Homepage</a>
    </div>
  );
};

Next you will want to add the new translations. One way to do it is to create a new function that translates the text.

// components/App.jsx
const App = () => {
  return (
    <div>
      <h1>{translate('Hello world')}</h1>
      <a href="#">{translate('Homepage')}</a>
    </div>
  );
};

But you can do better, so much better. Instead of the function, why not create a component? After all, components are the essence of React; they make React so wonderful.

// components/App.jsx
const App = () => {
  return (
    <div>
      <h1><Translate>Hello world</Translate></h1>
      <a href="#"><Translate>Homepage</Translate></a>
    </div>
  );
};

Much better, isn't it? Next step is to actually implement the Translate component.

Coding the Translate component

// components/Translate.jsx
import { useContext } from 'react';
import { AppContext } from '.';
import * as languages from '../languages';

const translate = (text) => {
  const { language } = useContext(AppContext);

  // return the translated text or the original text
  if (Object.keys(languages).includes(language)) {
    return languages[language][text] || text;
  }

  return text;
};

const Translate = ({ children }) => {
  return translate(children);
};

export default Translate;

You will also need to keep the language you want to translate in React context. Language should be kept as React context because it should be available anywhere in the app, similar to a "theme".

Closing thoughts

A simple multi language system in React can be developed fairly quick without using any third party packages. You will need:

texts you want to translate stored in a JSON file
store the language you want to translate your app in a React context
the <Translate> component that you can add anywhere in your app

This system does not handle edge cases (yet), but it's a great start. Bonus: your React components will be quite readable.

How do you implement multi language systems in your React apps? Let me know in the comment section below.

Quick security wins for your Next.js app

Victor Ocnarescu — Thu, 09 Sep 2021 15:17:29 +0000

Let's secure your next Next.js app (pun intended) in 3 minutes or less using HTTP response headers.

I will not go into details about every HTTP header used below. This Web Security Cheat Sheet from MDN is a great place to start learning about these.

However, I will point out that these headers provide some form of protection against cross-site scripting (XSS) vulnerabilities.

Using custom headers

Let's see some code!

First, let's create a new file headers.js with every header used in the app. This way we'll keep our project structure clean and DRY.

module.exports = [
  {
    key: 'X-DNS-Prefetch-Control',
    value: 'on',
  },
  {
    key: 'Strict-Transport-Security',
    value: 'max-age=63072000; includeSubDomains; preload',
  },
  {
    key: 'Server',
    value: 'Apache', // phony server value
  },
  {
    key: 'X-Content-Type-Options',
    value: 'nosniff',
  },
  {
    key: 'X-Frame-Options',
    value: 'sameorigin',
  },
  {
    key: 'X-XSS-Protection',
    value: '1; mode=block',
  },
  {
    key: 'Referrer-Policy',
    value: 'same-origin',
  },
  {
    key: 'Permissions-Policy',
    value: 'geolocation=*', // allow specified policies here
  },
];

Now that we have a single file for all our HTTP headers, we need to include them in the next.config.js file.

const headers = require('./headers');

module.exports = {
  // append this at the bottom of your next.config.js file
  async headers() {
    return [
      {
        source: '/(.*)',
        headers,
      },
    ];
  },
};

This will apply the defined HTTP response headers to all routes in your application, as seen in this Vercel guide.

I have included these security headers in my Next.js starter template on Github. It has plenty of cool features I hope you'll like.

Closing thoughts

You can scan your app for possible vulnerabilities using this awesome tool. And if you have a Next.js app and forgot to secure it, now is the perfect time.

Something missing? Disagree with something from the article? I would love to hear your opinion in the comment section below.

Better conditional css classes in React

Victor Ocnarescu — Tue, 24 Aug 2021 07:48:14 +0000

Something short and sweet: let's explore one of the better ways to write conditional classes in React. I will use a simple menu item functional component and some pseudocode.

const MenuItem = ({ children }) => {
  // TODO: add classes when a menu item is "active"
  // TODO: optionally add classes for dark theme
  return (
    <li className="menu-item">
      {children}
    </li>
  );
};

First attempt: Logical && operator

const MenuItem = ({ children }) => {
  return (
    <li className={`menu-item ${isActive && 'menu-item-active'}`}>
      {children}
    </li>
  );
};

Cons: This code actually has a hidden bug. For falsy values the false css class appears in the DOM. Let's get rid of the bug in our next attempt.

Second attempt: Ternary operator

const MenuItem = ({ children }) => {
  return (
    <li className={`menu-item ${isActive ? 'menu-item-active' : ''}`}>
      {children}
    </li>
  );
};

Cons: This code does not have any hidden bugs like before, but looks too complex for such a simple task. It is also not so readable as it should be and can get event worse: imagine having other use conditions like isDarkTheme.

Third attempt: Constructing className strings

The third attempt and my personal favorite is using a function (npm package) to construct the className. It is actually a mix of the first 2 attempts:

const MenuItem = ({ href, children }) => {
  return (
    <li className={classnames(
      'menu-item',
      isActive && 'menu-item-active',
      isDarkTheme && 'menu-item-dark'
    )}>
      {children}
    </li>
  );
};

NPM packages

Here is a list of NPM packages and their bundle sizes. They all have the same implementations, so you can choose which one suits you best:

classnames with a tiny 729 bytes
clsx with a tiny 516 bytes
merge-class-names at an incredibly tiny 372 bytes

Conclusion

We as developers always read more code than we write. That's why I always choose to write code that is more readable and easily understandable by anyone.

Better file structure in React projects

Victor Ocnarescu — Fri, 20 Aug 2021 10:30:05 +0000

Is there a perfect file structure for React projects? Probably not. But some are far better than others.

Over the years I discovered that I tend to structure files in some specific ways, which I believe are easier to understand and reasonable.

Meaningful folder names

Naming things is one of the toughest things to get right in programming. One of my favorite tactics to naming folders is to extract the subject and use it:

want a place for public resources? the public folder should be a good fit;
have some custom hooks that you are proud of? keep them easy to find in the hooks folder;
want to include yet another css file? store them in the css folder.

And so on and so forth.

Little to no folder nesting

I always wondered about the src folder and why it exists. And to this day it still is one of the many mysteries of programming.

I like to keep all my folders as close to the project root as possible. This way, they can be discovered more easily by any new dev working on the project.

Avoiding too much nesting is also recommended by the official React documentation as well.

Grouping by feature

The components folder is one of my exceptions: it has two (2) levels of nesting. Common components are accessible right from the folder root, while "specialized" components have they own folder.

The contents of the components folder:

Button.jsx - common button components
Link.jsx - common link component
Forms
- AddClientForm.jsx - specific "form" component
- EditClientForm.jsx - another specific "form" component

Minimal example

This is the project structure for a starter project I authored and for many projects I'm working on right now.

api
components
css
data
functions
hooks
models
pages
public
LICENSE
README.md

I hope the folder structure is self explanatory. If it is not, I have done a lousy job at naming folders. Let me know in the comment section below.

Closing thoughts

My favorite file structure:

is easy to read and understand
is shallow nested
is grouped by features

Have a different opinion? Can't wait to hear it!