DEV Community: Nikita Borisov

What should Frontend Developer really know?

Nikita Borisov — Sun, 06 Apr 2025 11:20:02 +0000

I've been working on many different projects as a tech leader. At some projects we were hiring people, and during interview I was realizing that actually majority of devs don't have fundamental understanding of basic concepts. By understanding I don't mean learning them by heart. I mean understanding why things work the way they do. For example, why do we have to use binary in programming? Or what is a computer? How can you build a software for a computer if you don't know what a computer is?

This article is not a complete overview of the whole frontend knowledge map. Instead, I will try to show things from a different angle: how to apply systems approach and generic research techniques to learn anything. I hope this will boost you somehow. Let's start.

What is the goal of Software?

Let's break it down: hardware and software.
Hardware is a physical device. Hardware can be programmed though. Initially, all the programming was done on hardware.

This led to a problem of slow iterations. If you want to change something in hardware, you have to replace or patch the hardware. It was complicated and expensive.

Later people came up with software. Basically ability to build and deliver program to a hardware. The hardware would still have some firmware, but in this case it was more generic and flexible.

C language was the revolution, because it allowed to give very high level of abstraction and to write code that is very close to the hardware. It's funny that nowadays C is considered low level language.

For the last 80 years people have been working on improving development process to reduce time from idea to the production and to improve quality.

What is backend

First programming was used in military and government. Later it came to business as well. Backend developers at that time were developing programs to support business processes like accounting, manufacturing.

I won't cover this in details, but keep in mind, that backend is something that is running required business processes, using tools like database, messaging systems, cron jobs, in-memory databases.

What is Frontend anyway

First programs were just simple terminal applications that would take input from the user, do some calculations and would display some output.

However, to optimize more complex processes terminal was not enough. Therefore, GUIs were invented — Graphical User Interfaces. They would allow to interact with the software in a more natural way. Basically documents and blank forms were displayed on the screen using some code.

The reason to separate Frontend development from Backend was because the context of the problems was too different. In backend you deal with distributed systems, databases, networks, uptime.
In frontend you deal with UI/UX, different devices, different screen sizes, different browsers, and many niche specific problems.

What you need to know

First, consider key components. They are:

Computer
- CPU
- GPU
- RAM
- Display
- SSD
- Data bus
- Power supply
- Keyboard
- Mouse
- Other input devices
Backend
- Servers
- Databases
- APIs
- Network
Users
UI/UX designers
Backend developers
Product managers
QA engineers
DevOps engineers

You need to understand this pipeline

User types in the browser address bar https://your-application.com
Browser parses the URL to identify protocol (HTTPS), domain, and path
Browser checks its cache to see if the DNS resolution is already available
If not cached, browser initiates DNS lookup through the operating system's resolver
OS resolver checks its local hosts file and DNS cache
OS resolver sends a DNS query to the configured DNS server
DNS server returns the IP address of the nearest CDN edge server
Browser initiates TCP connection to the CDN edge server IP on port 443 (for HTTPS)
TCP three-way handshake occurs (SYN, SYN-ACK, ACK)
Browser and CDN server perform TLS handshake to establish encrypted connection
Client sends "Client Hello" with supported cipher suites
CDN server responds with "Server Hello", certificate, and selected cipher
Keys are exchanged and encryption is established
Browser prepares HTTP request headers (User-Agent, Accept, Cookie, etc.)
Browser sends the HTTP GET request to the CDN server through the encrypted connection
CDN edge server receives the request and checks its cache for the requested content
CDN server retrieves the cached static files (HTML, CSS, JS) without backend processing
CDN server prepares response headers (Content-Type, Content-Length, caching directives)
CDN server sends the HTTP response with status code and HTML content
Browser receives the response and begins processing it based on Content-Type
Browser validates the response (status codes, security headers)
Browser begins parsing the HTML document, creating tokens for each tag, attribute, and text
Browser constructs the DOM (Document Object Model) tree from these tokens
Browser discovers and prioritizes resource requests (CSS, JavaScript, images)
Browser sends requests for critical CSS and blocking JavaScript (also served from CDN)
Browser constructs the CSSOM (CSS Object Model) tree from CSS responses
DOM and CSSOM are combined to create the Render Tree (only visible elements)
JavaScript parser compiles and executes scripts based on async/defer attributes
Browser performs layout/reflow (calculating exact positions and sizes of elements)
Browser creates layers for content that should be independently composited
Browser performs painting (converting render tree to pixels in each layer)
Browser performs compositing (combining layers with proper stacking and blending)
GPU processes the composited framebuffer data
Display controller sends the pixel data to the physical screen at the refresh rate
Browser establishes event listeners for user interactions
UI is continuously updated in response to user interaction, timers, and network events

