DEV Community: Maksim Dolgih

Fear of AI made me create my own product

Maksim Dolgih — Thu, 12 Mar 2026 11:19:55 +0000

After losing my job, I encountered problems and questions that had always been there, but I hadn't paid much attention to them. But that's what defined the new me.

Where should I begin my story…

I am a front-end developer with eight years of experience. Since September 2025, I have been looking for a job. And no, this is not another article about broken hiring or something else. This is my story of how losing meaning in the moment helps me understand and reflect on my entire professional experience. And that, sooner or later, everything I have done will mean nothing.

After losing my job through no fault of my own, I was confronted with problems and questions that had always been there, but which I had never paid much attention to:

Apathy and the trap of being a developer: "Why learn anything new about technology if AI will be able to do it in a month anyway?" "What's the point of learning if a library or framework only lasts 2–3 years on average?"
With the realization that after 2020, there is no such thing as "stability." But what can I do if I'm not a developer? Where is my concept of "anti-fragility"?
All my skills in processes and automation apply only once per team/employer. Once done, auto-process works without any problems. My skills served as a means to smoothly replace people, whether they were resources or not.

And the conclusion was simple: "I am a capable performer and creator, but I am still dependent on others."

I am a product of the current education system, where my skills are needed by those who are changing the world, but I myself am not.

The more I read about AI, the more useless I felt

We all live in the same information field. Yes, the availability of Claude Opus 4.5 or other models has gradually and slowly made my experience and learning from mistakes a waste of time in the past. Everything I used to do for each project is now sometimes just "prompt + generation."

I built processes where "SOLID" and "DRY" concepts were important. I built Zero Error Policy development and secure releases. I was meticulous about every possible bug, and I fiercely argued that writing strict and correct code was essential. But none of this fits under the concept of "business development." In fact, all my processes slow down feature delivery, but I forced people to write code for people.

Business thinks about how to make money now, while developers think about how not to spend money later.

This phrase can be used to describe any development, and every debate about what is more important: "refactoring" or "quick results."

AI has changed the code development paradigm

In the past, people wrote code for people, so it was important to follow development principles. It was important to understand the context of the code over time and to ease the cognitive load on the developer in the future.

With AI, there are no such problems. It can easily find bugs in the most obscure code, rewrite it, or adapt it to a new library or architecture. Tech debt has become conditionally free.

Everything I tried to prevent became unimportant. Because now you can do this:

Write preliminary tests and benchmarks for the application
Write down the instructions for the result
Run the model for 5–6 hours
???
Profit

The only thing that concerns you now is how to optimize tokens and avoid quotas.

Now, it doesn't matter how the code is written or by whom, because it can always be changed if you know how to verify it. Previously, a business couldn't grow without a development team, but now a business can consist of just one person with a smart idea.

We now have ready-made website builders and AI-driven site generation from plain descriptions. Where front-end development by a human being was important, it has become automated and reproducible. We have moved from "code by people for people" to "code by machines for machines."

Technology is not important, syntax is not important, patterns are meaningless; what matters is the idea.

The wrong question

For a while, I was asking myself: "How do I stay relevant?" — It's the wrong question.

It is assumed that relevance is something you develop within yourself by staying up to date with developments:

learning a new framework
mastering a new model
learning a new language

It's a treadmill. And the speed only increases.

I'm going to say something that might hurt developers' feelings, but you will need to keep learning throughout your life to remain "marketable" to businesses. Relevant development skills last 3–5 years; then they become obsolete. Even your 3,000 tasks on LeetCode are just a set of numbers in your profile; AI is better than you at applying algorithms for working with arrays, hash tables, and other types of data.

The more I read about AI, the more I framed the problem as a competition. Me versus the model.

My 8 years of experience versus a prompt that produces the same output in thirty seconds. Framed that way, I lose. Everyone loses. That's not an interesting problem to solve.

I stopped asking "how do I compete?"

I started asking, "What actually goes wrong when nobody with my knowledge is in the room?"

Because something does go wrong. AI generates code, but it doesn't audit the result. It produces sites that look correct, pass basic checks, and ship broken in ways nobody noticed.

That's not a gap that more AI fills. That's a gap that requires a different kind of thinking — not generation, but judgment. And judgment, unlike syntax, doesn't depreciate on a three-year cycle.

Capitalizing on your own skills

The standard playbook for a developer who feels obsolete is predictable: pivot to mentoring, launch a course, rebrand as a consultant.

And I rejected it immediately.

All of these are the same dependency, just repackaged. You're still selling time. You're still replaceable. And the next model update will commoditize that too.

The real question isn't "how do I stay marketable?" It's "what do I know that neither AI nor current automated tools will catch for you."

These aren't exotic edge cases. They're the ordinary output of agencies, freelancers, and AI-generated sites that nobody audited with actual front-end knowledge. The people who commissioned the work don't know what to check. The tools they have access to don't surface these issues. And the developers who built it have already moved on.

This is the gap. Not "I know more than AI." But: AI generates, Lighthouse measures performance, and nobody is looking at the output the way a senior front-end developer would.

Expertise as a service

Assessment based on external characteristics

As a front-end developer, I always look at the website of the company I am interviewing with.

They may tell you about excellent conditions, a professional team, and other benefits, but these are just words.

And the public website is the result of their work. If the public website is bad, what can be said about the rest of the internal product development?

But checking every company website using several different tools is difficult and tedious. On the plus side, there are many checks that Lighthouse and other static analyzers don't highlight, and only developers are aware of them.

That's how the idea to create a service for "auditing" public websites came about. To combine all the best practices and immediately perform a comprehensive analysis with one click: "What are the problems and how can they be solved?"

But don't just say "the problem is bad"; explain to the user why it's a problem, what needs to be done, and how the solution will help.

First steps

I knew for sure that I didn't want to do something like a "wrapper project over AI." Not because I'm bad at understanding AI, but because it creates obvious vendor lock-in.

Our project is not working due to an OpenAI malfunction. We apologize for the inconvenience.

Also, it won't be a startup that requires investment rounds, development hustle, and so on. I need to develop something at my own pace that reflects me and the knowledge I have, but also protects me from copying.

What was the first thing that came to mind? Take the Lighthouse API, add a few static checks, and generate a large report by category with error categorization.

What happened in the first iteration:

Lighthouse API
W3C Validator API
Basic rules for OpenGraph validation

No designer, no development team, no business analyst, no Customer Journey Map — just pure enthusiasm and a desire to prove to myself that my knowledge is not useless.

As you can see, at that point I had already created a "Dashboard" for storing history, a "Profile" for managing your data, and, of course, a "Subscription" for managing other people's money.

Yes, he was a businessman.

But at that stage, I didn't even explain what the mistake was, why it was bad, or how to fix it.

Obviously, simply creating a UI over standard free checks for the purpose of making money is not a great idea.

The initial motivation was enough to make a prototype, and the plan in my head worked, but it cannot be called a full-fledged product, because anyone can copy or vibe-code something similar.

The checks should primarily be based on my knowledge, which reinforces or supplements the usual code validators.

Development based on real needs, and almost the first customer

It so happened that my friend and ex-colleague was creating a personal website at the same time. He wasn't a developer; he was a QA engineer. He had minimal front-end knowledge, just his idea, a few design sketches on paper, and Gemini 3 and Claude Opus 4.5 to generate the site.

A distinctive feature of his website was that it was written entirely in native HTML, CSS, and JS. No trendy tools, builders, or optimizers. It's hard to imagine a more difficult way to build a website from scratch without any front-end knowledge.

Coincidence? Luck? Fate? — I don't know.

It so happened that I needed to automate the expert assessment process, and there was a person who needed help with the development, without asking AI, but getting an accurate answer about where the problem lies and what to do about it.

If we disregard SEO validations, which should be 100% in the product, several audits are always found in separate tools, but never together.

OpenGraph

The first problem that needed to be solved was, "How will the website look if it is shared on social media?"

Obviously, a preview was needed, and something similar to opengraph.xyz, with the distinctive feature of "we don't just talk about mistakes, we also make decisions right away in one place."

The standard solution is a parser, verification, output of failed checks, a little context, and providing fallback elements. It was simple.

The number of checks increased, and it was impossible to simply place them in one long list, especially with previews.

This is how the first draft for the Summary Preview came about.

Thanks to Apple for the tip

In November 2025, a critical problem was discovered for the App Store web client. All of its source code maps were found together with the code. Anyone could see how Apple works, what methods it uses, and how it organizes its code base.

App Store web has exposed all its source code

Naturally, for an engineer like me, who is used to nitpicking every minor bug, this was a gold mine for analysis.

That's how the idea to add a "Security" module came about — but not just to search for source.map, but to search for all possible "forgotten" tokens. What GitHub parsers do to search for committed API keys, I started doing for public sites.

There are more details now, and new entities in the form of "files" have appeared. This is not just a review of an HTML document; it is a complete analysis of the build that users receive.

Example of detecting a suspicious string

It became clear that the old format of "here's the whole long list" wasn't really suitable for a quick overview of the issues. We needed a new visual representation that showed what we were working with and where the problem came from.

Updated interface for working with security audits

Style validation

The main problem with using AI in front-end development is that it cannot "see" the results it generates. AI is used to develop based on structural approaches such as FSD and Tailwind. Without them, AI becomes blind. The context of elements, their styles, and future sizes can easily be lost on it.

Just as an example, this is what the adaptive looked like according to Claude Opus 4.5.

