DEV Community: Alexandru-Dan Pop

Releasing features with confidence as a software developer

Alexandru-Dan Pop — Wed, 09 Aug 2023 07:07:06 +0000

Unit Tests
CI/CD Pipelines
Feature Flags
Conclusion

As a software developer, there's this awesome rush when you see your code bring new features to life. It's like watching your digital creations come alive!

However, this excitement is often accompanied by the challenge of ensuring a smooth release that doesn't disrupt the user experience or introduce new bugs.

In this post, we'll dive into the art of releasing features with confidence, exploring not only the basics but also when to use feature flags and A/B tests.

Automated tests and CI/CD pipelines

Unit Tests

Before we embark on our journey of releasing features, it's essential to emphasize the importance of unit tests.

Preferably written using Test-Driven Development (TDD), unit tests serve as the bedrock of your codebase, ensuring that individual components of your application function as intended.

With TDD (writing tests before the actual code), you're compelled to think deeply about the code you write and potential edge cases, resulting in more robust and reliable code.

CI/CD Pipelines

Continuous Integration and Continuous Deployment (CI/CD) pipelines automate the process of building, testing, and deploying your code.

Like described in the video above (and with a few twists from my side), the ideal CI/CD pipeline for critical applications should include:
1) Source code integration step with

installing dependencies, build or compiling the code
running quality checks (for example SonarQube, linting, etc)
running unit tests (quality of the unit tests can be checked with mutation testing)
check and enforce code coverage

2) Deploy to test environment

running integration tests

3) Deploy to production

observability
alerts

For more critical systems or advanced use cases, a canary deployment strategy can be implemented. This means a gradual roll-out while traffic is gradually shifted from the old deployment to the new one.

Feature Flags and A/B Tests

Feature Flags

Feature flags (FF), also known as feature toggles or feature switches, are a technique that allows you to enable or disable certain features within your application without deploying new code.

There are many types of flags, but the most common would be to just turn a toggle on or off in a certain environment.

Example of a FF: Google_Login (dev - enabled, stage - enabled, prod - disabled). The power here is that we can turn the feature flag off in case we discover a bug with the Google Login, so we don't need to do a rollback or even worse a hotfix. We just disable the flag in production, push a fix then re-enable it.

Managing Feature Flags
It's important to have a system (external or internally built) to easily manage feature flags. While FFs provide flexibility, it's essential to strike a balance.

Keeping the number of active flags to a minimum reduces complexity and avoids potential confusion among developers. Just as you regularly refactor your codebase, it's important to remove old feature flags both from your code and your flag management system.

// Detect dark theme var iframe = document.getElementById('tweet-1687416719818489857-82'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1687416719818489857&theme=dark" }

A/B Tests

A/B testing, or split testing, involves comparing two versions of a feature or webpage to determine which one performs better. By dividing your users into two groups (A and B) and exposing them to different versions of a feature, you can gather empirical data to make informed decisions.

How A/B Testing Works: A/B testing allows you to release a new feature or design change to a subset of your users while keeping the original version for another group. By comparing user behavior and engagement metrics, you can objectively measure the impact of the change.

Primary & Secondary Metrics: When setting up an A/B test, it's essential to define primary and secondary metrics. Primary metrics directly measure the success of the feature, while secondary metrics provide additional insights. Analyzing both types of metrics helps you make well-rounded decisions.

Example: We observe that only 2% of the traffic in our website results in a user signing for our newsletter. We do some UX research and come up with an updated design of the landing page, and we try it out in a A/B test. Our current page (the control group) and the variation are both served to our customers. During a 2 week period we observe the new page results in 4% of the traffic subscribing to thew newsletter. Succes!

Clean-Up After A/B Tests: Just as with FFs, A/B test clean-up is crucial. Once you've collected enough data and made your decision, be sure to remove the code related to the alternative version, and also archive the test in the A/B test management system.

Conclusion

Releasing features with confidence requires a delicate balance of foundational practices and advanced strategies. Automated tests instill thoughtfulness in your code, while CI/CD pipelines ensure consistent and reliable deployments. However, the real magic happens when you embrace feature flags and A/B tests.

And it will also make you look cool, imagine you just discussed with the Product Manager whether to release that new stuff you worked on last 2 weeks, and he tells you to release it. You switch the feature toggle on, and there it is, one minute later.

So while feature flags empower you to release and iterate on features with flexibility and control, A/B tests provide the empirical data needed to make informed decisions about the usefulness of the changes you are making in the software.

Ubuntu 20.04 - how to make it perfect for development & productivity

Alexandru-Dan Pop — Mon, 05 Apr 2021 14:57:45 +0000

Since I recently configured my laptop to dual boot into Ubuntu 20.04, I wanted to share my experience and what I think you can do to make your use of this system as pleasant as possible.

I'm very impressed by how stable this system is and how customizable it is & quite frankly I think it makes an awesome dev environment.

This article assumes that you already configured your system to run Linux (Ubuntu 20.04) - and describes what customizations I did that I think are cool. If you haven't installed Ubuntu 20.04 yet, a simple google search will get you all info needed on how to create a bootable USB with Ubuntu, how to shrink your current Windows partition & finally configure BIOS to boot & install Linux.

Also, please note that this article is just scratching the surface of the configuration options of Ubuntu.

MacOS BigSur theme

Since I've used an M1 Mac with BigSur for a while I got very used to the "BigSur theme" and the good thing is you can replicate this on Ubuntu.

Here's how:

Add the universe apt repo: sudo apt-add-repository universe
Install gnome tweeks: sudo apt install gnome-tweak-tool
Install gnome shell extensions: sudo apt install gnome-shell-extensions
Download the WhiteSur Gtk Theme from here. I downloaded both the simple dark & light ones.
In your home folder create a .themes folder if it doesn't exist and unzip the downloaded folders there.
Download and unzip the WhiteSur icon theme from here and put it in your home directory in a .icons folder
Once you do this you open Tweaks app and configure the themes and icons:

Note you can also install & configure MacOS fonts, but I like the Ubuntu ones so I kept those.

One additional thing I did was install a BigSur wallpaper image, that you can easily find on google, and now the apps you open on your new Ubuntu installation will look like this, and I personally think it's pretty nice:

Configure Dash to dock

One more thing I consider it's nice to do is to configure Dash to dock - this can give you also a dock experience similar to macOS.

To do this:

Go to Gnome Extensions and install dash to dock
Go to the Tweaks app again in the Extensions section - Dash to dock should be enabled or enable it if it's not - and disable Ubuntu dock.
You should see the Dash to dock now - right-click on the 9 little dots icon - and click on Dash to dock settings. From here you can configure the position on screen - Bottom, the sizes of the icons (for me it's 32px), and in the Appearance tab - the Opacity and other small things.

You should probably log out & log in again to make sure the settings are applied.

The steps above are courtesy of this video, but using the WhiteSur theme, and with simplified steps.

Install Albert

Albert is a spotlight-like search tool (launcher) for Linux. Even though Ubuntu already comes with a pretty nice search functionality out of the box - pressing the Super/Windows key, I still like using Albert more.

You can read more about it and how to install it from here.

After you install it, make sure to go to Startup Applications app and configure it to run on startup. The command to launch it should be /usr/bin/albert. You can start Albert, and from the Settings screen configure your desired hotkey to open it and the Theme (I choose Spotlight Dark).

Install Tilix terminal

I like Tilix better than the default terminal, I like how customizable it is, and the split panel feature. I configure it so ctrl+t adds a new split terminal and ctrl+w closes a panel. You can install Tilix from the Ubuntu Software app.

I also installed fish shell and use it as the default shell. I think fish is a much nicer shell, especially for the autosuggestions. You can check it out here.

Brave browser

Brave is my default browser for a few months. It's exactly like Google Chrome (Chromium-based), so you can use all extensions & features you have on Chrome, but unlike Chrome - it's not a tracking machine.

It supports ad-blocking and tracker-blocking out of the box.

You can set it to use DuckDuckGo as the default search engine, and probably have a much better web surfing experience since you don't see all those ads and trackers don't make the websites you visit slow.

You can add Brave from the Ubuntu Software app.

Dev & productivity tools

I won't insist too much on this aspect, as it's pretty obvious that the best tools for development work great on this distro, and are pretty easy to install. I use:

VSCode
Notepad++
Docker
Postman
Homebrew
Nodejs, yarn, etc.

From my previous experience of trying out the M1 Mac, and trying all sorts of workarounds for simple stuff, I can say everything has been a breeze on Linux. 😊

The M1 Mac - Is it worth it for devs?

Alexandru-Dan Pop ・ Mar 1 '21

I also like using Spotify that works great here & Notion for note-taking & personal task management.

I use Melde as a 3-way merge tool for git - that is also pretty easy to configure - see below:

If I do a cd ~ && cat .gitconfig - will only copy here the merge tool config:



[merge]
    tool = meld
[mergetool "meld"]
    cmd = meld "$LOCAL" "$MERGED" "$REMOTE" --output "$MERGED"
"$MERGED"
    keepBackup = false

Then when you have a git conflict, you can use: git mergetool to fix it.

Make it faster

Linux systems are extremely memory-efficient, I sometimes look at the OS especially without having many things running and I marvel at how little memory it uses compared to Windows or macOS. But some application startup times are not the best, but for this, you can use preload, at the cost of some additional RAM.

To improve startup times for different applications:
sudo apt install preload

Conclusions

Consider trying Ubuntu or some other Linux distro if you are a developer. You will not regret it!

You might even see that your 3y old laptop/mac doesn't need an upgrade, just because of how memory efficient & well-optimized Linux is.

Thanks for reading, if you enjoy this article chances are you will also like what I post on Twitter.

The M1 Mac - Is it worth it for devs?

Alexandru-Dan Pop — Mon, 01 Mar 2021 11:04:07 +0000

I can say I was very impressed by the benchmarks results given by those machines, so I decided to try one out.

TLDR - I didn't choose the M1 Mac Mini as a mainly daily driver - yet - until docker will be fully supported. I'll use it for frontend workflows that involve running a bunch of the node.js tasks + mock APIs + continuously running tests in the background.

// Detect dark theme var iframe = document.getElementById('tweet-1358002530245095427-445'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1358002530245095427&theme=dark" }

Why I choose the M1 Mac Mini with 16GB RAM

I wanted to use it with - 2 big monitors (M1 MacBooks support only one external display - although there are workarounds). I don't like staring into small laptop screens, so for using both my monitors and also having more ports I have chosen the Mac Mini instead of the MacBooks.

Also, I am working remotely and already have a Dell XPS 15 laptop. So buying an M1 laptop didn't make sense - since I can use my laptop when I need portability.

I went for 16GB of RAM because some of my development workflows require running multiple docker containers locally, and we all know how much memory docker consumes. Also, I noticed that the 16 GB model barely uses less than ~7-8GB RAM but I'll get to that later.

Impressions

A lot of my development work implies running VSCode and node.js locally for frontend workflows.

Running the native arm node.js on this machine is extremely performant. Can say for some frontend builds I was getting ~60% speed increases from my 2y old Dell XPS 15.

With a local frontend workflow (build and running unit tests), lots of Chrome tabs open, docker running a few containers, VSCode, Spotify, and other programs running in the background I haven't seen it use more than '~12,5GB' of RAM. It never used the full '16GB' RAM. But it does use SSD swap, so that's interesting.

I did see that with very little use - like a few Chrome tabs + other background apps that run by default it will quickly consume the "standard" 8GB of RAM.

Caveats

I spent countless hours getting around some issues like for a Gatsby project I could not make the 'sharp' module work. When I finally managed to do that, BigSur had an update and after that, the arm version of node.js didn't work anymore. 🙀

I also tried docker and certain images that work on my Windows 10 laptop or on an Intel MacBook. Around half of them don't work on the M1 with docker for M1 preview. With some tweaks, I managed to run some of them, but others without luck.

Things to consider

Before considering this as your main machine check:

Is Apple silicon ready website to browse if the software you use is compatible yet or can run through Rosetta 2
consider issues like USB-C connected monitors not working from time to time (mine hiccups sometimes and have to unplug/plug the cable)
consider Bluetooth issues - those seem to be partly fixed, but I still experienced some smaller issues when you need to manually connect the devices
docker issues
no E-GPU support
Boot Camp no longer works
some users reported accelerated SSD tear

I also recommend you to watch some of Alexander Ziskind's Youtube videos around the M1 Macs. He is comparing them to Intel Macs or laptops and trying out various programming tools.

Personal conclusions

My impression is that if you have moderately big projects to work on - with a lot of dependencies & especially if you need to use docker - you will run into various issues that you need to fix. Some of those fixes will be easier as the community posts issues and fixes on Github. But for some other issues, you will just need to wait for fixes and use an x86 machine in the meantime.

Overall, I consider it a good price for a performant machine.

If you do mostly web development or web design and don't rely on things like docker or if you can use a mock API to mock your backend dependencies - I think this system makes a lot of sense.

If you are just learning programming, an M1 Mac Mini is a good machine considering the costs - you could even go for the cheapest M1 Mac mini. ✌️

// Detect dark theme var iframe = document.getElementById('tweet-1358214187244277771-8'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1358214187244277771&theme=dark" }

If you are patient and already have a good computer, you could probably wait around 3-6 months to see if more stable versions of the software you use pop up. Although seeing how fast the trend of fixing issues is - I think a lot of the current problems will be fixed soon.

If you are using Windows, I also have an article for setting things up for development and making a Windows machine more pleasant for development.

Modern Windows 10 development setup

Alexandru-Dan Pop ・ Oct 25 '20

And, if you want to embrace Linux but like the MacOs BigSur look & feel, I wrote an article how to tweak Ubuntu to look like BigSur & configure some extra stuff to make it more pleasant:

Ubuntu 20.04 - how to make it perfect for development & productivity

Alexandru-Dan Pop ・ Apr 5 '21

Creating a Calculator app with React and TDD

Alexandru-Dan Pop — Sun, 14 Feb 2021 16:06:58 +0000

Let us build a simple web-app calculator with a test-first approach and React!

I highly suggest you follow this exercise if you are already familiar with React, and want to also step up your testing game. 🌟

We will approach building a simple app, with only the basic calculation functions - but most importantly - we will follow a Test Driven Developmnet approach.

Test-driven development (TDD) is a development technique where you must first write a test that fails before you write new functional code. TDD is being quickly adopted by agile software developers for development of application source code and is even being adopted by Agile DBAs for database development. (agiledata.org)

Image stolen from agiledata.org.

Setup

We want a quick setup that provides us with testing already configured for us so we are picking good old create-react-app for this. We will also choose the TypeScript template. So open a terminal and run:

npx create-react-app calculator --template typescript
cd calculator
Open an editor. I'll use VS Code:
code .

Have two terminal windows open:

one to run npm start
one to run npm run test

Let's start coding

Start coding you say? Funny. I thought we were doing TDD. Of course, we want to create a failing test first. But where do we start?

Go to App.test.tsx, delete the existing test and write:

test("renders calculator", () => {
  render(<App />);
  const calculatorElement = screen.getByText(/calculator/i);
  expect(calculatorElement).toBeInTheDocument();
});

And there you go, our terminal that runs the tests should output:
Tests: 1 failed, 1 total

Our test just naively checks that we have somewhere in our app the text calculator rendered.

So we will create a Calculator.tsx file with:

const Calculator = () => <h1>Calculator</h1>;

export default Calculator;

The test still fails. Well.. We are not yet rendering our Calculator component. Let's fix that. Go to 'App.tsx':

import React from "react";
import "./App.css";
import Calculator from "./Calculator";

function App() {
  return (
    <div className="App">
      <main>
        <Calculator />
      </main>
    </div>
  );
}

export default App;

✅Tests: 1 passed, 1 total - great we passed our first test. Now what?

Do we build the code for the calculator?
❌ Of course not, we write another failing test, now in 'Calculator.test.tsx', to show the calculator numbers:

import { render, screen } from "@testing-library/react";
import React from "react";
import Calculator from "./Calculator";

describe("<Calculator />", () => {
  it("shows numbers", () => {
    render(<Calculator />);
    const numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];

    numbers.forEach((n) => {
      expect(screen.getByText(n.toString())).toBeInTheDocument();
    });
  });
});

And in Calculator.tsx:

+ const numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
+ const Calculator = () => {
+   return (
+     <div className="calculator">
      <h1>Calculator</h1>
+       {numbers.map((n) => (
+         <button key={n}>{n.toString()}</button>
+       ))}
+     </div>
+   );
+ };

export default Calculator;

Alright, at this point, if we look at the app we have something like:

Render rows of numbers

We want to show our numbers in rows:
Row 1: [7, 8, 9]
Row 2: [4, 5, 6]
Row 3: [1, 2, 3]
Row 4: [0]

Hmm.. how do we test that? So in 'Calculator.test.tsx', we could have a new test like:

  it("shows 4 rows", () => {
    render(<Calculator />);
    const rows = screen.getAllByRole("row");

    expect(rows).toHaveLength(4);
  });