It's ok if something doesn't look familiar at the moment. You should google it right away. Or check some source code of v8.

You need to understand what people want from you

To understand what people want from you, you need to understand what kind of people there are involved.

In outsourcing companies there is a customer and team of developers. There are also end users that will use the product.

If you are working in a product company, customer is actually stakeholder within a company.

Also depending on type of product, whether is's B2B or B2C, you will also have different considerations, constraints and requirements.

Customers don't know what they want

This is what product team is for. But customers always almost know what they don't want. With proper investigation you will be able to find out what they actually want.

The point of this is to understand core process of customer development:

Define business objectives and success metrics for the product
Stakeholder interviews to understand organizational goals and constraints
Market research to identify trends, competitors, and opportunities
Create user personas based on research data, not assumptions
User interviews with target audience to uncover pain points and needs
Journey mapping to visualize current user workflows and pain points
Job-to-be-done analysis to understand what users are truly trying to accomplish
User flow mapping to determine optimal navigation paths
Wireframing key screens to establish layout hierarchy without visual design
Content strategy development to plan messaging and information hierarchy
Design system updates to establish consistent UI patterns and components
Prototyping at appropriate fidelity level (low to high) based on testing needs
Usability testing with representative users to validate design solutions
Visual design refinement to create aesthetically pleasing, on-brand interfaces
Animation and transition design to enhance user understanding and engagement

You don't have to know how to do all of this yourself. But it's important to see how frontend implementation is related to the design process which is behind the scenes. This way you can see the meaning of what you do.

Do you have team/tech leader?

There is a probability that on your project you will have someone actually responsible for the whole result. Decent team leader will support you, teach you, help you to grow.

Unfortunately, sometimes there are communication issues between devs and team leader. For example, developer delivers the code and team leader checks it on code review and tells that it's looking shitty.

Yes, I think it would be hurtful for anyone to hear that. Especially if you are junior developer, busting your ass 12 hours a day to get things actually done while the team leader is drinking coffee working literally 20 minutes per day.

How to deal with it?

Understand the root of the problem. Be pragmatic, use system thinking. If someone is not satisfied with the result, first thing is you have to understand — why are they not satisfied? Did you both agree on certain criteria? If not, why did you start proceed to task without agreeing? Why did your team leader allow this process to work that way?

If something happens and people are blaming each other — it's a sign that there is a problem with the process. And it's more of a sign where the person responsible doesn't want to admit his mistakes.

Everyone makes mistakes, it's not a big deal. The only important question is — are you learning from them? If you are in an environment where nothing gets done, and mistakes aren't getting fixed — you need to change your environment.

Find problems and act

If you want to grow, it doesn't matter if you are frontend developer, designer or car washer. Your employer wants to live in a better future. If you help them to achieve that, you have a chance of setting up more strategic looking relationship with them.

In terms of Frontend development, here are the most common problems that you can find:

Time to market is not reducing or doesn't even get tracked
No clear definition of done, lack of requirements
Developers can't answer question — why are they doing what they are doing, what is the real value and purpose
margin-top: 15px — 15 is not divisible by 4, and margins are anti-patterns as hell, this is why
No dev and testing workflow defined
Requirements are changing during the work sprint
Backend API is not documented
Backend API is using REST (huge anti-pattern, but people believe that's the standard)

Keep the professionalism

Other people see and remember what you do in public. You have to keep professionalism. See the goal clearly. Make sure everyone is seeing the same goal. If there are conflicts, propose a solution, stand on it, but be respectful.

This is mostly enough to be a good developer. All the rest — you can learn any time. Most of the problems come not from the lack of knowledge, but from missing the right initiative. I hope that you readers see the point. Now since I've finished this article you can go and google all new words I've mentioned.

Good luck!

Making UI Layout: Fast, Pixel Perfect, Without Stress 🚀

Nikita Borisov — Thu, 29 Aug 2024 19:41:53 +0000

Why Read This? 🤔

This article is focused on developers that spend more than 15-30 minutes on coding layout per one screen. Today I'm going to tell you how to properly interact with Figma and write code for your UI layout to make UI 5-10 times faster.
I've worked on projects, where it was taking 4 hours for developers to create simple mobile responsive page, and it would take additionally 2 hours for testing and fixing stuff.
It took me a month to reduce that time to 15 minutes per screen + 15 minutes for testing + mobile responsivity + logic inside services and component interaction about 30 minutes would sum up to about 1 hour per feature ready to go to production.
Therefore, this article is also useful for developers that want to be able to reduce actual costs for business.

Core concepts

At the beginning we will break down every concept that is used and must be very clearly understood before we proceed to actual coding of the layout. Otherwise we're going to be randomly guessing what is going on which is no good.

Domain modeling

At this stage you don't need to be an expert and be able to define bounded contexts and entities lifecycle, no. However, you should be able to distinct what is entity and what is value object in order to be able to breakdown your layout into reusable components properly.
Understanding domain model helps you to distinct your UI components: what should be generic and what should be domain specific.

System analysis

You should have basic understanding what is user story, use-case, test case and so on. Basically because when developer is given a task to develop some feature for end user, it's important to be able to handle all the possible scenarios where something went unexpected and implement proper layout for it or handle this somehow else. This saves you time later on testing. Actually every early stage analysis mostly saves time later with 10x profit.

Design tools and terms

Design tokens, variant, state, typography, flex layouts, grid layouts, UI kit, design system — these are all important terms you need to learn. Please check this out on internet on your own or send a drop a comment if you want another article with detailed explanation and pictures.
Understanding of very basic linear algebra is also important: there is some coordinate system and some position vectors placed in it.

Simple arithmetics

To make layout you need to be able to divide and multiply values by 16 and 4. Although you will use calculator for these cases, it's important to be able to do it in your head, so that you understand the whole process.

Why 16 and 4: if you want to make layout responsive and scalable, it does make sense to set almost all the sizing's and spacings in rem units. And then you can set value of rem in px units depending on screen size. For example, it can be 16px for small mobile screen, 18px for bigger mobile screen, 20px for tablet screen, 22px for desktop and 24px for wider screens.

So the base of the document is rem is usually set to 16px. And if you use TailwindCSS, which is very convenient to implement atomic CSS approach in your project, they use 1 unit for 0.25 rem which is 4px which is 1/4 of rem. That's why when you need to set block width for example 40px you write w-10 because 40px / 4 = 10 tailwind css units, also 40 / 16 = 2.5rem.

Very simple, but very powerful thing, now it's easy to distinguish all the spacings and not to set weird values like padding-right: 39px; padding-top: 27px

Figma and its auto layouts

You must know how to use figma and how to use it fluently: UI, keyboard shortcuts, X and Y coordinates, navigating on left and right sidebars, detecting sizings, typographies, flex layouts, grid layouts.
It is also important to be able to visually comprehend structure of UI mockup in figma and translate it into code.
Remember: web app layout is just a bunch of rows and columns. Rows place content horizontally and columns place content vertically.

If designers in your Figma don't use auto layouts and most of the spacings are not divisible by 4, then mockup is not designed correctly and needs to be fixed. Always make sure both design and frontend development teams respect and follow fundamental concepts.

Getting to practice 💪

First we need to use to set up following things:

1. Get file with proper design mockups for practicing

This particular one seems to be ok to practice basic flex layout:
https://www.figma.com/design/T6yHwOh7iJmmCYqsTK5mDb/Auto-Layout-Projects-(Community)?node-id=4-483&t=2TJLJ1OEpAd8UZqK-4

2. Bootstrap application in your Frontend tech stack

We'll be using Angular for today's article, but you can use any other technologies you want to.

3. Install and set up TailwindCSS

This step differs for different frameworks and is described in the official documentation.

After all of this done, let's proceed to actual making layout.

Break down the design visually 🔍

This is the section we are going to work with. Our goal is to implement this as a layout pixel to pixel.

How to work with it:

First focus out frame you need to work on and then hover it with your cursor. That gives you rough overview of layout structure in this component.

When you look at some design you should visually parse it like shown on the screen:

Now let's define which pieces are reusable components to extract them in our code:

Now before proceeding to making actual layout, let's inspect the typographies used in the design, here is how you can get those:

As you see, there is a list with all typographies. This way you don't need to manually copy and paste over and over.
Actually setting up all the typographies is the first essential step in making every layout: we start from fully atomic entities and then go to complex composed layout components.

Code 👨‍💻

Finally, we are getting to some coding.

Set up typographies as Tailwind components

The design file I picked has huge collection of typographies included in its design system. To simplify this article I will use only 3 of them that present in our component for practicing layout:

Heading/Heading 2 — Rubik font size 24px, line height auto, letter spacing 0, font weight 700
Body/Base — Rubik font size 14px, line height 16px, letter spacing 0, font weight 300
Body/Label — Rubik font size 12px, line height 16px, letter spacing 0, font weight 300
Component/Base — Rubik font size 14px, line height 16px, letter spacing 0, font weight 500

There are many ways to configure typographies. I prefer doing this by adding custom components to tailwind configuration as described in the official documentation.
Here is our tailwind.config.js after adding typographies:

/* eslint-env es6 */
const plugin = require('tailwindcss/plugin');

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.{html,ts}"],
  theme: {
    extend: {},
  },
  plugins: [
    plugin(({ addComponents }) => {
      // Typographies are being added here
      addComponents({
        '.typo-h-2': {
          fontFamily: 'Rubik',
          fontSize: '24px',
          lineHeight: 'auto',
          letterSpacing: '0',
          fontWeight: '700',
        },
        '.typo-body-base': {
          fontFamily: 'Rubik',
          fontSize: '14px',
          lineHeight: '16px',
          letterSpacing: '0',
          fontWeight: '300',
        },
        '.typo-body-label': {
          fontFamily: 'Rubik',
          fontSize: '12px',
          lineHeight: '16px',
          letterSpacing: '0',
          fontWeight: '300',
        },
        '.typo-component-base': {
          fontFamily: 'Rubik',
          fontSize: '14px',
          lineHeight: '16px',
          letterSpacing: '0',
          fontWeight: '500',
        }
      })
    })
  ],
}