For a developer, this code is terrifying. For the average person, it's incomprehensible — but perhaps that's how it should be? This is just a few kilobytes added to the final size of the application, with no consequences, unless we consider the development of the site over the next 3–6 months.

Did this fit the needs of a profile-website? Not really. The profile-website is a one-time event: "made, published, and forgotten."

But !important is something that can be caught immediately as a starting point for style validation. Of course, auditing !important or z-index alone does not carry the same weight as "fix it or lose money," but if you add more meaningful checks — such as Unsupported syntax, Coverage, or SRI — then style auditing becomes just as important as searching for forgotten tokens.

Closed demo

Once the technical part was ready, I thought, "What if I bring the development out of the shadows and finally tell everyone what I've been doing for the past month?"

What was available at that time:

Modules:

Performance
OpenGraph
Network
Security
CSS Styles
HTML + A11Y validation
Technical SEO

Plus a range of basic functionality: launch history, localization into 2 languages, audit statistics for a website or domain, authentication, subscription management, and RBAC.

As a developer, you try to make the code and application as good as possible, even in your own project. The more you work on a project in focus, the harder it is to detach yourself from your own "I" and look at what you are doing from the outside.

This is a real problem if you don't have an outside perspective.

Focus group

The developer's environment consists mainly of other developers. And every developer understands how things work in browsers and on the internet.

Ten 1-hour calls. No hints, just observation and answering questions. As soon as we went through the first scenarios and everything was relatively clear, I added context about "what works, how, and why."

What did I learn?

A list of more than 50 errors is just "noise" to a person. Problems need to be prioritized.
An "audit score" is just a number. A value of 0 (out of 100) is not perceived as a problem.
Security — interesting to many.
I missed cases where a public website is an iframe widget or a Telegram mini-app.
Large websites cannot be checked because they are under re-captcha.
The developer wants auto-checking, which means integration with CI/CD is needed.
There was an "Ask AI" button that helped narrow the problem and solution when general recommendations were insufficient, but it was used only once.
My product is disposable, and the release cycle for websites is limited to 2–3 launches. Once it's fixed, it's forgotten.
UX and UI matter more than the number of features or product quality. If the interface doesn't tell you where to click, be prepared to do onboarding and tooltips.
Dividing into sections is not ideal. Some individuals require a comprehensive list of issues, ranging from critical to insignificant.
Technical descriptions and terms. Yes, the developers understood this, but QA engineers and others did not.
Developers looked at errors, leads looked at graphs, and managers only looked at what affects SEO.

"What difference does it make that it's a mistake if the company gets potential customers?"

"There's already a Lighthouse, what's new?"

"I don't understand what the correction will achieve?!"

And at this stage, it is possible to cancel everything

Because I have created something unnecessary.

The knowledge and context I provided were obvious to the developers. Most people work in closed systems, and access to the internal system involves security policies and raw code processing.

I asked the wrong people

What problem was I initially trying to solve?

You trust designers, agencies, or AI to create your website without understanding the technology, fully confident that everything is correct because you were told so. But what if I showed you that this is not the case? What if I showed you in detail how agencies/AI/designers are "deceiving" you?

And how do developers and commercial SPA development intersect with this problem? — Not at all.

I solved some people's problems while asking others for their opinions. People who were like me, but remained part of the system of executors, rather than decision-makers.

The same vector, but meaningful

Who am I trying to help?

People who develop websites themselves with or without AI
Agents to verify their work
Freelance developers
Customers who want to independently verify the result

What should I include in the product?

Clear context of the problem, as well as corrective measures
Description of the problem for non-technical specialists, classification of problems, and the impact of each problem
Seamless fix option for vibe-coders
Tracking issues remotely to support websites after delivery
Prevent problems before pages are indexed by Google

What did I do?

Each issue contains a description of the problem, a preview of the location of the problem, and the impact of the fix
Division of technical and product reports into "by audit" and "by category"
MCP server for local development that works with the build without interfering with the source code
Generate prompt for AI — a set of ready-made adaptive prompts for AI. For when you don't want to install an MCP server
Schedule of checks and thresholds by severity of problems
User notifications by email
Sharing the audit for review by other participants
PDF reports for users and customers

I have separated the product from general access and am identifying the real needs of users in private conversations, rather than through metrics.

Lighthouse is a solid foundation, but I go further: I discuss which errors matter and how to prioritize them to resolve them.

This is how the closed beta test of my product for my circle of friends and a publicly accessible page appeared: anyone can try a part of the product and, of course, sign up for beta testing.

Give Your AI Editor Perfect Context

Stop guessing why AI code broke. Get 10-second scans and structured Markdown prompts for Cursor or Copilot to fix HTML, SEO, and Security issues instantly

webvalid.dev

Keys are released gradually after major updates to avoid confusing the main tasks and issues. But you can already try part of the product for free.

This is not a conclusion, this is an opening

I didn't write this to prove anything, not to myself, not to you.

I wrote it because somewhere in this story — in the apathy, in the wrong questions, in the focus group that told me I was solving the wrong problem — you might recognize something familiar. A moment where you looked at what you built and weren't sure it mattered. Or a moment where you looked at what someone else built for you, and quietly suspected something was wrong, but didn't know what to call it.

That recognition is exactly what I'm looking for.

Not investors. Not users who will silently churn after a free trial. People who read this far — which means you're either a developer who's asked the same uncomfortable questions, or someone who commissions or ships websites and knows the gap between "it looks fine" and "it actually works" better than you'd like to admit. Either way, I want to hear from you.

Not "great idea, keep going" — that's noise.

Tell me:

Where does the logic break?
What problem have I described that you've actually felt?
What am I still getting wrong?
Does the product sound useful — or like something you'd close after thirty seconds?

WebValid is still being shaped. The person who shapes it is me — and, if you're willing, the next person is you.

If anything in this resonated — reach out. One message. No commitment. Just a conversation between people who care about whether things are built correctly.

I will leave it as an example

Full Website Audit | WebValid

Comprehensive scan of SEO, Security, Markup, and Performance examai.lovable.app

webvalid.dev

Creating Envless Angular-application

Maksim Dolgih — Mon, 12 Aug 2024 17:19:49 +0000

Ways to move from hard-coded code for each environment to a universal build that can be used anywhere

Introduction

As you all know, Angular has its own tools for building an application for different environments

Configuring application environments

This is accomplished by creating and using the environment.<env>.ts file for the appropriate environment in the build. These allow you to switch between settings for:

Development (environment.ts)
Testing (environment.test.ts)
Production (environment.prod.ts)

The main tasks of `environment.ts` files are:

API settings. Each file can contain different URLs for API servers depending on the environment.
Optimization. The production file disables debugging features and enables optimization to improve performance.
Environment variables. Easily manage environment variables such as API keys and flags to activate or deactivate functions.

And everything seems to be fine — a different file for each environment

Problem

Imagine, as the number of environments grows, you need to:

Create a separate environment.<env>.ts file each time.
Create a separate build-configuration and specify fileReplacements
Add this build-configuration to serve-build
Add the command "my-app.build.<env>": "ng build — configuration <env>” to package.json

So every time

I’m not speaking about e2e-tests in pre-prod-environment or dedicated builds for feature-branch.

And for what? — To use a template command in CI

- run: npm run my-app:build:${{ SOME_VAR.ENV }}

The notional pipelines of such an application can be depicted as follows

And you can say — “this is basic scaling and CI independence from env. If we want to use TEST1, just pass ENV=TEST1”.

No, my young architect, this is wrong. Why? — Because your application knows about all the environments in which it is used, and keeping track of every configuration is a problem:

Do you want to add 1 new parameter to the config? — you need to update each file, plus you need to know what value is needed for each env.
Want to change a parameter for an application in some environment? — Be kind enough to go to the repositories, update the file and run it

There are so many examples of this, and every time there are scalability and support issues

Disadvantages of using environments.ts files

Support for all environments.<env>.ts files is required
Creating alternative builds for each env in angular.json
Creating duplicate docker images with only a few parameters, resulting inefficient registry space utilization
Necessity to run a full pipeline for each
Tests are performed on an assembly that will not be provided to the user
Lack of flexibility to change a parameter for an individual environment
Inability to share the application as a HeadLess solution

Task Statement

Main points to achieve:

Ensure that the application and docker image are built only 1 time.
Our application should be able to be configured for different ENVs, and define only the interface of the variables it needs
To separate the development space and work with the application build, we need to keep the source files environment.ts and environment.prod.ts

As a result, we should get the following scheme for using and deploying the application

Where:

Envless Build pipeline is a pipeline that runs only once, builds the production build of the application, and saves it as a docker image in the registry
Deploy pipeline is a release pipeline that already knows for which ENV the application should be deployed.

The application configuration is pulled back until the last moment closer to the release part

Solution 1 — Get config from the server

To implement this solution, it is necessary to have an API-endpoint server within which all the necessary config can be obtained

Scheme of work

Implementation

Let’s declare a configure interface and a token for its provisioning within the application. Also, we’ll create a default value for the initial state

export interface IAppConfig {
  apiHost: string,
  imageHost: string
  titleApp: string
}

export const APP_CONFIG_DEFAULT:IAppConfig = {
  apiHost: 'https://my-backend.com',
  imageHost: 'https://image-service.com',
  titleApp: 'Production Angular EnvLess App'
}