Alright, now that we have the failing test, to pass it:

const rows = [[7, 8, 9], [4, 5, 6], [1, 2, 3], [0]];

const Calculator = () => {
  return (
    <div className="calculator">
      <h1>Calculator</h1>
      <div role="grid">
        {rows.map((row) => {
          return (
            <div key={row.toString()} role="row">
              {row.map((n) => (
                <button key={n}>{n.toString()}</button>
              ))}
            </div>
          );
        })}
      </div>
    </div>
  );
};

export default Calculator;

Let's also check our app:

Show calculator operators

Test to show operators:

  it("shows calculation operators", () => {
    render(<Calculator />);
    const calcOperators = ["+", "-", "×", "÷"];

    calcOperators.forEach((operator) => {
      expect(screen.getByText(operator.toString())).toBeInTheDocument();
    });
  });

Pass the test:

const rows = [[7, 8, 9], [4, 5, 6], [1, 2, 3], [0]];
+ const calcOperators = ["+", "-", "×", "÷"];
const Calculator = () => {
  return (
    <div className="calculator">
      <h1>Calculator</h1>
      <div role="grid">
        {rows.map((row) => {
          return (
            <div key={row.toString()} role="row">
              {row.map((n) => (
                <button key={n}>{n.toString()}</button>
              ))}
            </div>
          );
        })}
+       {calcOperators.map((c) => (
+         <button key={c}>{c.toString()}</button>
+       ))}
      </div>
    </div>
  );
};

export default Calculator;

Great! It looks terrible 😅. Don't worry, we will fix the styles later.

Show an equal sign & clear sign:

Tests:

  it("renders equal", () => {
    render(<Calculator />);
    const equalSign = "=";
    expect(screen.getByText(equalSign)).toBeInTheDocument();
  });

  it("renders clear sign", () => {
    render(<Calculator />);
    const clear = "C";
    expect(screen.getByText(clear)).toBeInTheDocument();
  });

Great, 2 tests are failing. To fix:

import { Fragment } from "react";

const rows = [[7, 8, 9], [4, 5, 6], [1, 2, 3], [0]];
const calcOperators = ["+", "-", "×", "÷"];
const equalSign = "=";
const clear = "C";
const Calculator = () => {
  return (
    <div className="calculator">
      <h1>Calculator</h1>
      <div role="grid">
        {rows.map((row, i) => {
          return (
            <Fragment key={row.toString()}>
              <div role="row">
                {i === 3 && <button>{clear}</button>}
                {row.map((n) => (
                  <button key={n}>{n}</button>
                ))}
                {i === 3 && <button>{equalSign}</button>}
              </div>
            </Fragment>
          );
        })}
        {calcOperators.map((c) => (
          <button key={c}>{c.toString()}</button>
        ))}
      </div>
    </div>
  );
};

export default Calculator;

Show an input for values to be calculated

Test:

  it("renders an input", () => {
    render(<Calculator />);
    expect(screen.getByPlaceholderText("calculate")).toBeInTheDocument();
  });

We always want this input to be disabled, so we will also add a test for that:

  it("renders an input disabled", () => {
    render(<Calculator />);
    expect(screen.getByPlaceholderText("calculate")).toBeDisabled();
  });

Implement the input:

+ import { Fragment, useState } from "react";

const rows = [[7, 8, 9], [4, 5, 6], [1, 2, 3], [0]];
const calcOperators = ["+", "-", "×", "÷"];
const equalSign = "=";
const clear = "C";
const Calculator = () => {
+  const [value, setValue] = useState("");
  return (
    <div className="calculator">
      <h1>Calculator</h1>
+     <input
+      type="text"
+      defaultValue={value}
+      placeholder="calculate"
+      disabled
+     />
      <div role="grid">
        {rows.map((row, i) => {
          return (
            <Fragment key={row.toString()}>
              <div role="row">
                {i === 3 && <button>{clear}</button>}
                {row.map((n) => (
                  <button key={n}>{n}</button>
                ))}
                {i === 3 && <button>{equalSign}</button>}
              </div>
            </Fragment>
          );
        })}
        {calcOperators.map((c) => (
          <button key={c}>{c.toString()}</button>
        ))}
      </div>
    </div>
  );
};

export default Calculator;

Make it display the user's inputs

Tests:

  it("displays users inputs", async () => {
    render(<Calculator />);
    const one = screen.getByText("1");
    const two = screen.getByText("2");
    const plus = screen.getByText("+");
    fireEvent.click(one);
    fireEvent.click(plus);
    fireEvent.click(two);

    const result = await screen.findByPlaceholderText("calculate");
    // @ts-ignore
    expect(result.value).toBe("1+2");
  });

  it("displays multiple users inputs", async () => {
    render(<Calculator />);
    const one = screen.getByText("1");
    const two = screen.getByText("2");
    const three = screen.getByText("3");
    const five = screen.getByText("5");
    const divide = screen.getByText("÷");
    const mul = screen.getByText("×");
    const minus = screen.getByText("-");
    fireEvent.click(three);
    fireEvent.click(mul);
    fireEvent.click(two);
    fireEvent.click(minus);
    fireEvent.click(one);
    fireEvent.click(divide);
    fireEvent.click(five);

    const result = await screen.findByPlaceholderText("calculate");
    // @ts-ignore
    expect(result.value).toBe("3×2-1÷5");
  });

Pass the tests:

               <div role="row">
                 {i === 3 && <button>{clear}</button>}
                 {row.map((n) => (
-                  <button key={n}>{n}</button>
+                  <button
+                    onClick={() => setValue(value.concat(n.toString()))}        
+                    key={n}
+                  >
+                    {n}
+                  </button>
                 ))}
                 {i === 3 && <button>{equalSign}</button>}
               </div>

         {calcOperators.map((c) => (
-          <button key={c}>{c.toString()}</button>
+          <button onClick={() => setValue(value.concat(c))} key={c}>
+            {c.toString()}
+          </button>
         ))}

Can it calculate?

Alright, so up until now we just wrote some tests to check if our calculator displays the right stuff, but let us write some tests for it to actually calculate something:

  it("calculate based on users inputs", async () => {
    render(<Calculator />);
    const one = screen.getByText("1");
    const two = screen.getByText("2");
    const plus = screen.getByText("+");
    const equal = screen.getByText("=");
    fireEvent.click(one);
    fireEvent.click(plus);
    fireEvent.click(two);
    fireEvent.click(equal);

    const result = await screen.findByPlaceholderText("calculate");

    expect(
      (result as HTMLElement & {
        value: string;
      }).value
    ).toBe("3");
  });

  it("calculate based on multiple users inputs", async () => {
    render(<Calculator />);
    const one = screen.getByText("1");
    const two = screen.getByText("2");
    const three = screen.getByText("3");
    const five = screen.getByText("5");
    const divide = screen.getByText("÷");
    const mul = screen.getByText("×");
    const minus = screen.getByText("-");
    const equal = screen.getByText("=");

    fireEvent.click(three);
    fireEvent.click(mul);
    fireEvent.click(two);
    fireEvent.click(minus);
    fireEvent.click(one);
    fireEvent.click(divide);
    fireEvent.click(five);
    fireEvent.click(equal);

    const result = await screen.findByPlaceholderText("calculate");
    expect(
      (result as HTMLElement & {
        value: string;
      }).value
    ).toBe("5.8");
  });

Notice in our second test we also check that the operations are executed in the correct order:
3*2-1÷5 = 6-0.2 = 5.8

And, let us make this pass. At this stage, we can use the unsafe eval function, which we will refactor later. Remember, we only need to pass the tests. We can always write a test to propose why our current implementation is not ok.

const rows = [[7, 8, 9], [4, 5, 6], [1, 2, 3], [0]];
 const calcOperators = ["+", "-", "×", "÷"];
 const equalSign = "=";
 const clear = "C";
+
+const calculateExpression = (expression: string) => {
+  const mulRegex = /×/g;
+  const divRegex = /÷/g;
+
+  const toEvaluate = expression.replace(mulRegex, "*").replace(divRegex, "/");
+
+  // todo - refactor eval later
+  const result = eval(toEvaluate);
+  return result;
+};
+
 const Calculator = () => {
   const [value, setValue] = useState("");
+
+  const calculate = () => {
+    const results = calculateExpression(value);
+    setValue(results);
+  };
+
   return (
     <div className="calculator">
       <h1>Calculator</h1>
@@ -29,7 +47,7 @@ const Calculator = () => {
                     {n}
                   </button>
                 ))}
-                {i === 3 && <button>{equalSign}</button>}
+                {i === 3 && <button onClick={calculate}>{equalSign}</button>}
               </div>
             </Fragment>
           );