We also need to add Rubik font to our app, this can be easily done:

Search for Rubik https://fonts.google.com/?query=rubik
Copy embedded code
Paste it inside the head of your index.html


<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>PixelPerfectTraining</title>
  <base href="/">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="icon" type="image/x-icon" href="favicon.ico">

  <!-- Rubik from Google Fonts goes here -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link href="https://fonts.googleapis.com/css2?family=Rubik:ital,wght@0,300..900;1,300..900&display=swap" rel="stylesheet">
  <!--  -->
</head>
<body>
<app-root></app-root>
</body>
</html>

Prepare atomic UI components

Here we need to prepare these components mentioned before:

icon
button
list item

I will put these components in ui-kit directory for simplicity, since this article is not about directories naming.

Icon

To copy icon from svg you need to find closes proper square container (usually sizes 12x12, 16x16, 18x18, 20x20, 24x24, 32x32)

Then paste it into your icon component


<svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path d="M5.99998 10.78L3.21998 8L2.27332 8.94L5.99998 12.6667L14 4.66667L13.06 3.72667L5.99998 10.78Z" fill="black" />
</svg>

List item

As we see, list item is a flex container with gap 8px (0.5 rem or 2 tw units) contains an icon and text passed from parent container. We can use content projection here to make our layout flexible enough.
Also list item can be disabled, so let's support this state as well. Pass though 20% basically stands for opacity which is 0.2 for disabled item.

import { Component, input } from '@angular/core';
import { IconCheckComponent } from "../icon-check/icon-check.component";
import { NgClass } from "@angular/common";


@Component({
  selector: 'ui-list-item',
  standalone: true,
  imports: [
    IconCheckComponent,
    NgClass
  ],
  templateUrl: './list-item.component.html',
  styleUrl: './list-item.component.css'
})
export class ListItemComponent {
  public disabled = input(false);
}


<div class="flex gap-2" [ngClass]="{ 'opacity-20': disabled() }">
  <ui-icon-check></ui-icon-check>

  <p class="typo-body-base text-black">
    <!-- ng-content is for content projection   -->
    <ng-content></ng-content>
  </p>
</div>

Button

Button is a flex container justified and aligned its content in the center with border and rounded corners. There are multiple types of buttons, but we will support only type Secondary for now.

import { Component, input } from '@angular/core';

export type ButtonType =
  | 'secondary';

@Component({
  selector: 'ui-button',
  standalone: true,
  imports: [],
  templateUrl: './button.component.html',
  styleUrl: './button.component.css'
})
export class ButtonComponent {
  public type = input.required<ButtonType>();
}

@switch (type()) {
@case('secondary') {
<button class="flex w-full justify-center items-center py-3 px-4 rounded-lg border border-[#5A45F2] inset-1">
  <span class="typo-component-base text-black"><ng-content></ng-content></span>
</button>
}
}

Final component layout 🎬

Basically we can complete work on our component just in a few steps. Note that since we are using more analytical approach instead of imperative trying to match the mockup, we haven't even tested our layout in code. Therefore let's make 80% of the job and then test and then make some fixes.
Go back to the step where I broke down layout a bit.Now go to Figma file, check the containers and how they actually lay out within the space.
This is how we can present it in the code:


<div class="flex flex-col gap-4 py-4 px-4 rounded-lg border-2 inset-2 border-[#DAE9EF]">
  <img class="self-center" src="assets/images/pricing-plan/starter.png" alt="Starter plan" />

  <div class="flex flex-col gap-1">
    <span class="typo-body-label text-black">Starter</span>
    <span class="typo-h-2 text-black">Free</span>
    <span class="typo-body-label text-[#5F6974]">per month</span>
  </div>

  <div class="flex flex-col gap-4">
    @for (item of [
    {text: 'Full courses library', disabled: false},
    {text: 'A new daily meditation', disabled: false},
    {text: 'Access to the meditation guru', disabled: false},
    {text: 'Sleep podcasts and exercises', disabled: true},
    {text: 'Mindfulness exercises', disabled: true},
    {text: 'Guided meditations', disabled: true},
    {text: 'Cooking recipes', disabled: true}
    ]; track $index; ) {
    <ui-list-item [disabled]="item.disabled">{{ item.text }}</ui-list-item>
    }
  </div>

  <ui-button type="secondary">Get Started</ui-button>
</div>

This is my result from literally first attempt:

Conclusion 📝

As you see, making pixel perfect layout is not that hard and doesn't take that much time. You just need to follow following rules:

Extract visually repeated pieces into reusable atomic UI components
Present your layout as set of nested rows and columns. Make sure you don't use margins, instead you should use gaps
Make sure designers and developers follow the same guidelines

Homework to practice 📚

If you want to get better at this, try implementing the whole section from the design. Publish your solutions at Github public repository and share in comments if you want to receive feedback and a code review.

Frontend made fully type-safe and without null checks. Part 1

Nikita Borisov — Sun, 11 Aug 2024 16:04:42 +0000

Introduction

I've seen many different approaches for reactivity in frontend applications and developed the ones that are most suitable for implementing features, type safe and without using null checks inside application code. In this article I will give an overview fundamentals of modeling reactive applications and show example on how to implement type safe reactivity in Angular application. However, you can apply this in any framework using the same principles. We will start with very basic system analysis and domain modeling. Then I'll show how to use functional programming, type system and reactivity to implement very basic feature — toggling a light switch. By the end of this article you will understand how to think and what to do in what order in order to write reactive code. In next articles I will guide you through more complex real life user scenarios.

Overview of reactivity (in terms of UI applications)

First we need to understand several terms that we will use later.

Stream

Stream is a sequence of values that we can listen to. When we listen to that sequence, we get new value every time stream produces new value. Basically anything that includes asynchronous operations is a stream.

Examples:

Listening to websocket, where every message coming from server would be a value in a stream and on connection drop it would throw an error. Executing http request, where every response would be a value in a stream and on error it would throw an error.

User actions

Something that user does with UI

Examples:

Click on a button, typing in text field, scrolling.

Command

Command is an action that can be invoked by user. In some cases commands can be invoked automatically by certain system events.

Examples:

Http request submit, sending message to websocket.

Event

Event is a system event. When user invokes a command, some pipeline is triggered, that pipeline emits some events.

Examples:

Http request completed, websocket message received.
Http request failed, websocket disconnected.

State

State is a value that represents the current value of some aggregation.
Everything starts from an initial state. And then it is changed by applying reducer with new events or commands.

Examples:

Http request completed/in progress/failed, websocket connected/disconnected.

Reducer

Reducer reacts to commands and events and produces new state.

Examples:

When http request is executed by user, state will become in progress and when it is completed, state will become completed.

Pipeline (or flow)

Pipeline is a sequence of operations that are executed in order one by one.
Pipelines handle commands invoked by user, execute some side effects and emit events in the system.

Examples:

When http request is executed by user, pipeline will get started that actually triggers http api call and then handles response, catches errors and emits according events.

Finite state machine

Finite state machine is a thing that contains determined set of states and transitions between them. Basically there are rules that machine can transit between states only if certain conditions are met.

Plugin (not related to reactivity)

This relates to composable architecture. Plugins are atomic entities that can handle certain parts of logic in our app. Plugin can be constructed dynamically from config, it accepts commands, emits events and updates its state. You can also think about plugin as an actor. However, there is no need for real actors on frontend, so I prefer term "plugin". Basically every plugin is a composable FSM.

Examples:

Http plugin, it accepts config for request, sends http request when user invokes a command and emits events when response is received or error occurs.

Overview of domain modeling and system analysis

As a developer you need to understand essentials how to express real world entities and rules in your application code. To do that you need to understand essentials of domain modeling and system analysis. Domain modeling is the process of mapping the real world entities and their relationships to some terms that are used in both the communication and the code. System analysis is the process when you research and document what are use-cases of the application, what scenarios can be there, what business rules are, what constraints are. Basically you need to research and to document everything from business goals to feature test cases.

Implementation of reactive architecture using RxJS and Typescript

Let's define essential types. Doing that helps us to break down the whole system and simplify its implementation.
How to express application logic in typescript and what is programming about: our program is basically a set of possible scenarios that can happen in certain conditions. With that in mind we can unify common scenarios like working with data, handling errors, reacting on user actions, integrating with external apis and so on.