export const APP_CONFIG_TOKEN: InjectionToken<IAppConfig> = new InjectionToken<IAppConfig>(
    'APP_CONFIG_TOKEN'
)

Create functions that will request the config and provide it. In case of server error, provide the application with default settings for valid operation

  function loadConfig(): Promise<IAppConfig> {
      // or relative path /app/config
      return fetch('http://localhost:3000/app/config').then(
          (res) => res.json(),
          () => APP_CONFIG_DEFAULT
      )
  }

  export async function bootstrapApplicationWithConfig(
      rootComponent: Type<unknown>,
      appConfig?: ApplicationConfig
  ): Promise<ApplicationRef> {
   return bootstrapApplication(rootComponent, {
       providers: [
           ...appConfig?.providers || [],
           {
               provide: APP_CONFIG_TOKEN,
               useValue: await loadConfig()
           },
       ]
   })
  }

Replace the native bootstrapApplication function with a new bootstrapApplicationWithConfig function

  // bootstrapApplication(AppComponent, appConfig)
  bootstrapApplicationWithConfig(AppComponent, appConfig)
    .catch((err) => console.error(err));

The application configuration server will be a simple configuration on express

  app.get('/app/config', (req, res) => {
      res.json({
          apiHost: 'https://my-backend.<ENV>.com',
          imageHost: 'https://image-service.<ENV>.com',
          titleApp: '<Env> - Angular EnvLess App'
      });
  });

Run-time verification

Since the application is configured in run-time, it is not a problem to check its operation even in a local environment, knowing the required URL.

At the moment of application startup, we get the config on request without any problems. We can use this config for other application services that use other API URLs for requests

In case of a response error from the server, the default value will be used and the application will continue working

Advantages and disadvantages

In addition to fulfilled task conditions, there is other advantages of using this approach:

The application is configured by runtime and does not require redeployment
The configuration is loaded before the application starts, so you can use parallel requests via APP_INITIALIZER tokens without worrying about the order in which the config is received
In e2e-tests, it is easy to intercept the request and give the configuration file for the test

But there is a downside:

You need to know the URL to get the config or have the same host for both front- and back-end application
The response from the server can be long, which can affect the user’s expectation
It is necessary to have a FALLBACK value in case of a request error
It is necessary to have a dedicated database with config for each ENV
It is necessary to have an API for reading and modifying the config by an administrator with dedicated access rights
Due to run-time configuration, there is an increased chance of errors and the config needs to be validated in the front-end application
Configuration support is provided by backend developers and DevOps

If we don’t touch the basic build pipeline, is there any possibility to keep the scheme with getting the config, but no longer depend on the server considering its disadvantages? — Yes, you can configure a docker image

Solution 2 — Configuring a docker image

The essence of this solution is simple — instead of requesting a remote server to get the config, there will be a request to the file directory where the Frontend application is located

The configuration file will be created during the source docker image retrieval stage, replacing the default config.json. The default directory in which the front-end application executes requests is assets or public.

The configuration file will be created on the ENV variables that were specified when the deploy pipeline was started. If the ENV variable is not found — the default value will be used

Scheme of work

The solution is elegant but will require skills not only in frontend, but also in DevOps and CI-scripts

You will need to implement this scheme of work to “update” the config.json file

Deploy Pipeline

Implementation

As opposed to getting config.json from the server. We need the keys in the config to match the ENV variable name when the config is updated

Local assets/config.json

{
  "APP_ENV_API_HOST": "https://local.my-backend.com",
  "APP_ENV_API_IMAGE_HOST": "https://local.image-service.com",
  "APP_ENV_TITLE_APP": "Local - Angular EnvLess App"
}

Config request function with updated URL

function loadConfig(): Promise<IAppConfig> {
    // relative host
    // public or assets path
    return fetch('/config.json').then(
        (res) => res.json(),
    )
}

Example script to create a new config.json and update docker-image

  #!/bin/bash

  set -x
  set -e

  # EXAMPLE - ENVS FOR CONFIG
  APP_ENV_API_HOST="https://<ENV>.my-backend.com"
  APP_ENV_API_IMAGE_HOST="https://<ENV>.image-service.com"

  # SETTINGS
  PORT=4110
  NGINX_PORT=80
  CONTAINER_NAME="angular-envless-container"
  IMAGE="angular-envless"
  NEW_IMAGE="patched-angular-envless"
  CONFIG_NAME="config.json"
  APP_PATH="/usr/share/nginx/html"

  #Step 1
  temp_container_run(){
    docker run -it -d -p $PORT:$NGINX_PORT --name $CONTAINER_NAME $IMAGE
  }

  #Step 2
  temp_container_get_config(){
    docker cp $CONTAINER_NAME:$APP_PATH/$CONFIG_NAME ./$CONFIG_NAME
  }

  #Step 3
  create_config_json(){
    temp_container_get_config

      if [[ ! -f "./$CONFIG_NAME" ]]; then
        echo "Config file not found in the specified directory."
        temp_container_stop
        temp_container_rm
        return 1
      fi

      # Extracting keys and values from JSON
      KEY_VALUES=$(awk -F '[:,]' '/:/{gsub(/"| /,""); print $1 "=\"" $2 "\""}' "./$CONFIG_NAME")

      # Creating a new JSON object
      PROD_CONFIG="{"

      # Passing through keys and values
      for PAIR in $KEY_VALUES; do
        # Separating key and value
        KEY=$(echo $PAIR | cut -d '=' -f 1)
        DEFAULT_VALUE=$(echo $PAIR | cut -d '=' -f 2 | sed 's/,$//') 

        # Check if there is a value in the environment variables
        VALUE=${!KEY}

        # If there is no environment variable, we use the value from the source file
        if [[ -z "$VALUE" ]]; then
          VALUE=$DEFAULT_VALUE
        else
          VALUE="\"$VALUE\""
        fi

        # Add key and value to JSON object
        PROD_CONFIG+="\"$KEY\":$VALUE,"
      done

      # Remove the last comma and close the JSON object
      PROD_CONFIG=${PROD_CONFIG%,}
      PROD_CONFIG+="}"

      # Saving the result to a file
      echo "$PROD_CONFIG" > "./$CONFIG_NAME"

      echo "Config updated successfully and saved to ./$CONFIG_NAME"
  }

  #Step 4
  temp_container_upsert_config(){
    docker cp ./$CONFIG_NAME $CONTAINER_NAME:$APP_PATH/$CONFIG_NAME
  }

  #Step 5
  temp_container_commit(){
    docker commit --pause $CONTAINER_NAME $NEW_IMAGE
  }

  #Step 6.1
  temp_container_stop(){
    docker stop $CONTAINER_NAME
  }

  #Step 6.2
  temp_container_rm(){
    docker rm $CONTAINER_NAME
  }

  main(){
      temp_container_run
      create_config_json
      temp_container_upsert_config
      temp_container_commit
      temp_container_stop
      temp_container_rm
  }

  main

Run-time verification

After running this script, all you need to do is run the docker image in the container and make sure that the environment variables are applied to the config

The code works fine, given that the APP_ENV_TITLE_APP variable was not passed when the docker-image was configured

Advantages and disadvantages

Thanks to this approach, the server’s influence on front-application configuration is reduced. In addition to the advantages of configuration through the server, we get:

The configuration is available immediately and delays in getting it are minimal
No FALLBACK value is required in case of a request error
No API or external administration over the config is required.
Reliability. The assembly cannot be broken in run-time
No need to create a separate database for each environment

But if you look at it from the other side, there are some disadvantages:

Increased complexity of the application’s deployment infrastructure
Separate Pipeline Deployment is required
Need to be supported and validated by DevOps-engineers
Need to know the right ENV-variables and set a pre-defined list to configure the application at the time the deployment starts

In conclusion

The solutions I have presented are only suitable if you need flexibility and independent management of your Frontend application. If you realize that your current application does not require flexible configuration, your DevOps engineers effectively manage docker-registry memory or you do not plan to create a headless application — you can use environment.ts files as before.

In some cases, when you don’t know the possible implementations and uses of an application at the start of development, this approach can save a lot of time in the future, and give you full control over build management

Angular 18 — Zoneless & Change Detection

Maksim Dolgih — Wed, 31 Jul 2024 08:27:29 +0000

Clear examples of change detection on different application triggers. Click, Input + NgModel, AsyncPipe, Signal, Web API — setInterval

After years of waiting and practicing “how to tame the dragon” skills, the Angular team has finally released an update that allows you to test building applications without using ZoneJs

In this article I would like to show how change detection is performed across the entire component tree when using different triggers, namely:

Click event — button click event + handler
Input + NgModel — processing of user input with saving to a variable via two-way data binding
AsyncPipe — output value into a template from Observable
Signal — output value into a template from toSignal(obs$)
setInterval — Web API

These triggers will be tested in a few environments:

NgZone + ChangeDetection.Default
NgZone + ChangeDetection.OnPush
Zoneless + ChangeDetection.Default
Zoneless + ChangeDetection.OnPush

Environment

Angular 18.0.7
zone.js 0.14.3
Rxjs 7.8.0

Click event

Let’s start with a simple one. Button events are one of the most frequent events of any application. They are used for web page interactivity — navigation, form validation, animation triggering, etc.

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

From these tests, we can see that the change detection behavior between NgZone and Zoneless is not different, and to reduce the number of checks it is necessary to use a detection strategy via OnPush

Input + NgModel