Can use clear button

The test:

  it("can clear results", async () => {
    render(<Calculator />);
    const one = screen.getByText("1");
    const two = screen.getByText("2");
    const plus = screen.getByText("+");
    const clear = screen.getByText("C");
    fireEvent.click(one);
    fireEvent.click(plus);
    fireEvent.click(two);

    fireEvent.click(clear);

    const result = await screen.findByPlaceholderText("calculate");
    expect(
      (result as HTMLElement & {
        value: string;
      }).value
    ).toBe("");
  });

Easy:

const Calculator = () => {
     setValue(results);
   };
+ 
+  const clearValue = () => setValue("");
+
   return (
     <div className="calculator">
       <h1>Calculator</h1>
@@ -38,7 +40,7 @@ const Calculator = () => {
           return (
             <Fragment key={row.toString()}>
               <div role="row">
-                {i === 3 && <button>{clear}</button>}
+                {i === 3 && <button onClick={clearValue}>{clear}</button>}
                 {row.map((n) => (

Back to calculating stuff

Alright, so at this point, we maybe want to test more scenarios for the calculate function. So I think it makes more sense to write those tests directly on the calculateExpression function.

So we will export it and write some extra tests:

describe("calculateExpression", () => {
  it("correctly computes for 2 numbers with +", () => {
    expect(calculateExpression("1+1")).toBe(2);
    expect(calculateExpression("10+10")).toBe(20);
    expect(calculateExpression("11+345")).toBe(356);
  });

  it("correctly substracts 2 numbers", () => {
    expect(calculateExpression("1-1")).toBe(0);
    expect(calculateExpression("10-1")).toBe(9);
    expect(calculateExpression("11-12")).toBe(-1);
  });

  it("correctly multiples 2 numbers", () => {
    expect(calculateExpression("1×1")).toBe(1);
    expect(calculateExpression("10×0")).toBe(0);
    expect(calculateExpression("11×-12")).toBe(-132);
  });

  it("correctly divides 2 numbers", () => {
    expect(calculateExpression("1÷1")).toBe(1);
    expect(calculateExpression("10÷2")).toBe(5);
    expect(calculateExpression("144÷12")).toBe(12);
  });

  it("division by 0 returns 0 and logs exception", () => {
    const errorSpy = jest.spyOn(console, "error");
    expect(calculateExpression("1÷0")).toBe(undefined);
    expect(errorSpy).toHaveBeenCalledTimes(1);
  });
});

Our tests still pass, except for the one with the division by 0. That's good. Let's fix that.

-const calculateExpression = (expression: string) => {
+export const calculateExpression = (expression: string) => {
   const mulRegex = /×/g;
   const divRegex = /÷/g;
+  const divideByZero = /\/0/g;

   const toEvaluate = expression.replace(mulRegex, "*").replace(divRegex, "/");

-  // todo - refactor eval later
-  const result = eval(toEvaluate);
-  return result;
+  try {
+    if (divideByZero.test(toEvaluate)) {
+      throw new Error("Can not divide by 0!");
+    }
+
+    // todo - refactor eval later
+    const result = eval(toEvaluate);
+
+    return result;
+  } catch (err) {
+    console.error(err);
+    return undefined;
+  }
 };

Ok, more tests for some extra cases:

  it("handles multiple operations", () => {
    expect(calculateExpression("1÷1×2×2+3×22")).toBe(70);
  });

  it("handles trailing operator", () => {
    expect(calculateExpression("1÷1×2×2+3×22+")).toBe(70);
  });

  it("handles empty expression", () => {
    expect(calculateExpression("")).toBe(undefined);
  });

Watercooler 🌊

Alright, if you made it until here, congrats! 🙌 You are learning how to write code in a TDD way.

Please notice, at this point, the mentality is to add tests and see what tests fail. Maybe some will pass, some will fail, but we want to make sure we have a test-first approach and we are careful with the quality of the tests. If our tests are good, and they all pass, the app will perform well.

So let us fix the 2 failing tests we have now:

 const clear = "C";


+const getLastChar = (str: string) => (str.length ? str[str.length - 1] : "");
+const isNumber = (str: string) => !isNaN(Number(str));
+
 export const calculateExpression = (expression: string) => {
+  if (!expression || expression.length === 0) {
+    return;
+  }
+
   const mulRegex = /×/g;
   const divRegex = /÷/g;
   const divideByZero = /\/0/g;

-  const toEvaluate = expression.replace(mulRegex, "*").replace(divRegex, "/");
+  let toEvaluate = expression.replace(mulRegex, "*").replace(divRegex, "/");

   try {
     if (divideByZero.test(toEvaluate)) {
       throw new Error("Can not divide by 0!");
     }
+ 
+    const lastCharaterIsNumber = isNumber(getLastChar(toEvaluate));
+
+    if (!lastCharaterIsNumber) {
+      toEvaluate = toEvaluate.slice(0, -1);
+    }
+

Get rid of eval

Remember when we said we will change eval to something else. Yes, we want to avoid it as our linter and our common sense dictates we should not use it.

Luckily there is a package that does exactly what we want. Pass a string as an expression and safely evaluate it:
yarn add mathjs @types/mathjs

+import { evaluate } from "mathjs";

-    // todo - refactor eval later
-    const result = eval(toEvaluate);
+    const result = evaluate(toEvaluate);

What... our tests still pass? Cool!

Style the app

But the app is really ugly.. Let's fix that.

First, let us declare some variables in the index.css:

:root {
  --theme-color-dark-10: #006ba1;
  --theme-color-dark-20: #005a87;
  --theme-color-background: #fed800;
}

In the body we will just add the background color and leave the rest of the styles as they are:

 body {
+  background-color: var(--theme-color-background);

We will need to add a bit more structure to our Calculator.tsx:

import { Fragment, useState } from "react";
import { evaluate } from "mathjs";
import "./Calculator.css";

const rows = [[7, 8, 9], [4, 5, 6], [1, 2, 3], [0]];
const calcOperators = ["+", "-", "×", "÷"];
const equalSign = "=";
const clear = "C";

const getLastChar = (str: string) => (str.length ? str[str.length - 1] : "");
const isNumber = (str: string) => !isNaN(Number(str));

export const calculateExpression = (expression: string) => {
  if (!expression || expression.length === 0) {
    return;
  }

  const mulRegex = /×/g;
  const divRegex = /÷/g;
  const divideByZero = /\/0/g;

  let toEvaluate = expression.replace(mulRegex, "*").replace(divRegex, "/");

  try {
    if (divideByZero.test(toEvaluate)) {
      throw new Error("Can not divide by 0!");
    }

    const lastCharaterIsNumber = isNumber(getLastChar(toEvaluate));

    if (!lastCharaterIsNumber) {
      toEvaluate = toEvaluate.slice(0, -1);
    }

    const result = evaluate(toEvaluate);

    return result;
  } catch (err) {
    console.error(err);
    return undefined;
  }
};

const Calculator = () => {
  const [value, setValue] = useState("");

  const calculate = () => {
    const results = calculateExpression(value);
    setValue(results);
  };

  const clearValue = () => setValue("");

  return (
    <div className="calculator">
      <h1>Calculator</h1>
      <input
        type="text"
        defaultValue={value}
        placeholder="calculate"
        disabled
      />
      <div className="calculator-buttons-container">
        <div role="grid">
          {rows.map((row, i) => {
            return (
              <Fragment key={row.toString()}>
                <div role="row">
                  {i === 3 && <button onClick={clearValue}>{clear}</button>}
                  {row.map((n) => (
                    <button
                      key={n}
                      onClick={() => setValue(value.concat(n.toString()))}
                    >
                      {n}
                    </button>
                  ))}
                  {i === 3 && <button onClick={calculate}>{equalSign}</button>}
                </div>
              </Fragment>
            );
          })}
        </div>
        <div className="calculator-operators">
          {calcOperators.map((c) => (
            <button key={c} onClick={() => setValue(value.concat(c))}>
              {c.toString()}
            </button>
          ))}
        </div>
      </div>
    </div>
  );
};

export default Calculator;

We will also add a Calculator.css file, with:

.calculator > h1 {
  color: var(--theme-color-dark-20);
  text-transform: uppercase;
}

.calculator input {
  height: 2.5rem;
  width: 13rem;
  padding: 0.4rem;
  border: 1px solid white;
  margin: 0.3rem 0.3rem 1.5rem 0.3rem;
  font-size: 1.5rem;
  color: var(--theme-color-dark-20);
  box-shadow: 8px 8px 5px -7px var(--theme-color-dark-10);
}

.calculator button {
  width: 3.5rem;
  height: 3.5rem;
  font-size: 1.5rem;
  color: var(--theme-color-dark-20);
}

.calculator-buttons-container {
  display: flex;
  align-items: center;
  justify-content: center;
}

.calculator-operators {
  display: flex;
  flex-direction: column;
}

Looks better.

Conclusions

I want to stop here - still, the app has some bugs and things that can be fixed.

If you are up for it, fix them in a TDD style 🔥.

Here's the repo for this coding exercise.

// Detect dark theme var iframe = document.getElementById('tweet-1360695228890558466-50'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1360695228890558466&theme=dark" }

Microfrontends explained

Alexandru-Dan Pop — Sun, 17 Jan 2021 14:53:49 +0000

I'm addressing this topic because I get a feel that Microfrontends are no longer just a buzzword, they are being adopted rapidly in large web applications.

Microfrontends might be the next big thing in frontend development.

Let me tell you why!

What are Microfrontends?

Microfrontends is a software architecture pattern for frontend code. It is influenced by the backend microservices architecture pattern.

To understand microfrontends and why do we need them, we first need to know a bit about microservices.

Microservice architecture – a variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. (Wikipedia)

An example - if we would have a Webshop microservice backend, in which each service is owned by a team, we could have the following microservices:

Products
Products catalog (management)
Reporting
Customer
Orders

Note: This is a simplified view of a microservices architecture & in a real-world application we could have tens or hundreds of microservices.

In the frontend world, for an application like this - we could have:

Notice a few things:

each microfrontend can be built with different technologies
each microfrontend can be owned by a team
each microfrontend can depend on only one microservice

Why Microfrontends?

What advantages does this bring? Well, quite a few.

Remember that time you joined a dev team on an old project and the frontend was still built with XSLT & jQuery? A re-write was not even considered and you had to use those old technologies to add new features and fix bugs.

Even if you could convince the stakeholders to do a re-write, and you have a new codebase for 1-3 years. What makes you think in 10 years it won't be perceived as XSLT & jQuery are today?

Microfrontends promise:

smaller, more maintainable codebases
each microfrontend can be written with different technologies - this removes as much as possible external dependencies
each microfrontend can be handled by a different team - reduce cross-team dependencies
we can update/upgrade or delete microfrontends whenever we think it is needed

As a business a commitment needs to be taken - we will constantly be replacing old micro/services/frontends with new ones. So we will continuously evolve our codebases.

Example:
We could delete an old framewok.X.js microfrontend and completely swap it with the new one written in framewok.Y.js. This reduces the risk of an entire app rewrite.

Different approaches

There are different approaches to build microfrontends.

Option 1 - One microfrontend for each microservice 🤖

This option is fine when the microservices architecture is based on features. We can have a feature microservice - for example for checkout, then we also build a checkout microfrontend. The advantage here is that each microfrontend needs to know exactly about one single backend API.

Option 2 - Web components 🌟

Those days, a lot of UI frameworks provide support for web components (Svelte being pretty good in this area).

We can have a legacy UI and constantly swapping old code with new Web components. Each new web component can be a microfrontend written in Svelte, Vue, vanilla JS, or whatever you prefer.

The code for each web component can be hosted on a different server, so individual deployment can be done easily without affecting the rest of the system.

Option 3 - using a Microfrontend tool 🛠️

You can use a tool like single-spa to achieve the wire up of different microfrontends.

This approach fits best for building new microfrontend applications. If you decide to use single-spa make sure you read thoroughly their docs and look at their recommendations.

Option 4 - Module federation ⚙️

This is a Webpack 5 feature that achieves:

Multiple separate builds should form a single application. These separate builds should not have dependencies between each other, so they can be developed and deployed individually. (webpack)

As Webpack Module Federation seems quite stable, this option looks the most exciting at least for projects that use Webpack. Module federation allows for modules sharing so things like loading the same version of React or Angular twice can be avoided with proper config.

Note: you can also combine those options to achieve the architecture that you need. For example, you can use single-spa with module federation.

Can I afford microfrontends?

Microfrontends are certainly not for every use case.

Micro/frontends/services tackle the problem of software rewrite and software scalability. Independent deployments are also very important for micro/frontends/services.

It also relies on the fact that the company has a big dev team, so in this case, it's much easier if not all devs work on a single codebase, stepping on each other's toes all day. Instead, those devs will be split up in teams, each working on a set of a few or maybe only one micro/frontends/service.

The problems with microfrontends

Obviously, there is nothing without a set of disadvantages, so let's look into what are the drawbacks of microfrontends:

hard to test the entire codebase locally when there are many micro/frontends/service
very strict interfaces need to be designed upfront
more codebases to maintain, upgrade & address security risks
performance cost on the end-user, having to download the applications code for each microfrontend
the communication between microfrontends can get very complex
the infrastructure & deployment will probably get more complex as well

More Resources

Conclusions

I hope this article makes microfrontends and what they represent more clear to you, thank you for reading!

Top resources to learn Angular in 2021

Alexandru-Dan Pop — Sun, 03 Jan 2021 16:51:19 +0000

Angular is a very in-demand framework in 2021, with a similar programming model based on components as React or Vue.

It bakes in other concepts like dependency injection, routing, HTTP client based on observables, 2-way data binding & a strong CLI tooling.

Angular can surely be a strong tool under your belt, so for this reason I will go into how you can quickly learn it and be productive with it.

No one reads the docs

Oh well, I am the first to say that I rarely find everything I need to learn a new tool in the docs. Lots of times I need to read other blog posts, watch some videos, and go through stack overflow for some advanced topics.

But with Angular I managed to learn mostly from their docs.

You can spend a few hours to study the docs, and they will get you started & understanding:

using the CLI
Components
Templates
Directives
Dependency injection
Angular Modules

Once the core concepts are understood, you can proceed with building some sample applications.

Sample applications

The Angular website will teach you this too.
You can check out how to build:

Another small app you can start building is a Currency Converter, and you can follow this tutorial:

Coding styles guide

The nicest thing in Angular is that being an opinionated framework - it has best practices and the coding styles are documented.

I think it's nice for once to work with a framework with opinionated:

naming conventions
folder structure
modules structure
and much more

This leaves teams with more time to build and less time to dispute those topics.

How to set up Angular projects

There are two main ways to setup Angular projects:

Angular CLI
Nx

The Angular CLI is more than capable of generating the boilerplate of Angular applications. You can also have multiple projects or apps in it using the Angular Workspaces.

With Nx you will get more of a monorepo experience, and it will configure the testing tools for Angular a bit differently - using Jest and Cypress instead of Karma and Jasmine. Linting, code formatting, and some other nice things are also configured when using Nx.

What other libs should I use

When using Angular, there are a lot of libraries for pretty much anything you need to do in a UI. There are of course very popular UI kits like Angular Material or ng-Bootstrap and many others.

For a comprehensive list of libraries, you can further explore here.

I want to learn more

There are many resources out there to learn Angular, but I can only recommend the ones that I looked at. If you can afford Pluralsight (or you can also look at their free trial option) - you can check out their Angular courses - there are plenty of them. Would start with:

Conclusions

Angular is a powerful framework, that many companies use especially in the enterprise space, and can be very beneficial to learn.

Thanks for reading and hope this content helps you get started with Angular! 🥳

What resources did you use to learn Angular?

If you like this article chances are you will also enjoy what I post on Twitter.

Configuring Next.js with Typescript, Tailwind CSS, ESLint, and Jest

Alexandru-Dan Pop — Sat, 05 Dec 2020 13:28:51 +0000

Next.js might be the best way to set up a new React project in 2020 & 2021. I don't even know if it's worth to appraise it even more, but yeah the Next.js team did a great job!

It just stands out with all the needed features to build bulletproof web applications: hybrid approach with SSR, SSG, ISR, hosting can be done on the Vercel platform on a serverless runtime. Static assets are where they belong, hosted in a CDN edge network for fast delivery. 🏃🏃🏃

So let's configure Next with our favorite tools: Typescript & Tailwind CSS, and we'll use ESLint for lining and Jest to write tests.

Setup Next.js with TS

Go to a terminal and run (replace next-ts-tailwind with your desired app name):

npx create-next-app next-ts-tailwind
cd next-ts-tailwind
Create a tsconfig.json file: touch tsconfig.json

{
    "compilerOptions": {
      "allowJs": true,
      "alwaysStrict": true,
      "esModuleInterop": true,
      "forceConsistentCasingInFileNames": true,
      "isolatedModules": true,
      "jsx": "preserve",
      "lib": ["dom", "ES2020"],
      "module": "esnext",
      "moduleResolution": "node",
      "noEmit": true,
      "noFallthroughCasesInSwitch": true,
      "noUnusedLocals": true,
      "noUnusedParameters": true,
      "resolveJsonModule": true,
      "skipLibCheck": true,
      "strict": true,
      "target": "esnext"
    },
    "exclude": ["node_modules"],
    "include": ["**/*.ts", "**/*.tsx"]
  }

Add TS dependencies
yarn add --dev typescript @types/react @types/node
Go to /pages/index.js and change it to index.tsx
Run yarn dev - all good and running on http://localhost:3000/

Setting up Tailwind CSS

The Tailwind team already put together an excellent tutorial to set this up with Next.js, but there are just a few changes needed for it to work with TS files.

yarn add tailwindcss postcss autoprefixer
yarn add tailwindcss@npm:@tailwindcss/postcss7-compat postcss@^7 autoprefixer@^9
npx tailwindcss init -p
Go to tailwind.config.js and change purge: [], with:
purge: ["./components/**/*.{js,ts,jsx,tsx}", "./pages/**/*.{js,ts,jsx,tsx}"],
This makes sure that when we build for production only the classes that we use from the tailwind framework will remain in the final production css file. It's called tree shaking if you need a more fancy term to impress your grandma. 👵
Include tailwind at the top of your ./styles/global.css file

@tailwind base;
@tailwind components;
@tailwind utilities;

Go to your pages/_app.js (that you should rename to _app.tsx) component and make sure it looks like this:

import "../styles/globals.css";
import type { AppProps } from "next/app";

function MyApp({ Component, pageProps }: AppProps) {
  return <Component {...pageProps} />;
}

export default MyApp;

To test tailwind is working go to index.tsx and change it to:

import Head from "next/head";
import styles from "../styles/Home.module.css";

export default function Home() {
  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App</title>
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <div
        className="bg-yellow-100 border-l-4 border-yellow-500 text-yellow-700 p-4"
        role="alert"
      >
        <p className="font-bold">Be Warned</p>
        <p>You are using Tailwind CSS!</p>
      </div>
    </div>
  );
}

Running the app with yarn dev you should see:

Setting up ESLint

yarn add --dev eslint
Run npx eslint --init and answer with the following:

Go to package.json and in the scripts section, add:
"lint": "eslint ."

Now, if you try yarn lint, you will see a bunch of errors. Go to eslintrc.json and modify it to:

{
    "env": {
        "browser": true,
        "es2021": true,
        "node": true,
        "jest": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
        "plugin:@typescript-eslint/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "settings": {
        "react": {
            "version": "detect"   // Automatically detect the react version
        }
    },
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": [
        "react",
        "@typescript-eslint"
    ],
    "rules": {
        "react/react-in-jsx-scope": "off",
        "@typescript-eslint/explicit-module-boundary-types": "off"
    }
}

Note that I also disabled the explicit-module-boundary-types because I like TS to do its job and infer the return types for me, but you can remove that if you like to always add return types to your functions. There will be other lint warnings that you will probably not like and turn off, that's totally fine.

Running yarn lint now should result in no warnings and errors.

Note that you should probably use the ESLint VSCode extension if you use VSCode. This way you can see errors and fix them as they pop-up while you code.

Adding Jest

yarn add --dev babel-jest jest @types/jest @types/babel-generator
in package.json scripts section - add "test": "jest --watch"
create a .babelrc file in the root and add in it:

{
    "presets": ["next/babel"]
}

Create a jest.config.js with:

module.exports = {
  setupFilesAfterEnv: ["<rootDir>/jest.setup.ts"],
  testPathIgnorePatterns: ["<rootDir>/.next/", "<rootDir>/node_modules/"],
};

And a jest.setup.ts with:

import "@testing-library/jest-dom";

Next, let's add the React testing packages:

yarn add --dev @testing-library/react @testing-library/dom @testing-library/jest-dom @testing-library/user-event

Create in the components folder a file SomeComp.test.tsx with:

import { render } from "@testing-library/react";

function SomeComp() {
  return <div>Hello</div>;
}

describe("SomeComp", () => {
  it("renders Hello", () => {
    const { getByText } = render(<SomeComp />);
    expect(getByText("Hello")).toBeInTheDocument();
  });
});

Run yarn test:
PASS components/SomeComp.test.tsx
SomeComp
√ renders Hello (24 ms)

Conclusions

If you got this far congrats - you have a Next.js app configured with TS, Tailwind CSS, ESLint, and the testing is set up with Jest and RTL. 🥳

If you got stuck or prefer to see the working solution directly you can check it out on Github.

I post more cool content on Twitter 🔥🔥.

FE Jargon you should know - SSG, SSR, CSR, VDOM

Alexandru-Dan Pop — Fri, 27 Nov 2020 11:16:08 +0000

If you have heard lately talks about SSG, SSR, CSR, VDOM - and you were like:

What the heck is that? 🤔

Then this article is for you and aims to be a mini dictionary for modern frontend terminology and jargon.

Please leave a 🧡 & 🦄 if you enjoy this article & follow me on Twitter where I post more cool content.

CSR

Client side rendering

The general way of building frontend applications those days is writing them using libraries like React, Angular, Vue, or Svelte and then building them in a javascript bundle. This bundle is referenced in our single HTML file. CSR (client-side rendering) is rendering our markup in the browser. If that sounds complicated, look at the image below:

This image represents two stages:

Dotted gray line represents the deployment of our FE code to a server. As you can see the deploy step generates an HTML file and a bundle.js file.
Dashed green line represents how a browser gets to paint our app:
1. Browser - STEP 1 - The browser requests the HTML file
2. Browser - STEP 2 - The browser requests the JS file
3. Browser - STEP 3 - Perform Client-side rendering (CSR)

✅ As an advantage - CSR is the most straight-forward way to build a SPA (single page app). So it's the easiest and fastest way for developers.

❗ The main disadvantage of this approach is that after Step 1, we cannot show anything to the user. We need to wait until JS is downloaded, parsed & executed (Step 3), and only then our users can see the app.

SSG

Static site generation - this is when you are pre-rendering a website with a framework or library that is producing static HTML pages.

For example, you could be writing a React application, but you want its output to be static HTML pages. This might be because you enjoy React, but you also want the performance of pre-rendered content. Something like a blog, a presentation website, or an e-shop.

If the content doesn't change often, it makes sense to render at build time, instead of loading all the javascript in the browser and only then building the HTML that the user will interact with.

Comparing to CSR -> you can see we have lots of HTML files resulting from our build step. We also have HTML available to render in the browser in Step 2.

Additionally, SSG sites can be hydrated after the initial page is loaded.

Ok, if that sounded weird, that just means after the initial HTML page is loaded, it can also load the CSR library so when the user navigates to the next page, it happens instantly, rendered on the client, without other network calls.

✅ SSG sites will create the most performant web apps provided the hosting is also good.

❗ Content needs to be fetched always at build time. This means we need to build & deploy every time the content changes. This is not feasible for highly dynamic content.

SSR

Server-side rendering
Server-side rendering is a pretty old technique. Any application that renders HTML on the server can be called an SSR app.

But this looks like the SSG pic...

Hmm.. kind of, but here you can see we actually don't treat our server just like a dumb provider of static content, instead we are actually doing something useful with it. We are generating the HTML every time our user needs it. This is slower than SSG because the server needs to compute the HTML.

The generic code that runs on a server in this picture could be a Node.js Express App or Ruby or Python. The thing that we achieve with this approach is the dynamic control of our content, headers & meta tags (that can serve for SEO). And a plus can also be the performance. We don't stress our app consumers downloading a bunch of JS and only then rendering HTML (CSR), we give it straight away. The caveat is that we need to account for the fact that our server needs to be performant doing the generation & also support the load we throw at it.

✅ SSR sites provide us the most flexibility in terms of what we want to display to users despite fast content changes & how we optimize our response headers & meta tags for SEO.

❗ Extra complexity due to the server-side code & we need to scale our server in case we receive more load. SSR and SSG don't have this problem, they can be thrown on a good CDN and that just scales to any load.

SSR, SSG, CSR - can be combined.

Modern frameworks like Next.js (for React) or NuxtJS (for Vue) allow us to write applications that can serve multiple purposes and we can combine those techniques with it.

VDOM

Virtual DOM
The Virtual DOM is an in-memory representation of our UI elements. Frameworks like React, Angular & Vue use a Virtual DOM to not paint in the real DOM the same thing multiple times. Because the real Browser DOM is slow to paint things, those frameworks use a VDOM as an optimization to keep track and only re-paint the things that are necessary.

The next post will be more about:

Micro-frontends
Building & bundling related topics - CodeSplitting, Transpiling, Tree shaking

For React specific things to know - I wrote about it in-depth in my other article.

For a description of more general concepts - you should also read the very nice Web Nerd Terminology blog post on CSS tricks.

Conclusions

Hope those explanations help - please leave a 🧡 & 🦄 to support the effort of creating this article. More cool content on Twitter 🔥🔥.

👇 Comment below 👇

Do you use SSR, SSG, CSR, or all of them?

React.js - Top things to know

Alexandru-Dan Pop — Sun, 08 Nov 2020 18:26:08 +0000

React is eating up the web development world - being the defacto library for modern user interfaces, so learning it can bring many advantages.

In this article, you will be introduced to all things you need to know in order to be a successful React dev. This is not meant to be an in-depth tutorial, but instead an introduction to all needed concepts. You will find extra resources linked here, that can help you get in-depth knowledge of certain topics.

Before starting

It is often advised to get HTML, CSS, and JS experience before starting to build applications with a framework like React. So it is best if you study those, before reading this article. Also, would help a lot if you leave a 🧡 & 🦄 if you enjoy this article.

Let's get started!

Modern JS features

spread syntax
class syntax
arrow functions
template strings
async/await
ES modules

Modern JS development environment

The target environment for React code is browsers (most of the time, we can also write mobile apps or render apps on the server). Since browsers can't understand all the latest JS features that I just mentioned earlier - we need a bundler and a code compiler - more info ahead. We also need a package manager for downloading all the libraries we want to use - including React, React-DOM, Router, etc.

Note you don't need to understand those very in-depth if you are just starting out, but it makes sense that you have an idea about each of them

Node.js - our development environment is a Node.js environment. Our tools - like Webpack or Babel, or Create React App - are Node.js programs. We use Node.js to start our dev environment, build for production, run tests etc.
npm (or yarn) - package management - use to install everything we need in our dev environment (React, Router, Babel, Webpack, etc)
ESLint - watch our code for common programming errors or bad practices - a good linter config will save you of many coding errors and bugs. A lint config will throw errors or warnings when you do something that breaks lint rules (ex not using React hooks correctly)
Babel compiler - converts modern JS to code that browsers can understand
Webpack - takes all our code modules (all our files and dependencies) - and spits out a single (or multiple) JS files the browser can understand. We can use different plugins in Webpack to achieve different things (minify the code, bundle and optimize CSS, etc)

Structure your UIs into reusable components

The most important thing in React development is the concept of components. We will have lots of components that compose our UI. Here is a simple example of the Dev.to interface broken down into components:

Larger chunks of the UI will be composed of many smaller pieces. I didn't break down all the pieces from the LeftPane for example. You can look at it and imagine it contains an Avatar component, that also contains a Picture, Header & Text components. Below is a side navigation component, and so on.

Learn to use React Hooks

React hooks are the modern way of writing React applications. There are a few hooks that you will need in all React applications:

useState or useReducer
useEffect - make sure you understand this one as it's not trivial at first

Routing

Unless you are building some very small app, you will realize you need to render multiple pages in your app. That's when routing comes in.

Routing works by rendering a specific set of React components under a route:

'/' - render HomePage component
'/about' - render AboutPage component

Routing can become more complex when we accept in our routes:

URI parameters Ex: /employee/{employeeID}
Query parameters Ex: /employee?{employeeID=1}

Learn ways to manage global state

Global or application level state is a piece of data that is necessary to be stored globally so it's accessible to multiple components.

Some examples of global state:

who is the currently logged in user and what are her/his rights
the currently selected theme
the currently selected language/locale

Learn about:

Context Api + useReducer hook
Redux

Generally, you should avoid global state as much as possible, and prefer using local component state.

Why React projects still use Redux

Alexandru-Dan Pop ・ Aug 8 '20

Interacting with HTTP services

Now that we know how to split UIs into components, do routing and state management, the next step is managing to get data from APIs in our application.

A basic understanding of HTTP and Web APIs is important. You will interact with APIs using the fetch API or using a library like axios, so please learn how to use one of those two.

I wrote about popular Web APIs and how to interact with HTTP APIs:

Popular web APIs you should know about

Alexandru-Dan Pop ・ Jul 22 '20

#webdev #api #productivity #machinelearning

Correctly handling async/await in React components

Alexandru-Dan Pop ・ Apr 5 '20

Component libraries

You probably don't always want to build all the components for a complex UI from scratch - so it's useful to know about pre-build component libraries. Using those can speed up development as you don't need to code basic UI components like buttons, dropdowns, tables, etc from scratch.

Material UI
Reactstrap
Semantic UI
Chakra
Ant Design

You definitely don't need to be familiar with all of them - just know they are there, and you can reach them when you need them.

You are all set!

Alright! If you made it until this point, gathered info about all the previous topics, and got an understanding of each of them - you are all good!

Next, we will talk more about some more advanced stuff that are also very interesting for React devs.

Advanced - React toolchains when and why?

In the post above I address when you should use react toolchains like Create React App, or Next.js, or Gatsby.

This is interesting when you can actually make those decisions, or help others make those decisions because picking the correct one of those three will be crucial to the success of your project:

When to pick Gatsby, Next.Js or Create React App

Alexandru-Dan Pop ・ Jul 13 '20

Advanced - Deployment models

Since in most cases our react apps production build will result in static assets, we can deploy using:

A CDN
A web server
Containers

When to choose one or the other might depend on different factors.

Advanced - Typescript

Typescript is becoming more and more popular in the React ecosystem. I wrote an article around it:

The React Typescript path - 2020

Alexandru-Dan Pop ・ Sep 10 '20

#react #typescript #javascript

Advanced - React patterns

Using patterns can make our code more modular, easier to extend and reason about, but also more testable.

Some of them are:

Headless Components are probably the most popular pattern right now, as it's really nice to write the business logic of our apps in custom hooks, leaving our component code clean.

Advanced - Testing

Testing is a big thing when it comes to building resilient UI applications. If we use all those nice tools to build apps that can be modularized in independent components - why not also make sure those modules/components will always work as we intend them to?

You will need to know:

Basics of Jest
How to use - React testing library
How to use Cypress

You can use this free course to learn using Jest & React testing library to test React apps.

Advanced - styling approaches

As with many other things in the React ecosystem, styling has its flavors - and can be kept as simple as using a normal CSS stylesheet or using more complex approaches like CSS in JS.

Styling can be:

CSS
Inline
CSS modules
SASS (modules)
CSS in JS
Atomic CSS (TailwindCSS - for example)

Different applications will have different styling needs. If all styles are from scratch - something like CSS in JS or Atomic CSS might make the most sense.

Some applications might require minimal custom styling as they are built on top of a CSS framework like Bootstrap 4 or Material UI. In that case, CSS modules or SASS might be your choice.

Conclusions

Learning React & working with the Web is a never-ending journey, so keep learning, keep exploring!

// Detect dark theme var iframe = document.getElementById('tweet-1325402636389113856-186'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1325402636389113856&theme=dark" }

Leave a 🧡 & 🦄 if you like this article, also check out my Twitter where I post more cool content.

👇 Comment below 👇
Did I miss anything? What are the top things to know from the React world today?

Modern Windows 10 development setup

Alexandru-Dan Pop — Sun, 25 Oct 2020 17:26:22 +0000

Windows is the most popular desktop & laptop OS, love it or hate it, lots of programmers run this OS.

The reasons may be various, but I like to think that many use it because it just works very well for a lot of stuff - including programming.

Ok, another reason that matters to many. For some time Mac computers didn't have a real competitor design-wise. I think now, they do.

I mean just take a look at the new 2020 Dell XPS 13 - that thing is gorgeous.

While I don't want to raise a battle on Windows vs Linux vs Mac, I want to state that I've tried all 3, and I like them all for what they do best. Windows is a very good all-around operating system that also has its quirks, so I want to share what you can do to make your developer experience as good as possible on this OS.

Chocolatey 🍫 or Winget

The Package Manager for Windows - this tool, once installed, can do things like:
choco install nodejs
choco install vscode
choco install firefox

Amazing right? You can have a script with everything you need to install on a new machine - making the setup process really easy. Also - they have a cool website where you can search packages and see what other nice things choco does (besides getting some nice dopamine in your brain).

As of 2023, it's probably better to use winget instead of choco, check it out here and read more about it on learn.microsoft.com.

Alternatively, you could also check out Scoop.

Cmder 💻

Cmder is a console emulator - allowing you to have a multi-tab console for Windows - supporting cmd, Powershell & bash. It has lots of customization features - like choosing a background, the font-size, aliases, and other nice features. Also has good keyboard shortcuts out of the box.

By the way, you can also map your VS Code terminal to be Cmder.

Some alternatives:

I'd say give all a shot and pick the one you like the most.

Wox 🔎

Wox - I really enjoy using this tool as a Spotlight alternative for Windows. Need to quickly find an app, run something from a command line, calculate something, or search something on google? Wox can do all those things for you - FAST!

Code editors

Take your pick, the best of the best run on Windows of course:

VSCode
Webstorm
Atom
Sublime text

Develop as on a Linux box with WSL2 🐧

Of course, spinning up a Linux VM is pretty easy on Windows with Hyper-V, but why bother when you can get this natively? You just need to turn on WSL from the Windows features section, and then you can code using Linux-first languages like Ruby or Python in the environment they were designed to run.

A gotcha when running things in WSL2 is using /mnt/c that will make your dev experience really slow. You should not use the Windows drives for WSL2 development, but the actual WSL2 drive, for example:
/home/{username}/projects

Extra steps to make the OS faster

Uninstall any bloatware
Prevent Windows Security dev folders scanning (if you are sure you are using only trusted secure software - beware that some hacked npm packages have exploited Windows machines in the past)
Turn off Windows search indexing - since you are using Wox, you don't need it

Conclusions

Do you need a Mac to code?

Absolutely not. Unless you are doing some OSX/iOS development, you definitely don't need a Mac. Pretty much everything you can do on a Mac is possible on a Windows PC as well.

Leave a 🧡 & 🦄 if you like this article, also check out my Twitter where I post more cool content.

Working with .Net Core & React - what I've learned

Alexandru-Dan Pop — Fri, 09 Oct 2020 11:27:13 +0000

I have been using both of those 2 awesome technologies for some time. From the point I started using React, I had a slow migration to the JS ecosystem and started to do more frontend work and less backend work using .Net.

Lots of folks like ASP.NET Core. 🌟

see the 2020 stack overflow dev survey

In this article, I don't compare them - just telling a few my personal impressions of both ecosystems.

It's mostly about what I like or dislike about both the ecosystems & their tooling. 👀

Why those two?

Both React and .Net Core are baked up by tech giants. 🗿
This makes picking those technologies easy for decision-makers.

The React ecosystem

React is the dominant go-to solution when it comes to building web applications.

Some advantages:

the ecosystem is huge and more vibrant
great tools are free - ESlint, Prettier, Typescript, HMR (hot module replacement) - the JS community really has the lead when it comes to DX
Monorepo tools // Detect dark theme var iframe = document.getElementById('tweet-1299752196356136962-277'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1299752196356136962&theme=dark" }
An inclination towards FP (functional programming) instead of OOP (object-oriented programming)
Some advantages are due to working with JS - like the ease of using JSON data and doing object manipulations
More and more traction to Typescript in the last few years - I think this is a great quality boost for the ecosystem

Some disadvantages:

things get deprecated (see examples below)
using TS doesn't give that seamless typed language experience (yet) as C# does. TS has escape hatches that can make TS code weekly typed (this can be also a benefit for some people)
Things move much faster - and it's harder to stay up to date
Standards are still missing in the React ecosystem. This is a good and a bad thing because each project will look very different - from folder structure to the way components are written, to what CSS technology is used in the project. This is somehow nice because it leaves a lot of room for new innovation, but still, it feels like some standards are missing

Examples of deprecation in the React world:

You learned React class components years ago and became an expert using them and all the lifecycle methods and all the class-based patterns. Well...bad luck, React function components with hooks are the new standard (don't get me wrong I absolutely love hooks ❤️).
If you learned unit testing React components 5 years ago you might have learned Enzyme. At least from let's say 2019 (when also hooks were released), Enzyme is not encouraged to be used in React projects anymore. React Testing Library is the new standard, which has a totally different approach and different testing concepts (that are better). To put this in contrast - if you used .Net and learned to unit test your code with xUnit and Moq, maybe 5 years ago, you would still use those and be encouraged to do so
You learned some complex state management solution and now there are talks in the community that you should not use it anymore - but maybe you should 😉

Why React projects still use Redux

Alexandru-Dan Pop ・ Aug 8 '20

Examples of missing standards in the JS world:
Just to give some context - there are 3 popular bundlers / build tools (webpack, parcel, rollup). There are more than 4 popular Rendering libraries (React, Vue, Svelte, Angular). There are at least 10 different ways of doing data fetching in React (with redux using your own middleware, sagas, thunks, redux-observable, useEffect, RxJs, react-query, swr, etc)

.Net core

A more mature community who figured out doing things in certain ways.
Now the .Net core ecosystem is obviously not as popular as the React ecosystem. When it comes to server-side applications or API's there is no clear winner, but we can certainly say .Net Core is one of the trending top picks in the world of APIs & backends.

Some advantages:

A more consistent way of building server-side apps
More stability - the best practices you learn today will probably be also around 5 years from now
Both C# & F# are excellent languages that evolve a lot over time
It's just great for building Web APIs, background services, etc
Microsoft owns .NET, so you will get a pretty nice experience using .Net/.Net Core on other platforms they own - Azure, Azure Devops, Github

Some disadvantages:

Lacks the advanced OSS tooling in the JS world - for more advanced linting, refactoring tools, code formatting you need to pay (ex for Resharper or Rider)
Lacks monorepo tools (at least I don't know any)
The community is not so vibrant. And a lot of folks are not so open to sharing things. This ecosystem would have great success if people would be more open and share things more

Is it worth knowing both?

Yes! While a lot of new people join programming and try to learn React or some other Javascript framework first, I would actually encourage them to learn a pure backend language first.

Why? It helps focus on pure coding and avoids learning at first all the complexities of the Web.

Aside from this, it's an incredible stack to master, as .Net Core offers a consistent way to build complex backends, and React helps you build complex interactive user interfaces.

Leave a 🧡 & 🦄 if you like this article, also check out my Twitter where I post more cool content.

👇 Comment below 👇

Let me know what you think about the .Net Core & React combo.

Is it worth learning C# with .Net Core or should we just use Node.js server-side and use the same language everywhere?

What if you could change one thing about your career

Alexandru-Dan Pop — Fri, 02 Oct 2020 18:01:16 +0000

Hello, fellow devs 👋, if you could change one thing about your dev career so far, or could improve one thing from it, what would it be?

DEV Community: Alexandru-Dan Pop

Releasing features with confidence as a software developer

Table Of Contents

Automated tests and CI/CD pipelines

Unit Tests

CI/CD Pipelines

Feature Flags and A/B Tests

Feature Flags

A/B Tests

Conclusion

Ubuntu 20.04 - how to make it perfect for development & productivity

MacOS BigSur theme

Configure Dash to dock

Install Albert

Install Tilix terminal

Brave browser

Dev & productivity tools

The M1 Mac - Is it worth it for devs?

Alexandru-Dan Pop ・ Mar 1 '21

Make it faster

Conclusions

The M1 Mac - Is it worth it for devs?

Why I choose the M1 Mac Mini with 16GB RAM

Impressions

Caveats

Things to consider

Personal conclusions

Modern Windows 10 development setup

Alexandru-Dan Pop ・ Oct 25 '20

Ubuntu 20.04 - how to make it perfect for development & productivity

Alexandru-Dan Pop ・ Apr 5 '21

Creating a Calculator app with React and TDD

Setup

Let's start coding

Render rows of numbers

Show calculator operators

Show an equal sign & clear sign:

Show an input for values to be calculated

Make it display the user's inputs

Can it calculate?

Can use clear button

Back to calculating stuff

Watercooler 🌊

Get rid of eval

Style the app

Conclusions

Microfrontends explained

What are Microfrontends?

Why Microfrontends?

Different approaches

Option 1 - One microfrontend for each microservice 🤖

Option 2 - Web components 🌟

Option 3 - using a Microfrontend tool 🛠️

Option 4 - Module federation ⚙️

Can I afford microfrontends?

The problems with microfrontends

More Resources

Conclusions

Top resources to learn Angular in 2021

No one reads the docs

Sample applications

Coding styles guide

How to set up Angular projects

What other libs should I use

I want to learn more

Conclusions

Configuring Next.js with Typescript, Tailwind CSS, ESLint, and Jest

Setup Next.js with TS

Setting up Tailwind CSS

Setting up ESLint

Adding Jest

Conclusions

FE Jargon you should know - SSG, SSR, CSR, VDOM

CSR

This image represents two stages:

SSG

SSR

But this looks like the SSG pic...

VDOM

Next article