To implement proper abstractions let's break down application flow in real world. There are some actions that user can run. There is a UI that handles user actions and sends requests to some system like backend that processes requests and responds back either with success or error. If it's a read operation, then value can be either found or not. Basically that's what 90% of common applications consist of. For sure there are a lot of other things that can happen in the application, but in this article we'll focus only on the most essential scenarios.

Let's start with result types. Result means that some operation completed and it either run successfully or not. We can express that using these types:

// Ok means that operation was successful. In this case we can read value returned
export type Ok<T> = { kind: 'ok'; value: T };
// Failure means that operation failed. In this case we can read error, but can't read value, since there is no value
export type Failure<E> = { kind: 'failure'; error: E };
// Result can be either Ok or Failure
export type Result<T, E = any> = Ok<T> | Failure<E>;
// Bug means that something went wrong, that we didn't really expect.
// But instead of throwing an error, we return special kind of error that wraps bug with any data passed.
// This way we can structure it better in logs and not raise any errors in our application
export type Bug = { kind: 'bug'; data: any };

// These are just some helpers to make code more composable and easier to construct.
// Otherwise we would need to use explicit type casting, because typecsript is not always very smart
// { kind: 'ok', value: 1 } as Ok<number>
export function ok<T>(value: T): Ok<T> {
  return { kind: 'ok', value };
}

export function failure<E>(error: E): Failure<E> {
  return { kind: 'failure', error };
}

export function bug(data: any): Bug {
  return { kind: 'bug', data };
}

If operation reads data from db, then we can suppose that data can present or not. We can define type for case when there is some data for case when there is no data and we can name it accordingly:

// Some means that there is some data
export type Some<T> = { kind: 'some'; value: T };
// None means that there is no data
export type None = { kind: 'none' };
// Option can be either Some or None
// Example:
// const player: Option<Player> = getPlayerFromDb(id)
export type Option<T> = Some<T> | None;

export function some<T>(value: T): Some<T> {
  return { kind: 'some', value };
}

export function none(): None {
  return { kind: 'none' };
}

// Easy to use wrapper
export function option<T>(value: T | undefined): Option<T> {
  if (value === null || value === undefined) {
    return none();
  } else {
    return some(value);
  }
}

Now let's define types for plugins and reactivity. This is going to be a bit more complicated.

We need to generalize what can happen in the system. Basically there are either users who interact with the system, and there is also system itself that produces events reacting on different triggers, such as user actions or other events.


type PluginCommand = {
  kind: string;
};
type PluginEvent = {
  kind: string;
};

// naming those above starting with "Plugin" has a reason: it makes it easier for your IDE to import because words like Command or Event are way more likely to conflict with other libs (Event is included in dom lib).

// This is type that insures proper typing for commands, so that handlers can be implemented very easily
type Handlers<Command extends PluginCommand, Event extends PluginEvent> = {
  [P in Command['kind']]: (
    command: Extract<Command, { kind: P }>,
  ) => Observable<Event>;
};

// If we have some external data sources (listening to external APIs for example), we need to define them explicitly
type ExternalDataSources<T extends string, Event extends PluginEvent> = {
  [P in T]: Observable<Event>;
};
// This is type of the function that will be called in reducer. It is proper typed: it accepts current state and event and returns new state
type PluginReducerFn<State, Event extends PluginEvent> = (
  state: State,
  event: Event,
) => State;

// This ensures that all the types for plugin passed properly and match all the requirements
type PluginConfig<
  Command extends PluginCommand,
  Event extends PluginEvent,
  State,
  InitialValue extends State,
  Reducer extends PluginReducerFn<State, Command | Event>,
  ExternalDataSource extends string = string,
> = {
  handlers: Handlers<Command, Event>;
  reducer: Reducer;
  initialValue: InitialValue;
  externalSources: ExternalDataSources<ExternalDataSource, Event>;
};

Don't be confused if there is not completely everything obvious with these types. They won't be used directly anywhere outside the plugin's code. I'll dedicate another article to typing with Typescript. Now after we have all the utility types we can define plugin that will be used in our system.

Plugin is a thing that can be constructed from a config, it accepts commands, and produces events. We can send a command using send method. There is an event stream that allows us to listen to all system events. We need to subscribe to that event stream to initialize plugin, that's why it's called connect. We can subscribe to current state using state method. State is updated on each reducer call after command or event is received.

export interface AtomicPlugin<
  Command extends PluginCommand,
  Event extends PluginEvent,
  State,
> {
  connect(): Observable<Event>;

  state(): Observable<State>;

  send(command: Command): void;
}

Plugin implementation

// reactive-plugins.ts