Another one of the popular elements of any web application — search, login form, filtering data in a table. Listening and validating element values can be done in different ways from addEventListener to SubmitEvent, but nevertheless you should always listen. For these examples we use the ngModel binding

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

Similar to the button and click event tests, there is no difference between NgZone and Zoneless and OnPush should be used to get a better and more optimized version of the application

AsyncPipe

One of the older Angular APIs for handling asynchronous events and template updates. RxJS and AsyncPipe make it easier to handle asynchronous data flows, make code cleaner and more reactive, and improve the manageability of Angular applications.

From a component update perspective, there is not much difference between subscribing inside a component with a call to markForCheck() and using AsyncPipe. We have a new value — we need to request an update.

For this example we will use a simple timer() counter with a period of 1 sec and display the value on the screen.

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

Again no change between Zoneless and NgZone, still need to use OnPush to reduce the number of component tree checks

Signal

A new API for handling asynchronous values on a pub/sub basis.

Angular Signals is a system that keeps detailed track of how and where your state is used in the application, allowing the framework to optimize rendering updates.

The familiar timer() function will be used as the data source, with conversion to the Signal API via the toSignal() function

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

Finally we can evaluate and see the impact of signals on change detection checking for the whole application.

The event detection cycle for the entire component tree only works in the NgZone + Default mapping. In all other cases, changes coming from signal are isolated for the component and do not require checking even the component itself. Wow 🔥

Web API — setInterval

The basic idea behind zone.js is to create an execution context, called a “zone”, that can intercept and handle all asynchronous operations occurring in that context. Zones can intercept and handle all asynchronous operations occurring in them. This is accomplished by overriding standard functions such as setTimeout, setInterval, promises, etc.

In simple language, “overriding” a function is monkey-patching. This is how zone.js notifies Angular to check for a change.

setInterval is one of the global functions available when code is executed in the browser. It is considered good practice to wrap the setInterval call in zone.runOutsideZone() to avoid unnecessary validation loops

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

The tests give an unexpected picture, the use of setInterval has a significant impact on component tree checking only when using the NgZone + Default mapping. In other cases, using setInterval is safe without using runOutsideZone, and does not affect component tree checking.

Conclusion

It is relatively safe to use Zoneless in current applications when upgrading to version 18. All necessary component checks and trigger responses are similar between Zone.js and Zoneless. If possible, you should always follow the event detection strategy via OnPush.

Signal’s were a pleasant surprise. Template updates are isolated and do not affect the component tree, which will be extremely useful for partial hydration.

There is no need to be afraid of using asynchronous global Web API. Even when using Zoneless + Default — it doesn’t cause component tree checking and all calculations happen in the background.

I realize I have only checked a small part of possible scenarios and triggers, there are many more examples — using Signal-input / output / model, Signal Store, etc.

Bonus

One of the benefits of dropping ZoneJs will be to lighten the current build.

If your standard application with 0 logic at the start is 216kb in size, ZoneJs takes up 15% of the total build, which is quite a large share

After uninstalling ZoneJs got rid of 33kb and made your build lighter, and the app continued to work as before.

“Eslint-Summary” — Hack your Eslint Config

Maksim Dolgih — Wed, 31 Jul 2024 05:35:44 +0000

Get full information about used rules and plugins in the eslint-config on the project with just one console command

Introduction

Not very often, but we need to understand what rules are used in our eslint-config on a project. There could be several reasons for this:

Control of third-party rules. It’s more profitable for developers to use pre-built style guides from other teams. For example, Google or Airbnb. However, keeping track of other people’s rules is extremely inconvenient, especially if the rules are actively being added and changed.
- GitHub - google/eslint-config-google: ESLint shareable config for the Google JavaScript style guide
- Airbnb's ESLint config, following our styleguide
Familiarize team members with the current style guide. If your configuration consists of many plugins, you hardly want to force a person to manually familiarize themselves with each plugin, rule, and area of responsibility from the config.
Collecting feedback: Visual presentation and knowledge of the current rules help to collect and incorporate feedback from the team to further improve the ESLint configuration, making it more useful and convenient for everyone
Avoiding redundant checks: Understanding of the rules being used avoids redundant rules that can slow down development or complicate the current config

Example of problem

Let’s say you’re a newbie and your first working week has started. You’ve got all the accesses, downloaded the repositories, see the familiar file .eslintrc.json.

You open this file and see in it…

{
 "extends": "next/core-web-vitals"
}

What information does this line give to you? — Nothing, except the name of the config. Ask yourself, “Are you willing to waste the time to find a plugin and familiarize yourself with its rules?” — I think not.

What’s the solution?

If eslint is familiar to you, you can call the command eslint --print-config ./.eslintrc.json. Calling the command will return a list of all the rules from the config as a long list in the console. But, unfortunately, you will have to search for each rule manually, understand its meaning and rationale, and correlate the current settings. This is extremely inconvenient if there are many rules.
You can try using the new solution “Eslint config inspector” — it is a visualization of the current config. The disadvantage of this solution is that it doesn’t support deep rule search along the inheritance chain. Also, it is not documentation, but an application.
GitHub - eslint/config-inspector: A visual tool for inspecting and understanding your ESLint flat…
My solution is npm package @dolgikh-maks/eslint-summary

What is “Eslint-Summary”?

This is an npm-package to generate rules documentation for the current project, custom plugins, sub-projects, and other possible scenarios where eslint configs are used.

Its task is simple — to generate a markdown file on the current configuration for each plugin and the rules involved in it.

But not just to show that “there is such a rule”, but to provide all information about it, as if you were viewing the plugin’s page. You understand what the rule is for, whether it supports autofix, and what files it applies to.

Installation

All you need to do is specify the familiar command to install npm-packages

npm i --save-dev @dolgikh-maks/eslint-summary

Launch

If you are using the .eslintrc.js file as the base config, then no additional configuration is needed, and it is enough to call the command

eslint-summary

After running the command, you will have an eslint-summary-report directory with the .eslintrc.md file.

Report file

When you open the created .eslintrc.md you will be given summary tables for each plugin involved in the .eslintrc.js config.

The table has reserved columns:

Rule — name of the rule of an eslint plugin
Extension *.<extension> — column showing what settings the rule has for this or that extension file

The remaining columns are columns that display meta data from the rule

Custom Rule Tutorial - ESLint - Pluggable JavaScript Linter

The main feature

If you want to learn more about a rule, you don’t need to search for it manually through the search engine, just select the desired rule from the table.

The name of a rule already contains a direct link to its documentation

Configuration

The .eslint-summary.<js | json | ts | yaml> config file is used for easy configuration of the package. In it, you specify the necessary options for generating reports if you are not satisfied with the default settings of the package

extensions

default — ['js']

Specify the required file extensions to display the rule settings for each file type in the report.

This is a very convenient option if your project contains different file types, such as json or spec.js, and you want to know how rules work with these file extensions.

Important. Specifying any value will overwrite the current [js] setting. If you want to save the report for js-files, this extension must also be specified

/**
 * @type {import('@dolgikh-maks/eslint-summary').IConfig}
 */
module.exports = {
   extensions: [
       'json',
       'spec.js',
       'js'
   ],
};

output

default — eslint-summary-report

Change the path of the report directory.

Supports nested directories. If such a directory does not exist at the moment of generation start — it will be created.

/**
 * @type {import('@dolgikh-maks/eslint-summary').IConfig}
 */
module.exports = {
   output: './docs/eslint-summary',
};

ignorePlugins

default — []

Exclude plugins from your report.

Sometimes other people’s configs contain the use of third-party plugins, but they don’t work with our code and its analysis. For example, eslint-config-prettier, which contains plugins for react, vue and flowtype.

/**
 * @type {import('@dolgikh-maks/eslint-summary').IConfig}
 */
module.exports = {
   ignorePlugins: ['eslint-plugin-vue', "eslint-plugin-flowtype"],
};

configs

default — ['./.eslintrc.js']

Specify eslint-configs for which you want to analyze and generate documentation.

If your eslint config file name is different from the standard one (.eslintrc.js), you can specify where and which file needs to be analyzed.

If you have several files or sub-projects with their configs, it is not a problem to specify paths to them

/**
 * @type {import('@dolgikh-maks/eslint-summary').IConfig}
 */
module.exports = {
    configs: [
        './example-apps/angular/.eslintrc.js',
        './example-apps/next/.eslintrc.json'
    ],
};

The generator will create a different report for each config, according to its name and location

Example of usage

In my article on creating a team style guide, we got a way to create and scale @my-team/eslint-plugin

Create your code style for the team from scratch. Eslint, Prettier, Commitlint and etc.

What if we want to allow users of our plugin to see settings and configurations as documentation, similar to this structure?

It’s pretty simple:

Install the package @dolgikh-maks/eslint-summary
Set the desired settings in .eslint-summary.js

/**
 * @type {import('@dolgikh-maks/eslint-summary').IConfig}
 */

module.exports = {
  extensions: [
    'ts',
    'html',
    'spec.ts',
  ],
  ignorePlugins: [
    'eslint-plugin-vue',
    'eslint-plugin-react',
    'eslint-plugin-flowtype',
  ],
  configs: [
    './configs/base.js',
    './configs/recommended.js',
    './configs/spec.js',
    './configs/strict.js',
    './plugins/rxjs/recommended.js',
    './plugins/prettier/index.js',
      // other paths  
  ],
  output: './docs',
};

Run the eslint-summary command
Get documentation for each configuration 🔥

Now, some users of your plugin can go to the /docs folder and see the current plugin settings.

For example plugins/prettier/index.md

You can find full example here

In conclusion

At the moment, the npm package is under development and does not take into account many factors such as Eslint 9 and its flat configuration. But nothing stops you from trying to use it with Eslint 8 and older.

If you think this tool would be useful — let me know. I’m happy for any feedback and help

Get an email whenever Maksim Dolgikh publishes.

@dolgikh-maks/eslint-summary

Bad questions for Senior Frontend Dev Interview

Maksim Dolgih — Mon, 08 Apr 2024 06:11:51 +0000

How the interview process has turned into a generic ChatGPT template where your experience doesn’t matter because you’re just being run through a checklist of questions

Everything described below is my subjective opinion

This story is not a direct guide for candidates and serves as a reflection on current technical interviews. It is up to you to decide what to do with this information

I aim to tell how popular interview questions, which can be freely found in the search results, do not have any practical application, and for me, there are signs of the negligence of the company in the selection of candidates. By doing so, any team can lose all Senior developers because there won’t be any relevant questions asked

I understand that the interview can be abstract if the hiring process is being held by a large company where the technical interviewer is not a part of the target team or project, and it’s just one step in a large selection process.

These questions are more relevant to the hiring process for small to medium-sized companies on the employment scheme

HR Interview (0.5–1h) — Technical Interview (1.5–2h) — Manager Interview (Optional) — Offer

I don’t rule out that the questions I’ve outlined have come across time and time again only to me and are my poor choice of company to interview with. I only mention some of the questions, but not the interview itself or the approach, and also suggest alternative questions for a particular topic.

How does the Event Loop Work?

At this point you close the page, because everything is clear — the author is dumb.

This is the most annoying question from any job interview for any level. But aren’t you tired of answering this question yourself every time?

Yes, of course, you can memorize the answer like an article from the Bible and calmly answer — There is some event, it is put into Call Queue, then into Call Stack and blah, blah, blah.

You have successfully told about the Event Loop and received the coveted checkmark ✅. Next question.

Do you understand why JS needs this mechanism?

The basic understanding of the Event loop is not to answer “How is asynchrony provided in JS?” but “Why is asynchrony provided in JS via the Event loop?”.

These are two principally different questions. Do you feel the difference? The second question relies on your experience, perception and outlook in development, where the keyword will be “single-threadedness” in your answer.

But basic interview guides from the internet and the popularization of Frontend development have led to the formalization of the main points, trying to pass off desired knowledge as actual knowledge

Try asking, "How to bypass the ‘single-threadedness’ limitation in JS and do computation in a separate thread?”

Does knowing “Call Stack” or “Call Queue” help you? — No. I guess it’s something to think about

Microtask and Macrotask execution queue

You have successfully answered the standard Event loop question and you are given a new task — “In what order will the numbers be output to the console ?”

console.log(1);

setTimeout(() => console.log(2));

Promise.resolve().then(() => console.log(3));

Promise.resolve().then(() => setTimeout(() => console.log(4)));

Promise.resolve().then(() => console.log(5));

setTimeout(() => console.log(6));

console.log(7);

Do you smell that? Unreal code, son. Nothing else in the world smells like that.

Even if you’re a Node.js developer — How often does your code have an “execution race”? You don’t understand when your code is synchronous and asynchronous?

The answer to this task is not even responsible for understanding microtask and macrotask, and their impact on rendering in the browser.

With knowledge of the execution priority in console.log, can you answer these questions?:

How to ensure that the interface is fast and smooth even with multiple concurrent events in it?
What is the point of using requestAnimationFrame?
How can you block the whole interface and further interaction with it when clicked, and how to avoid it?

Arrow functions vs regular functions

There is nothing wrong with this question, but it depends on who is asking it. If you answer “about the accessibility of outer this context and accessibility of function for executing” — that’s enough for me. (Yes, you can also mention the use of arguments)

But the question is being asked not by a simple interviewer, but by that “school nerd” who can’t get enough of your answer. You sit in awkward silence, and he is waiting for the difference between the two ways of declaring a function, and doesn’t give even a hint, because “the senior dev must know everything!”.

Give me, give me more

What’s he waiting for? — He’s waiting for you to talk about using constructor in regular functions. Yes yes, it’s 2024 and we have to discuss ES5 syntax.

Tell me, how often do you use this construction?

    function RegularFuncBird(name, color) {
      this.name = name
      this.species = color
      console.log(this)
    }

    new RegularFuncBird("Parrot", "blue")

Classes? — c’mon, who needs them ?! — FUNCTIONS.

Yes, you can say that “classes in JS are ‘syntactical sugar’ and it’s a way to pay homage to the old days”.

But let’s be honest, this knowledge is not relevant today. If a candidate has told you the practical ways and the difference in usage — that’s enough for the work.

Don’t be a nerd, your historical knowledge is only for you. Progress does not stand still and new knowledge is replaced by others

Var vs const & let

Since I started the topic about ES5 syntax, I’ll continue.

Another one of the popular interview questions. You are asked about it, and the discussion begins with which var is bad — popping up, contexts and problems, and const and let are good ones

You memorized a lot of mock interview answers and waited for this question

What is the practical value of this question? — minimally

Can I think that the company has projects with var? — yes

We can discuss for a long time how bad var is, but if you really care about this question of variables, you’d better ask:

About const working with objects and arrays
How the candidate understands the “const first” principle

In my opinion, the candidate’s answers will cover a lot of use cases and will give a clear picture of the candidate’s understanding of how this syntax works.

Detecting Memory Leaks

In one of my job interviews, I got an interesting question — “You come on a project and immediately look for memory leaks in the application, but it’s not you who will do this task, it’s QA. How would you describe the process of finding memory leaks to him?”

Wow. Unconventional wording of the question, because the interview usually indirectly describes the current problems of the project without telling you directly. But the funny thing is, my answer about “analyzing application snapshots through the profiler” was wrong. I still don’t know what the person wanted to hear from me

Anyway, if we abstract from the situation and try to understand the question, it appears that it describes the solution and the search for consequences, but not the prevention of causes.

Yes, you have found a memory fragment increasing with time, you have found a code area with a leak, and you don’t know what to do further, because you only know how to run the profiler.

In my opinion, the better question is — “how to write safe code that does not generate memory leaks ?”

The main points to be covered:

addEventListener('event', handler) -> removeEventListener('event', handler)
const interval_Id = setInterval() -> cleanInterval(interval_Id)
Understanding of “garbage collector” and long-lived refs.

You don’t need to know all about “how to find and fix consequences?” if you know “how not to cause problems?”

Types in Javascript

My favourite section for useless questions:

What are the main types of JS?
Why is null the object?
What is Symbol and how to use it?
What is prototype?
What is the difference between Number(num) and new Number(num)?
Why are there artefacts in the remainder when adding fractional numbers?
How to make a == 1 && a == 2 && a == 3 ?

You, as a Senior frontend developer, sit in an interview like this:

Yeah, dude. Not a single day goes by without me not using this syntax when developing web apps

This list can go on and on, but the answers to these questions are not necessary for developing reliable and functional front-end applications.

If you want to hear a candidate’s understanding of working with “types”, you should ask a list of questions like this:

How do you make sure that a value is an array?
What are some ways to cast the value to boolean type?
Where do the toString() and toJSON() methods come from?
Why is it better to use obj.hasOwnProperty(key) instead of obj.key ?
What are the peculiarities of working with fractional numbers and displaying their result?
Why should NaN.isNaN() be used?

CORS

Anyone who has ever developed an application with integration to some service has gotten this error. All you need to know about the CORS mechanism is that the browser checks the correspondence between the allowed domains for calling the service and the current domain.

You can find the historical part and the reasons for the appearance here

What could go wrong here?

You can get the question - “Why is the HTTP OPTIONS request used ?”

You don’t know? — It’s okay, don’t worry. You remain a good front-end developer. I give you answer

Calling HTTP OPTIONS is browser logic for getting allow HTTP methods from the service for requests to it, which you cannot influence in the final build from the user, and do not organize in any way yourself

The right question about CORS

“What are the ways to bypass CORS policies in the browser during development ?”

This question can show that you are familiar with this error and you can suggest solutions to your colleagues. You can suggest your own variants:

Proxy config
Special browser extension
Disabling browser policies

Knowing “Why is the HTTP OPTIONS request used?” won’t eliminate blocker problems when integrating a front app in development because you don’t develop the backend part

In conclusion

The technical interview is a two-way process to understand how future tasks and your experience can be used for the best advantage of each other, rather than sitting for 2 hours taking a theoretical exam disconnected from reality.

Checking the basic things that are required for Junior and Middle selection are not applicable for Senior developers. First and foremost, a Senior developer is about the experience with mistakes.

Based on my suggested questions, ask yourself — “What kind of candidate would I like to get? The one who answers the theory or the one who applies it?” All stakeholders will benefit from this decision because the project will really have people with experience, not just “sets of knowledge”.

Still, my proposal will not cover the main problem — only one technical interview for the Senior Frontend Developer role. In 2 hours of interviews, you won’t learn about the candidate’s skills in system design, and you won’t be able to devote much time to “live coding” and spend time on theory.

But hopefully, it will help

P.S.

I don’t exclude that I will make a second part about CSS questions if you like this article

Adding strict Eslint rules to the current code without problems