export class AtomicPluginInstance<
  Command extends PluginCommand, // possible commands to accept
  Event extends PluginEvent, // possible events to emit
  State, // type of state
  InitialState extends State = State, // concrete type of the intial state
  ExternalSources extends string = string, // list of keys of external sources. For example, 'statusUpdated' | 'onShutdown'
> implements AtomicPlugin<Command, Event, State> // pass generics to the interface in order to ensure proper types in implemented methods `send`, `connect` and `state` 
{

  protected config!: PluginConfig<
    // same boilerplate as above =)
    Command,
    Event,
    State,
    InitialState,
    PluginReducerFn<State, Command | Event>,
    ExternalSources
  >;

  // accepts command from user 
  private command = new Subject<Command>();
  // processes commands and emits events back to the stream 
  private commandHandler!: Observable<Event | never>;
  // emits events from the system
  private events!: Observable<Event>;
  // emits current state
  private stateSource!: Observable<State>;

  constructor(
    // just accepts config from higher level APIs
    private configValue: PluginConfig<
      Command,
      Event,
      State,
      InitialState,
      PluginReducerFn<State, Command | Event>,
      ExternalSources
    >
  ) {
    this.config = configValue;
    this.init();
  }

  // essential interface implementation. Could've been done through abstract base class 
  public connect(): Observable<Event> {
    return this.events;
  }

  public state(): Observable<State> {
    if (!this.stateSource) {
      throw new Error('state source not defined');
    }
    return this.stateSource;
  }

  public send(command: Command): void {
    this.command.next(command);
  }

  public init(): void {
    // Here is how command handler works:
    //  It accepts command from user
    //  Then it gets handler from the config for that command
    //    - If there is no handler, then app is not configured properly, and we throw an error
    //    - If there is handler, then we call it with command, and return Observable of events.
    //   For now we use `mergeMap` here, because we need to make sure that all nested observables would complete if user sends multiple commands. This behavior can be extended later in order to handle different cases like http request canceling. But in this article we won't cover such scenarios.
    this.commandHandler = this.command.pipe(
      mergeMap((command) => {
        const handler = this.config.handlers[command.kind as Command['kind']] as
          | ((command: Command) => Observable<Event>)
          | undefined;

        if (!handler) {
          throw new Error('No handler found');
        }

        return handler(command);
      }),
      share({ connector: () => new ReplaySubject(1) }),
    );

    // here we want to merge received events and external sources into one stream
    const eventSources = merge(
      this.commandHandler,
      ...(Object.values(this.config.externalSources) as Observable<Event>[])
    );

    this.events = eventSources.pipe(
      share({ connector: () => new ReplaySubject(1) })
    );

    // This is our very simple state reducing pipeline
    this.stateSource = merge(this.command, this.events).pipe(
      // `scan` is just continous applying events over an accumulator state 
      scan<Command | Event, State, InitialState>((state, event) => {
        return this.config.reducer(state, event);
      }, this.config.initialValue),
      // `startWith` accepts initial state
      startWith(this.config.initialValue),
      // `shareReplay` means make this observable hot. It will buffer the last emitted value and replay it to new subscribers. 
      // That means that if value was emitted  before, but client subscribed later, it will be replayed to the client from buffer
      shareReplay({ bufferSize: 1, refCount: true })
    );
  }
}

Basically that's it for the core implementation of the plugin. Now let's proceed to actual implementation of our light switch. We will display state from the plugin on the screen:

// light-switch.plugin.ts

import { AtomicPlugin, AtomicPluginInstance } from './reactive-plugins.ts';
import { EMPTY, Observable } from 'rxjs';

// We assume the only action user can do with a switch light is to toggle it
type ToggleCommand = {
  kind: 'toggle';
};

export type LightSwitchCommand = | ToggleCommand;

// There is no real need for switch to return events, we can just subscribe to its state
export type LightSwitchEvent = never;

// Now we can see that light switch can have two states: on and off
type StateOn = {
  kind: 'on';
}

type StateOff = {
  kind: 'off';
}

// // define all possible states of light switch
export type LightSwitchState = StateOn | StateOff;

// Now let's create an implementation of our plugin which is basically simple state machine
// First we pass types to the plugin as generics
export class LightSwitchPlugin implements AtomicPlugin<LightSwitchCommand, LightSwitchEvent, LightSwitchState> {
  private plugin: AtomicPlugin<LightSwitchCommand, LightSwitchEvent, LightSwitchState>;