Maksim Dolgih — Thu, 29 Feb 2024 17:28:33 +0000

A strategy for applying new or strict linting rules to existing code without loss of development

Problem statement

In a previous story (Create your code style for the team from scratch. Eslint, Prettier, Commitlint and etc.), I broke down a way for a team to create their rules, organize them into packages in the recommended format, and apply them to a repository

Suppose you want to apply new Eslint rules or configs to an existing repository. You run a check on your repository and get a message like this:

1271 problems (1076 errors, 195 warnings)
345 errors and 37 warnings potentially fixable with the  --fix option.

What does this message tell us? — It says that Eslint rules found 1076 errors and 195 warnings. Of these, 345 errors and 37 warnings can be corrected automatically. We can fix only some parts of the code automatically, while the rest it requires manual correction. It is an unpleasant situation.

With lint-staged, any commit will “crash” on validation, because of errors in existing code. If you have a built-in check on the Lint job in CI/CD, it will also crash.

If the project is large and involves several participants, it is unlikely that you will be able to fix all the problems at once, even with auto-fixing. Even if you manage to do that, the current pool of Pull Requests will become conflicting, which will also affect the speed of development and the usability of the others.

We wanted the best, but we got a huge “blocker” of development

Strategies for solving the problem

Three main options can be identified:

Don’t apply new rules

You realize that introducing new rules generates many problems and there is no time to adapt and correct the code. Your attempt to improve the code and standardize it has failed.

Disable checks

Rules are needed, but they shouldn’t block work either, and perhaps you’ll look into fixing problems in the future. In this strategy, lint-staged checks do not include Eslint startup, and CI/CD jobs don’t block the pipeline process.

This strategy has a significant downside — your code review has become passive. Every developer can use his own style,
and your code review will be noticeably longer because you need to mark all the places to be fixed yourself when Eslint did it for you.

It is also not a fact that you will allocate time to fix problems in future and that the number of errors has not increased during this time.

Adapt rules to the current repository

With this strategy, you disable or change the alert type to WARN of “blocking” rules that don’t support auto-remediation. This will take some time to implement, but it’s a straightforward golden mean to get out of the situation. You don’t unilaterally fix the code to fit the rules, which will help not to affect your other colleagues.

Is it all?
There is no more strategy to apply code inspection rules? — There are

Divide & Conquer

This strategy is basically based on the “Adapt rules to the current repository” strategy, with one difference — the old code is checked against the Eslint config you adapted, but the new code is checked against the original Eslint config you originally wanted to apply to the repository.

For this purpose 2 Eslint configs are created:

Source config. Config containing code main lint rules to be used for development.
Adapted config. It inherits from the source config, but it also inherits from the “temporary rules config”. “Temporary rules” are “blocking” rules of the source config in the ERROR state, but which have no auto-remediation capability. These rules must be obtained imperatively the first time you run the code checker and their status is set to WARN.

Main advantages:

The approach ensures that new changes within the current repository will already be styled according to the new rules, but leaves the old code checked in. Over time, the new code will supersede the old code, and your repository will follow the current code style without exception.
To speed up the process, you can build into the work cycle switch from WARN to ERROR 1 rule per sprint
The approach can be applied to existing repositories with static analytic tools of code if you need to increase code rigour with a new plugin or rules

An abstract scheme for making changes and validating them would look like this:

Implementation

As an example, let’s see how to use the configuration strict from @my-team/eslint-plugin to the repository

Creating adapter eslint config

If we run the lint now, we will get the following log

There are 4 “blocking” rules that do not have autofix. Let’s put them in “temporary rules config” c WARN

configs/temp-rules.eslint-config.js

module.exports = {
    overrides: [
        {
            files: ['*.ts'],
            rules: {
                '@angular-eslint/no-output-native': 'warn',
                '@typescript-eslint/explicit-member-accessibility': 'warn',
            },
        },
        {
            files: ['*.html'],
            rules: {
                '@angular-eslint/template/no-any': 'warn',
                '@angular-eslint/template/no-call-expression': 'warn',


            },
        },
    ],
};

Also, create an adapted config that inherits from the .eslintrc.js and our temp-rules.eslint-config.js

.eslintrc.adapted.js

module.exports = {
    root: true,
    extends: ['./.eslintrc.js', './configs/temp-rules.eslint-config.js'],
};

If we run the check now, we should have no errors left behind

Files splitting for validation

Most implementations of lint-staged and husky are as follows starting call lint-staged on the pre-commit hook

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx lint-staged --quiet

Config .lintstagedrc.js from the root of the repository

module.exports = {
    '*.{js,ts,html}': [
        'eslint --quiet --fix',
    ],
    '*.{json,scss,md}': [
        'prettier --write',
    ],
};

So how can we achieve separate checking of our change with two Eslint configs?

To do this, we can refer to the lint-staged documentation and find the --diff-filter parameter. This is a Git parameter that allows you to separate files by how they are type of change (learn more here).

We should only be interested in two parameters — A (added) and M (modified). We will use them to call separate checks. So simple 🔥

Now our file for the pre-commit hook looks like this:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged --diff-filter M -c ./.lintstagedrc.adapted.js --quiet
npx lint-staged --diff-filter A -c ./.lintstagedrc.js --quiet

In addition to the main .lintstagedrc.js config, we also need to create .lintstaged.adapted.js, which will call our .eslintrc.adapted.js config

module.exports = {
    '*.{js,ts,html}': [
        'eslint --quiet --fix --config ./.eslintrc.adapted.js',
    ],
    '*.{json,scss,md}': [
        'prettier --write',
    ],
};

This completes the configuration

Testing

As a check, let’s perform some changes, namely:

create a component new-test-app-component identical to app.component
in the original app.component, add a few simple changes.

What for? The code of these files is almost identical, but different checks will be applied to them because of the type of change. In the first case, we’ve created conditionally new files that have problems and we don’t want to push them to the repository. In the second case, we changed the old files, but since we need non-blocking validation, we should just get warnings.

If we call git commit such changes, we should only get an error on the new code.

[STARTED] .lintstagedrc.adapted.js — 2 files
[STARTED] *.{js,ts,html} — 2 files
[STARTED] *.{json,scss,md} — 0 files
[SKIPPED] *.{json,scss,md} — no files
[STARTED] eslint --fix --config ./.eslintrc.adapted.js
[COMPLETED] eslint --fix --config ./.eslintrc.adapted.js
[COMPLETED] *.{js,ts,html} — 2 files
[COMPLETED] .lintstagedrc.adapted.js — 2 files

→ eslint --fix --config ./.eslintrc.adapted.js:
/Users/maksim/WebstormProjects/playground/example-styleguide/example-angular-app/src/app/app.component.html
   2:12  warning  Avoid calling expressions in templates  @angular-eslint/template/no-call-expression
  15:17  warning  Avoid using "$any" in templates         @angular-eslint/template/no-any
/Users/maksim/WebstormProjects/playground/example-styleguide/example-angular-app/src/app/app.component.ts
  12:13  warning  Output bindings, including aliases, should not be named as standard DOM events  @angular-eslint/no-output-native
  15:5   warning  Missing accessibility modifier on method definition test                        @typescript-eslint/explicit-member-accessibility
  15:13  warning  Unexpected any. Specify a different type                                        @typescript-eslint/no-explicit-any
✖ 5 problems (0 errors, 5 warnings) ✅

[STARTED] Preparing lint-staged...
[COMPLETED] Preparing lint-staged...
[STARTED] Running tasks for staged files...
[STARTED] .lintstagedrc.js — 3 files
[STARTED] *.{js,ts,html} — 3 files
[STARTED] *.{json,scss,md} — 0 files
[FAILED] eslint --fix --config ./.eslintrc.js [FAILED].

✖ eslint --fix --config ./.eslintrc.js:
/Users/maksim/WebstormProjects/playground/example-styleguide/example-angular-app/src/new-test-app-component/app.component.html
   2:12  error  Avoid calling expressions in templates  @angular-eslint/template/no-call-expression
  15:17  error  Avoid using "$any" in templates         @angular-eslint/template/no-any
/Users/maksim/WebstormProjects/playground/example-styleguide/example-angular-app/src/new-test-app-component/app.component.ts
  12:13  error    Output bindings, including aliases, should not be named as standard DOM events  @angular-eslint/no-output-native
  15:5   error    Missing accessibility modifier on method definition test                        @typescript-eslint/explicit-member-accessibility
  15:13  warning  Unexpected any. Specify a different type                                        @typescript-eslint/no-explicit-any
✖ 5 problems (4 errors, 1 warning) ❌

husky - pre-commit hook exited with code 1 (error)

As you can see, everything worked as intended, and now we can be confident in our style guide, and that new files will follow it without exception.

Resources

GitHub - Misterion96/frontend-style-guide-example: test repository to demo style-guide operation

I'm expanding my network of contacts on LinkedIn. I will be glad to meet new people

The Front-End Development we’re used to is dying

Maksim Dolgih — Fri, 09 Feb 2024 07:47:44 +0000

Why I think we’ll soon be back to where we started.

Introduction

Before the advent of SPA, web applications were typically multi-page. This meant that every time a user interacted with the application, the server sent a new page in its entirety and a browser loaded it again. Each time the user navigated between pages, a complete page reload occurred, and it could slow things down and create a less-than-smooth user experience. Similar applications were often built using server-side technologies such as PHP, Ruby on Rails, ASP.NET, etc., which generated HTML code on the server side and sent it to the browser.

Web developers were universal specialists, they were responsible for front-end and back-end parts at the same time. After the development of web technology and the demand of users, new solutions, which would allow them to work with an interactive interface without any problems or waiting were required.

This is how the first solutions for SPA using BackboneJs or AngularJs appeared. They allowed us to reduce the load on the server, whose resources were limited at that time, and to provide interactivity when working with a web page via JS because there was no need to wait for a new page with updates from the server.

That’s how the division into front-end and back-end parts appeared. The role of purely front-end developers has become more demanded and diverse. They began to specialize in creating user interfaces, working with HTML, CSS and JavaScript, as well as interacting with APIs and the server. On the other hand, back-end developers became more focused on data processing, application business logic, working with databases, and creating server APIs.

And that’s how we entered the era of React, Angular2, Vue and other web application development tools. Instead of creating simple forms and lists, now we have js-routing, state management, browser API, binding authorization tokens to requests, data mappings, etc.

We started to complicate things which were simple.

As a result of this approach, the problems were obtained:

Difficulties in communication and coordination. Api Contracts and communication method — HTTP 1.1, Websocket, GraphQL. JSON parsing and validation.
Divergence in understanding and knowledge. For example, you could develop a front-end application that creates many queries and consider it a normal and optimized SPA. But for the back-end, this is a very dangerous situation, because it now needs a lot of database accesses and proper aggregation of this data, which will affect its performance and maintenance.
Duplication of work. Most CRUD operations on the back-end had similar behaviour on the front-end. We didn’t just get the list from the server, now we put it in the store(), each user action is processed via dispatch() and waits for the request to be executed, after that we update the store via reducer() depending on the result — everything the back-end does to the database, we repeat on the front-end. (page reloading and restoring SPA to the current state from the server are also worth mentioning — a separate pain for the moment)
Difficulties in debugging and testing. You now need to consider possible integration issues and test them in the context of both sides of the application. Yes, you can create isolated e2e-tests for the front-end application, but they cannot guarantee reliability in Production. Yes, there is ZoD for validating server responses, but what percentage of its usage?
Increased development time and cost. Any change to an API contract requires two people at the same time. You can’t directly change a template to a server like you used to. You need rallies, split into separate tasks, business-analytic specialists and so on to make the change smoothly.
SEO. Since our app is entirely formed through JS, search engines could not get the app content and its navigation to index it properly, thus SSR and SSG solutions were required.
Security. Any critical data entered on the page needs to be hidden before being passed to the server. Also, a lot of personal information needs to be requested from the server for the application, revealing access tokens.

So, why is the usual front-end dying?

Just go to any resource and you’ll see how many job vacancies are open:

Python + Django
PHP + Laravel
NextJs + React
Nuxt + Vue

These are all bundles for server-based web application development. Thanks to the Hydration and Resumability approaches, the server can only render the modified part of the interface, without reloading the page.

What they provide:

The server application now does not need complex HTTP or WS contracts and support them on both sides, it can use better methods to exchange information with other services like gRPC.
The process of making changes is faster due to the lack of intermediate approvals, for 1 person the result the user sees immediately changes.
Tests can check the application holistically, eliminating integration tests and reducing errors.
You exchange only HTML markup, all “request-response” logic is hidden for a user
Why pass a lot of data in JSON to restore SPA to the right state when you can pass a ready template?
You don’t need to worry about browser compatibility and use babel and other tools, because JS code on the page is minimal.

With the advent of No-Code solutions, template generation via AI, huge server resources, and SEO requirements — the current number of front-end developers as well as tools are not needed to develop only the front-end part.

Business owners have a valid question — “Why do I need to hire a pure front-end developer and a pure back-end developer to do a simple application?”

Full-stack developer is not a management fad, in terms of saving on staffing, now it’s a mainstay. You don’t need a pure front-end developer, you need a developer who can make a whole application, performing simple operations with the database directly or other services and displaying the result.

Yes, there will undoubtedly remain a complex or "headless" applications that require front-end and back-end separation but most of the applications will move away from SPA and go down the way that was already there, but now we have a solution to those problems. With the advent of HTMX, any back-end developer with basic knowledge can create a web application. You don’t even need to know JS to create a single-page app with little logic now.

You may ask, “The front-end developer was responsible, not only for JS logic but for CSS and proper selectors, HTML and its semantics, does the backend developer have to know that now ?” — No, now an AI or “HTML layout designer” can do template generation based on layouts from Figma. The logic and interactivity of the HTML-template are now defined on the server.

Conclusion

Now is a good time to think whether you really need all these sophisticated front-end development tools and whether you should remain a pure front-end developer.

I expect current front-end developers to move to Fullstack qualification with a 60%-front-end, and 40%-back-end split to stay relevant specialists. HTMX is just the beginning, the vector towards NextJs or Nuxt tools will grow, and Angular-type frameworks will die if they can’t adapt to new implementations, although the Angular ecosystem already has prototypes on AnalogJs as well

Resources

Angular is not for everyone, and probably not for you

Maksim Dolgih — Thu, 11 Jan 2024 08:27:40 +0000

For 2023, Team Angular has made a lot of important changes which were asked for by the community, and that’s insanely awesome. But it wasn’t always like this.

In this story, I’d like to tell you about my 4 years experience of using Angular. First of all, I think Angular should not be your first technology to develop applications.

I want to highlight the problems which Angular creates and how they affect developers and team building. I will also try to give solutions to the problems I have identified if you already use Angular or want to use it.

Unfortunately, some teams or even companies are slow to upgrade for one reason or another, and you may find applications on Angular 8, 9 or 12. Therefore some of the issues outlined here can still be relevant.

If you are a junior developer, this article may also be useful for you and will help you with choosing your first development stack.

At the one moment, i may seem criticizing declarative approaches implemented by the Angular team — not at all. I don’t question that over time any low-level code becomes high-level code via abstraction and new features, making our work easier. Each new UI library tries to solve the problems of current libraries and offers improvements, providing growth and quality tools from year to year

The convenience trap

As we know, Angular is a UI framework, not a library. It positions itself as a self-contained solution for front-end application development. You don’t have a “zoo of technology” from app to app, everything is uniform and monotonous, but there is a downside to this. It’s easy to get used to the conveniences that Angular provides, and it gets more difficult to give them up later on.

ReactiveForms

At one time, the approach proposed by the Angular team, the form and its control are separated into an HTML-template and a JS-controller, really proved to be handy for form development.

The problem is different, we are so used to relying on validation from ReactiveForms that we forget that HTML natively provides us with all the attributes we need to validate input fields — min, max, pattern, required, readonly, etc.

What is this problem? — Once you get beyond Angular, it turns out that ReactiveForms doesn’t exist as a standalone library. You’ll have to re-learn how to develop forms — events (submit,change) and input field attributes.

Building an application

You don’t need to customize the application build, just run the “build” or “serve” commands to get started. You do not see the webpack.config.js or vite.config.js configuration files of the builder.

Can you say:

How is your application built?
Which file is the entry point?
Which tool builds your application?
How do your SCSS files become CSS?
How does HRM work?

If you work only with Angular, you missed the growth stage of gaining the skill to build an application. Webpack, Gulp, Rollup, Vite, Esbuild — you just don’t know it. If you’re asked to create a simple web page in HTML and SCSS without Angular — probably you can’t.

HTTP client

This is a convenient wrapper over XHR using the Observable pattern, given the recent XHR2 feature for SSR. It allows us to make queries with multiple parameters, track the progress of the query, and be able to convert the response to the desired data type with just a single parameter.

But as an angular developer, would you be able to say:

When was the last time you used native methods to handle HTTP — fetch or XHR?
Can you handle requests and errors globally without using an Interceptor?
Can you name ways to undo an HTTP-request without using switchMap?
Do you know of axios or node-fetch libraries?

Despite the convenience, we should know how to make queries without Angular. It surprises me when even Senior developers don’t know how to make a request before bootstrap application or about the existence of RxJS.Ajax

We must have an understanding of the essence of the request and response to be able to:

Handle errors
Parse the response
Track the progress of the request
Work with FormData

Charts and CSS-variables in Angular

Maksim Dolgih — Mon, 08 Jan 2024 19:47:35 +0000

Chart styling as we know it

Styling charts is another area where you need to use colors. There are a lot of color palettes for charts on the internet, but not every color palette can fit our brandbook and we have to apply “our” colors to maintain the overall style.

Often, it is a regular preset with hardcoded colors. This approach completely covers most graph styling issues if only 1 interface color scheme is used.

But what about supporting more than one color scheme?

Adapting charts for each theme is a challenge for developers. And if experience is not enough, you can even meet such implementations

backgroundColor = theme === 'dark' ? 'white' : 'black'

It’s scary to imagine if detailed stylization of each type of chart would be required. 😱