  constructor() {
    // initialize actual plugin with config
    this.plugin = new AtomicPluginInstance<LightSwitchCommand, LightSwitchEvent, LightSwitchState, StateOff>({
      handlers: {
        toggle: (cmd) => {
          // no need to handle command actually
          // `EMPTY` observable here is like a noop
          return EMPTY;
        }
      },
      reducer: (state, eventOrCommand) => {
        // check what event or command is passed
        switch (eventOrCommand.kind) {
          case 'toggle':
            // check current state
            switch (state.kind) {
              // if state is on and switch is toggled, then its state becomes off
              case 'on':
                return { kind: 'off' };
              // if state is off and switch is toggled, then its state becomes on
              case 'off':
                return { kind: 'on' };
            }
          default:
            throw new Error('Invalid event');
        }
      },
      externalSources: {},
      // switch is off on start
      initialValue: { kind: 'off' }
    });
  }

  // this is the required boilerplate
  public connect(): Observable<LightSwitchEvent> {
    return this.plugin.connect();
  }

  public state(): Observable<LightSwitchState> {
    return this.plugin.state();
  }

  public send(command: LightSwitchCommand): void {
    this.plugin.send(command);
  }

}

Then let's initialize put light switches into our component somewhere. After setting up switches we need to aggregate state from all of them to display it on the screen. We'll combine observable and convert it to a signal.

// app.component.ts

// ...


export class AppComponent {
  private lightSwitches = [
    new LightSwitchPlugin(),
    new LightSwitchPlugin(),
    new LightSwitchPlugin()
  ];

  private lightSwitchesState = toSignal(
    combineLatest(
      this.lightSwitches.map((lightSwitch) => lightSwitch.state())
    )
      .pipe(
        map((states) => states.map((state) => state.kind === 'on')),
        shareReplay({ bufferSize: 1, refCount: true })
      ),
    {
      requireSync: true
    }
  );

  public lightSwitchesWithState = computed(() => this.lightSwitchesState().map((state, index) => ({
    state,
    instance: this.lightSwitches[index]
  })));

  constructor() {

    // here we subscribe to light switches events stream to initialize plugins
    merge(...this.lightSwitches.map((lightSwitch) => lightSwitch.connect())).pipe(
      takeUntilDestroyed()
    ).subscribe();
  }
}

Rendering in template

<!-- app.component.html -->

<div class="grid grid-cols-3 grid-rows-auto gap-4">
  @for (item of lightSwitchesWithState(); track $index) {
    <div class="h-24" (click)="item.instance.send({ kind: 'toggle' })"
         [ngClass]="{ 'bg-yellow': item.state, 'bg-gray': !item.state }"></div>
  }
</div>

Styles

/* styles.css */

.grid {
  display: grid;
}

.grid-cols-3 {
  grid-template-columns: repeat(3, minmax(0, 1fr));
}

.grid-rows-auto {
  grid-template-rows: auto;
}

.gap-4 {
  gap: 1rem;
}

.bg-yellow {
  background-color: yellow;
}

.bg-gray {
  background-color: gray;
}

.h-24 {
  height: 6rem;
}

Summary

In this article we've covered fundamentals how ot break down systems: every operation within the system returns result which is either success or failure. System consists of atomic plugins that accept commands from user, plugins can update their state and emit events.

To build a plugin we need to define commands, events, states, handlers for commands, reducer for state.

In next article we will extend functionality of our light switches by adding some real world scenarios where switch is broken and then being repared.

DEV Community: Nikita Borisov

What should Frontend Developer really know?

What is the goal of Software?

What is backend

What is Frontend anyway

What you need to know

You need to understand this pipeline

You need to understand what people want from you

Customers don't know what they want

Do you have team/tech leader?

How to deal with it?

Find problems and act

Keep the professionalism

Making UI Layout: Fast, Pixel Perfect, Without Stress 🚀

Why Read This? 🤔

Core concepts

Domain modeling

System analysis

Design tools and terms

Simple arithmetics

Figma and its auto layouts

Getting to practice 💪

1. Get file with proper design mockups for practicing

2. Bootstrap application in your Frontend tech stack

3. Install and set up TailwindCSS

Break down the design visually 🔍

How to work with it:

Code 👨‍💻

Set up typographies as Tailwind components

Prepare atomic UI components

Icon

List item

Button

Final component layout 🎬

This is my result from literally first attempt:

Conclusion 📝

Homework to practice 📚

Frontend made fully type-safe and without null checks. Part 1

Introduction

Popular approach and problems with it

Example

Overview of reactivity (in terms of UI applications)

Stream

Examples:

User actions

Examples:

Command

Examples:

Event

Examples:

State

Examples:

Reducer

Examples:

Pipeline (or flow)

Examples:

Finite state machine

Plugin (not related to reactivity)

Examples:

Overview of domain modeling and system analysis

Implementation of reactive architecture using RxJS and Typescript

Plugin implementation

Rendering in template

Styles

Summary