Let’s suppose developers have solved the problem of this approach and made a ColorsService that provides the desired color by colorName, hiding the actual value.

    export class ColorsService {
       private themeMap: Map<TThemes, Map<TColorName, string>> = new Map([
           ['default', new Map<TColorName, string>([
               ['primary', '#d75894'],
               ['secondary', '#9b3dca'],
               ['chart-color-1', '#526ed3'],
               ['chart-color-2', '#ea97c4'],
               ['chart-color-3', '#fee797'],
               ['base-1', '#808080'],
               ['base-2', '#bebebe'],
           ])],
           ['dark', new Map<TColorName, string>([
               ['primary', '#5e84ff'],
               ['secondary', '#0dd0ff'],
               ['chart-color-1', '#ffce56'],
               ['chart-color-2', '#36a2eb'],
               ['chart-color-3', '#ff6384'],
               ['base-1', '#c7c7c7'],
               ['base-2', '#bcbcbc'],
           ])],
       ])


       private paletteMap: Map<TColorName, string> = this.themeMap.get('default');


       constructor(
           private themeSwitcher: ThemeSwitcherService,
       ) {
           this.themeSwitcher.eventBus$.pipe(
               takeUntilDestroyed()
           ).subscribe(theme => {
               this.paletteMap = this.themeMap.get(theme)!;
           })
       }


       public getColor(colorName: TColorName): string {
           return this.paletteMap.get(colorName)!;
       }
    }

The service installs a new color map every time the theme changes. And the eventBus$ bus will notify the charts that they need to be refreshed.

By introducing the ColorsService abstraction, we have solved the potential problem of hardcoding colors in each component of the graph.

But we didn’t get rid of another problem — SCSS color variables and ColorsService are not related in any way, and therefore support for current and new themes will also be done by hardcoded colors. If the color scheme on SCSS changes, we’ll need to make changes here as well.

Can we make this ColorsService even more abstract, and not do any more theme support in it ? read more...

ng-deep is no longer needed

Maksim Dolgih — Mon, 08 Jan 2024 19:38:55 +0000

External library component

Let’s imagine that we are developing an Angular library of UI components for the rest of the teams.

We have a simple component that displays a header and a description

    @Component({
     selector: 'lib-external-component',
     standalone: true,
     imports: [],
     template: `
       <h2 class="header">{{header}}</h2>
       <span class="description">{{description}}</span>
     `,
     styleUrl: './external-component.component.scss'
    })
    export class ExternalComponentComponent {
     @Input()
     public header = 'External component header'


     @Input()
     public description = 'External component description'
    }

    :host {
     display: block;
     padding: 8px 12px;
     outline: 1px solid #b7b7b7;


     .header {
       font-size: 18px;
       font-weight: bold;
       color: red;
     }


     .description {
       font-size: 14px;
       color: blue;
     }
    }

Currently, when we change the theme, the component does not pick up our styles and remains unchanged

How can we style .header and .description?

There are three options:

Customize globally via a generic styles.scss file
Customize the style of the component in the parent component style with ViewEncapsulation.None
Customize the style of the component in the parent component by wrapping that in ::ng-deep

The first two options may be used depending on the situation and if they do not break the overall styling logic.

But ng-deep is a deprecated selector, and developers continue to use it as a “magic pill” for accessing styles of a child component.

Overriding styles in a parent component with theme support may look like this

    @each $theme-key in map.keys(variables.$themes) {
     $theme: map.get(variables.$themes, $theme-key);


     :host-context([data-theme="#{$theme-key}"]){
       ::ng-deep {
         app-external-component {
           .header {
             color: map.get($theme, "primary");
           }


           .description {
             color: map.get($theme, "secondary");
           }
         }
       }
     }
    }

Let’s check the support of our themes for the external component

We got the result we wanted but created a lot of complex code to style the component, which inherited all the styling issues for generic styling

Is it possible to simplify all this and even get rid of using ::ng-deep? read more...

Forget about SCSS variables

Maksim Dolgih — Mon, 08 Jan 2024 19:21:53 +0000

SCSS variables

In my career, I’ve managed to work on a lot of projects that used styling via SCSS, LESS, or Stylus. One of the main advantages of favoring them over CSS, besides “cascading”, was “variables”

They enabled:

To respect the DRY principle
To centralize shared variables for reuse via @import or @use
To create more abstract styles without hardcoding
To synchronize variable names with Figma tokens
To perform simple arithmetic and complex operations on variables
Variables did not go directly into the build, but were compiled into actual CSS values

Example of implementation

Let’s realize a basic example of SCSS variables application

Variables

    $primary: #d75894;
    $secondary: #9b3dca;
    $background: #fafafa;

Styling of elements

    @use 'variables';


    body {
     background: variables.$background;


     h1 {
       color: variables.$primary;
     }


     p {
       color: variables.$secondary;
     }
    }

It’s simple and intuitive *👍.*

New theme

But let’s say we need to add support for a dark theme for the current style scheme due to business requirements. *How do we implement it? *🧐

Experienced developers 🤓 will tell you that you should use mapping to substitute the correct value into the selector from each theme. In this way, we will provide extensibility for new themes.

Let’s change our simple variable list to a color theme map

    $themes: (
     "default": (
       primary: #d75894,
       secondary: #9b3dca,
       background: #fafafa,
     ),
     "dark": (
       primary: #5e84ff,
       secondary: #0dd0ff,
       background: #1b1918,
     )
    );

Themes applying

    @use "variables";
    @use "sass:map";


    @mixin setTheme($theme-map) {
     background: map.get($theme-map, "background");


     h1 {
       color: map.get($theme-map, "primary")
     }


     p {
       color: map.get($theme-map, "secondary")
     }
    }


    body {
     @each $theme-key in map.keys(variables.$themes) {
       &[data-theme="#{$theme-key}"]{
           @include setTheme(map.get(variables.$themes, $theme-key))
       }
     }
    }

Result

Yay, we’ve achieved the requested behavior. But at what cost?

Problems

As you can see from this small example, the amount of code to support the new dark theme has increased, and the old scheme had to be refactored.

Another disadvantage is obtained is the increase in the resulting CSS file due to having multiple themes simultaneously.

And hence its size, which takes time 📉 to download and parse.

    body[data-theme=default] {
     background: #fafafa;
    }
    body[data-theme=default] h1 {
     color: #d75894;
    }
    body[data-theme=default] p {
     color: #9b3dca;
    }
    body[data-theme=dark] {
     background: #1b1918;
    }
    body[data-theme=dark] h1 {
     color: #5e84ff;
    }
    body[data-theme=dark] p {
     color: #0dd0ff;
    }

As a consequence, with the growth of the code base and the requirement for stylization, we will get:

Increasing complexity of style architecture in the development of individual components
Maintenance and development of new features will be harder every time
Constant refactoring and need for regression screen tests

These problems will undoubtedly affect the speed of development, the quality of the result, and the convenience of developers.

Unfortunately, many libraries developed using SCSS, such as @angular/material, encourage this approach. Many developers are unaware of the recommended ways of styling via mixins, which leads to anti-pattern styling as well as the use of ::ng-deep

Those who have ever upgraded Angular in conjunction with @angular/material will understand UI problems in regression tests after upgrade if you don’t use the recommended way of component customization

So what’s the solution to this problem? read more...

Disable any animations in Angular by prefers-reduced-motion

Maksim Dolgih — Mon, 08 Jan 2024 11:12:11 +0000

Introduction

Animations today are an integral part of modern web applications. Animations help us to improve the perception of our application to the users by giving them feedback about their actions, which helps to make the user experience pleasant and memorable.

But there are cases when we should not use animations:

Users with restrictions. For them, animation is not an embellishment, but a distracting part that may be less accessible and interfere with the perception
E2E tests. It takes time to wait for each animation and transition. The more tests there are, the more time is spent waiting for them to be completed

For these 2 cases, you can’t build a separate application without animations, you need to have an opportunity to disable animations.

And there is an easy way to do this.

Prefers-reduced-motion

The prefers-reduced-motion CSS media feature is used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion. The setting is used to convey to the browser on the device that the user prefers an interface that removes, reduces, or replaces motion-based animations. ( You can find ways to activate it here )

Since this is an @media setting, all code can be handled in the @media block

@media (prefers-reduced-motion) {
  transition: all 0 linear;
  /* others styles */
}

Knowing about this customization, we just need to learn how to handle it properly in the Angular application read more...

DEV Community: Maksim Dolgih

Fear of AI made me create my own product

Where should I begin my story…

The more I read about AI, the more useless I felt

AI has changed the code development paradigm

The wrong question

I stopped asking "how do I compete?"

Capitalizing on your own skills

Expertise as a service

Assessment based on external characteristics

First steps

Development based on real needs, and almost the first customer

OpenGraph

Thanks to Apple for the tip

Style validation

Closed demo

Focus group

And at this stage, it is possible to cancel everything

I asked the wrong people

The same vector, but meaningful

Give Your AI Editor Perfect Context

This is not a conclusion, this is an opening

Full Website Audit | WebValid

Creating Envless Angular-application

Introduction

The main tasks of environment.ts files are:

Problem

Disadvantages of using environments.ts files

Task Statement

Solution 1 — Get config from the server

Scheme of work

Implementation

Run-time verification

Advantages and disadvantages

Solution 2 — Configuring a docker image

Scheme of work

Deploy Pipeline

Implementation

Run-time verification

Advantages and disadvantages

In conclusion

Angular 18 — Zoneless & Change Detection

Environment

Click event

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

Input + NgModel

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

AsyncPipe

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

Signal

Angular Signals is a system that keeps detailed track of how and where your state is used in the application, allowing the framework to optimize rendering updates.

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

Web API — setInterval

NgZone + Default

NgZone + OnPush

Zoneless + Default

Zoneless + OnPush

Summary

Conclusion

Bonus

“Eslint-Summary” — Hack your Eslint Config

Introduction

Example of problem

What’s the solution?

The main tasks of `environment.ts` files are: