DEV Community: Anton

Object-Oriented User Interface

Anton — Fri, 05 May 2023 08:36:43 +0000

Object-Oriented User Interface (OOUI) is a design methodology that aims to separate the implementation layers of a user interface. In contrast to actual Object-Oriented Programming (OOP), OOUI is more of a metaphorical expression that helps developers, QA testers, and designers reduce cognitive complexity and view UI development in small chunks. With OOUI, developers can break down the development process into smaller steps, see results earlier, and improve the overall efficiency of the development process. This article will explore the different stages of implementing OOUI, from the code abstraction stage to integration into a real application, and how it can help developers build UI components in an isolated environment, which allows for easier debugging and testing. Additionally, we will discuss why CSS styles should be implemented as independent units and not directly tied to functionality.

It’s not a rare case when developers are having hard time starting a new project or a feature. There are always a bunch of unknowns. In addition, almost every engineer faced the case of an “infinite” development process. When results are visible only in the last 5-10% stages of their work. OOUI helps to separate the process into smaller steps and see results much earlier than in the regular approach.

A UI component should be a black box. It receives an input, then returns an output. A component may have two types of outputs: visual representation, and output data.

Components should not be coupled. They should not interact with the store, or database or make HTTP requests.

The code (abstract class)

Let’s call it an “abstract component”. In the code internal logic, html structure, and styles are defined. There also we define which parts, sub-components it will use.

An abstract component is the code a developer writes. The major part of code writing is blind. Blind in the meaning that a developer sees only the code, but doesn’t see any visual representation.

This stage should be separated into small sub-tasks. Otherwise, a developer’s motivation shrinks if the blind phase lasts a long period of time.

This implementation should contain unit tests. The type of tests which usually check the correctness of the work of functions/methods. In other words, a function receives some data and is expected to return some data or perform an action.

Live example of a component (class)

Build UI components in an isolated environment where a developer can focus on a specific component instead of running the whole application. Isolation allows running and debugging a component without the fear of being impacted by other pieces of HTML, CSS, or Javascript.

That’s not a component in the real application. It’s a stand-alone example where a component receives an input, then shows or does something.

As input, we use mock data. An example should be created per each different usage of a component.

Storybook provides a wide variety of tools to run isolated components.

Integration into an application (object, implementation, integration)

After all the previous steps are passed a component is ready to be integrated into the real application. Usually, after the previous stages, there should not be a real reason for the component not to work as expected. Most issues that pop up will be related to the missing functionality. It’s not rare when during the development process an engineer forgets to implement some feature or didn’t have a clear enough technical overview.

This implementation should be tested via e2e tests. Accessibility tests are among them. Interaction tests as well. They show how a component reacts to user interactions such as clicks, keyboard interaction, scrolling, etc.

CSS framework

This layer purposefully was not mentioned in the OOUI approach. CSS styles should be implemented as independent units which can be reused in any part of the application without any relation to the functionality. Later these styles are applied via HTML classes.

In conclusion, Object Oriented UI (OOUI) is not actual OOP, but a metaphorical expression that means separating implementation layers in UI development. By using this approach, developers, QA testers, and designers can reduce cognitive complexity and see results much earlier in the development process. The OOUI approach involves creating an abstract component, building live examples of the component in isolation, and integrating the component into the real application. This process should be separated into small subtasks to keep developers motivated, and each stage should be tested thoroughly to ensure the component works as expected. While CSS styles are an essential part of UI development, they should be implemented as independent units that can be reused in any part of the application without any relation to functionality. Overall, OOUI provides a structured approach to UI development that can lead to more efficient and effective results.

The post Object-Oriented User Interface first appeared on Anton Mi.

Why Web Accessibility Matters

Anton — Thu, 04 May 2023 08:09:18 +0000

The internet has become an essential part of our lives. We use it for work, learning, entertainment, and communication. However, not everyone has equal access to the web. In fact, a significant percentage of people are unable to use many websites due to accessibility issues. As a Senior Front End Developer, I am aware of this problem and its importance. In this article, I will discuss why web accessibility matters and how we can implement it.

Web Accessibility Statistics

Did you know that only 5% of the most popular websites fully support accessibility? This means that a significant number of people are unable to use them. According to statistics, 15% of the world’s population has some kind of disability. This means that more than one billion people worldwide are affected by accessibility issues.

The population with differing abilities in the United States alone contains $500 billion in spending power, with global spending power estimated to be $1.2 trillion. By not providing proper accessibility, we are blocking people from working, learning, finding jobs, and enjoying the benefits of the internet. This is not only a matter of equality, human rights, and respect, but it also makes good business sense. Non-accessible websites are turning down a $1.2 trillion market share.

Devices have all the Accessibility Functionality, but Websites Have to be in the Right Structure

Most devices have accessibility features built-in, but websites have to be in the right structure to enable all the interactions. The internet has to be not limited to text-only interfaces. The information can be transferred in different ways. We need to consider different people with different types of disabilities and provide them with access to information.

Who Needs Web Accessibility?

Web accessibility is not only for people with limited abilities. It is also necessary for people from lower socio-economic layers, people with old and slow devices, and people with low internet speeds. By not considering different people, we are taking a technocentric approach, which is not right.

Implementing Web Accessibility

Implementing web accessibility is not easy, but it is essential. Many developers don’t understand accessibility, while others realize it’s needed but don’t know where to start. We can start with semantic HTML tags, headings order, search, ARIA attributes.

Web accessibility is essential for everyone. We need to provide equal access to the internet and information. Modern web technologies almost have no limits. They can support a variety of colours and shapes. The main problem is not the technological limitations, but the fact that websites are produced for an average user. We need to think beyond the average user and provide accessibility for everyone. The internet is a tool to transfer information, and it can be transferred in different ways. Let’s make it accessible to everyone.

Helpful resources

Learn accessibility:
- https://a11yphant.com/
Information about accessibility:
Stats:
- https://webaim.org/projects/million/
- https://webaim.org/projects/screenreadersurvey8/#intro
Tools:
- Axe vscode linter
- Chrome devtools lighthouse
- Axe devtools

The post Why Web Accessibility Matters first appeared on Anton Mi.

How to create reliable and scalable frontend applications

Anton — Fri, 21 Jan 2022 14:41:33 +0000

Intro

A software engineer day to day work usually focused on some specific application or even piece of that software. When a long period of time developer works on only one program he may experience difficulties in the case he needs to start with a new project.

In this article, I would like to share my findings which come from frontend applications built by me in recent years.

Overview

First, a walk when planning a new application it has to be decided what is the main purpose.

There are two main directions for a web-based application:

A website with a public content
Web/Native application

For content websites, it’s highly suggested to use server-side rendering such as Next.Js, Angular SSR, Gatsby, or similar. These technologies will provide a better performance as well as better Search engine optimization.

On the other hand, web or native applications are used when it’s required a high level of in-app interactions.

In addition, it has to be defined whether the application will have offline mode or features. In that case, the application is considered a Progressive Web App and the usage of service workers will be required.

Proposed Technologies list

State — Redux
React, react-router
UI — MUI or Bootstrap
Linting — Husky, eslint, prettier
Testing — Jest
CI/CD — Gitlab

Folders structure

The following folder structure can be used for the medium as well as small apps.

Components — all components. Each can have input/output
Containers — components defining specific layout
Pages — A page will use one of the containers and contains components.
Routes — contains route declarations
Config — Constants
Services
Api specific files
Authorization
General services — such as traces/logs, system notifications, etc
Store — Redux’s store files. Such as reducers
The root folder will contain package.json, eslint, etc.
.ENV — environment-specific constants

For large and multi-application projects consider reading the article “Semantic Grouping Folders with Nx”.

General essential features

Logging, tracing
Authorization: Send credentials -> receive token. All manipulations with sensitive data should be working via the Authorization header.
Centralized system notifications
Generic pop-ups: Confirmation popup
User activity statistics: Backend should save each user action/request for further analysis or an external service can be used.

Code modularity

Modularity is achieved by separating functionality into components. Each of them should have one responsibility. Components will have Input/Output data.

State management

Redux is one of the suggested options for state management. State flow in react app unidirectional **and **immutable. Immutability allows stability and debugging features such as states history. Where it’s possible to go “back in time” analyzing all the state changes.

There are two types of components:

*Stateless *— has I/O data and does not manage states
*Stateful *— manages states and transfers into the components. Also are dividing when to transfer state to regular components in order to reduce component rerendering

Performance

APi calls In browser *caching *— rarely updated data should be stored in Browser’s cache. It is achieved by setting cache headers for HTTP responses.
App files caching — images, fonts, js bundles should be cached in the browser.
Reduce components re-rendering by limiting states flow.
Lazy loading — the application will load only necessary bundle files. Achieved by code splitting techniques.

Code quality

In general, the code has to obey industry best practices. The code has to be easily readable and built of small components/methods/classes where each has one responsibility focused.

However, each developer may have his own code style preferences. Therefore it’s strongly suggested to force project-specific code standards. Alignment with code standards can be achieved by using eslint library. Pre-commit hooks will secure that no non-standard code arrives in the Git repository.

In addition code formatting could be done by Prettier. This operation can be attached to the pre-commit hook as well.

Code readability can be achieved with the help of the CodeMetrics, SonarLint, SonarQube vscode plugins or similar. The tool will analyze the cognitive complexity of the code and will suggest improvements. In general functions/methods should be short and avoid multilevel nested loops or conditionals.

Type declarations are another important point in frontend development. Static type definition provides greater reliability as well as readability. The application should be written on TypeScript which has wide support and community.

Unit testing

Each component has to be test covered by at least 70%. Jest is one of the well-supported libraries for that purpose.

Versioning

Git is the most preferred option for version control.

Each commit has to obey commit message standards. This link gives a good explanation. Following the standard will provide good readability of the app development history.

Deployment

Gitlab can be used for managing deployments and Continous Integration. Repository updates have to be pushed as new branches. On each commit Gitlab will run unit tests.
After the code review and pipeline passes, a merge request can be created. After the MR is approved commits will become a part of the master/main branch and the original branch will be erased.

The application should have multiple deployment environments such as Stage, Dev, Production. The stage will have the latest master version. After it passes QA tests it can be promoted to Production.

Accessibility

The application has to be accessible to people with all, abilities. It has to support screen readers, color schemes, and font size adaptability.

Chrome Lighthouse dev tool can be used to analyze the level of accessibility covered by an application.

UI

Use one of the well-supported UI frameworks such as Mui or Bootstrap
Multiple themes support. At least two: light and dark modes should be
Responsive — mobile-first approach. Guarantees the app will not lack functionality on all devices.

Security

At least the following points should be considered when creating a Frontend application.

Frontend:

User-generated data sanitation. React and Angular natively support sanitation.
Auth token secure storage in HttpOnly only cookies. Refer to the explanation on the OWASP page.

Backend:

Limit number of HTTP requests per user in order to avoid DDOS attacks
Limit login attempts
OWASP rules

Migration

Styles separation — when creating custom styles separate a set of SCSS files containing all the common styles. In the case of migration to another SPA library, the styles can be reused.

It is always difficult to migrate a large codebase. For instance, an Angular app migrates to React. In the major part of the cases, each SPA library has its own architecture and it will not be possible to copy the components.

However such tools as NX or Module Federation can manage micro frontends and allow gradual migration from one SPA library to another.

Conclusion

The current article discussed the main best practices which should be considered when planning a new frontend application. All the mentioned techniques may seem like an exaggeration. Though each of them increases the maintainability and reliability of an application.

Let’s recap what we learned:

Define the type of the project if it’s content-based or app
Performance
Modularity
State management
Code quality: Typescript, linting
Stability: Unit tests
Versioning: git
Deployment: GitLab
UI: MUI, Bootstrap
Accessibility
Security
Migration

Photo by Marc-Olivier Jodoin on Unsplash

Code quality: pre-commit linting

Anton — Wed, 12 Jan 2022 19:22:14 +0000

In 2012 I started my attempts to develop web applications. As the first project, I chose to build a website constructor. This kind of software requires a ton of client interactions. Since then I knew only one library able to assist me with that mission. It was the legendary jQuery. I put all my efforts to achieve the interactivity goals. And the end result was pretty good. Even now I am still proud of it. It was my first real project. Though since then I knew nothing about the code quality and architecture patterns.

“The code works, don’t touch it”

When I finished building the initial phase including backend and frontend parts started to mention that I am not feeling so comfortable with the code I built.

jQuery gave me a lot of freedom to structure the files and folders. And I have to say it was bad freedom. So my code looked like you were leaving your dog alone at home. All the items were in total disorder and everything upside down. It wasn’t a total disorder, but just a brand new order for each component of the application.

Initially, all was smooth and clear. I was holding all the code base in my mind. After a while, it grew larger and that’s when the problems started. Each time I needed some component I had to dig up all the code to find the component. Though it’s another topic.

The main issue with the code was the fact I was writing the code in different code styles. One time I used tabs, the next time I used spaces. Variables, methods, and constants were written in different cases without obeying any code style.

From one side it was my problem not knowing coding best practices. On the other hand, junior developers cannot know all these nuances.

The problem

Every programmer may have his preferences on how to write code. The code style may differ between coders. Nothing bad in that fact. We are all humans and have our perceptions. However, usually, software engineers are working in teams. That’s the point where problems are starting.

Imagine you’ve been given a task to do a code review. You are trying to read the code, but after a while realize you can understand nothing and the main issue in the code style. Variables are written in unusual cases, as well as functions. Lines are too long and go out of the screen borders. Indents not aligned. Once there is a line of space, another time no lines at all.

The code style is not the only and the biggest problem. The right usage in code itself means a lot for performance as well as readability.

What do I mean? For instance, let was used for a variable that has a single value assignment. If it’s not going to change why aren’t you using const? Or another case. You’ve imported some libraries to a file but afterward decided not to use them. It should be removed from the file if it’s not used otherwise the application will have a larger size than it requires.

Example

Let’s compare linted and prettified code against the same code lacking linting. For that purpose, we will take Angular code.

Non-linted and non-formatted:

    import { CrudService } from 'src/app/services/crud.service';
    import { Component, OnInit } from '@angular/core';

    @Component({
      selector: 'app-example',
      templateUrl: './example.component.html',
      styleUrls: ['./example.component.scss']
    })
    export class ExampleComponent implements OnInit {

    constructor( ) { }

    ngOnInit(): void {
      }

    public someMethod() {
        let rabbitName = 'Walter'; return rabbitName;
      }

    public anotherMethod(){
        let one = 1;
     let two = 2;

    return one+two;
      }
    }

Linted and formatted:

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

    @Component({
      selector: 'app-example',
      templateUrl: './example.component.html',
      styleUrls: ['./example.component.scss']
    })
    export class ExampleComponent{

        constructor( ) { }

        public someMethod() {
            return 'Walter';
        }

        public anotherMethod() {
            const one = 1;
            const two = 2;

            return one+two;
        }

    }

As you can see the second example has nothing unnecessary inside and is more readable. This is only a tiny demonstration. Imagine having an app containing dozens of files and thousands of lines of code.

Linter is the solution

It’s good to keep all the best practices in your head. However, even senior developers may miss something unintentionally. There are a couple of tools able to assist developers to keep their code clean and structured.

Eslint

Linter is the main instrument to assist with code style and syntax issues. You may want to use the **eslint **extension if you’re working with vs code. It analyzes the code in a live mode and proposes improvements.

Prettier

There is another useful tool for developers called Prettier. It also can be used as a vscode extension. The main purpose of the instrument is to format the code in a visually nice manner. It aligns all spaces and indents providing developers with beautiful code formatting.

Only having those extensions within the IDE doesn’t guarantee all the developers on the team are responsible enough and going to be using the tools.

How do we ensure no unlinted or unformatted code will appear on the git repository? Unfortunately, none of the large frontend libraries/frameworks are supporting forceful code linting. Most of them have lint cmd commands which are running linter and verifying the code following standards.

Anyways there are npm packages able to assist with this mission.

Husky

There is an npm package coming up to help us to secure none of the unclean commits will drop into our git tree. It’s called Husky. The main purpose of the package is to create hooks for git operations. That way it’s possible to bind Eslint and Prettier actions on the pre-commit hook.

Please refer to this StackOverflow question. Where there is a basic setup for Husky. In addition, it explains how to use the pre-commit hook.

Recap

The current article discusses the necessity of code formatting and linting. Keeping eye on code quality is essential especially in large projects when it’s easy to mess up.

Lint — script responsible for alarming developers when the code violates standards.

Code formatting/prettification — an operation that makes the code more human-readable.

Getting rid of NgModule in Angular. Javascript

Anton — Wed, 05 Jan 2022 20:42:21 +0000

Working many years with angular I found it hard to create the structure of a project. The main reason for that struggle lay behind the way Angular interacts with components and modules. The following article explains what is the issue with NgModule and whether is going to change in the foreseeable future.

Builtin lazy loading mechanisms

Angular has NgModule based architecture. In other words, each application has at least one NgModule which connects all the components and routes together. It is a practical approach for applications structure. An application has a central unit that contains all the declarations. That’s right when we are talking about small web apps.

When working with large Single Page Applications performance becomes a critical pain point. It is a time to start thinking about optimization. One of the ways to reduce loading times is to minify application size on the first load. This goal can be achieved with lazy loading. The technique is supported by angular routing mechanisms.

The technique allows loading specific parts of an application only when needed. Here is the full documentation on how to implement lazy loading within Angular framework.

What is wrong with NgModules?

Up to now, all seems correct, right? Let’s zoom in to see whether potential issues could pop up.

For instance, we will take the Angular Material UI. The framework should comply with best practices because it is built and maintained by the Angular team. Looking at the components provided you may mention that each of them has its own NgModule. It is done to allow importing of a single component without grabbing all them and overloading the application.

What does all that mean for me as a developer? Practically you will need to create a NgModule for each of the components. Thus double action on each component creation.

For newbies, the concept may appear quite painful. To be honest for me to work in this way is still frustrating.

VueJs components interaction

When I started to work with VueJs I didn’t feel any discomfort. Just after some period of time mentioned I am doing fewer actions to achieve the same component interactions than I was doing in Angular. “How could it be?” I thought. Just after side by side comparison, figured out what was missing through all the development process with VueJs. The answer was “modules”.

In VueJs all is based on components. Do you want to create a page? Make a component. Do you want to create a reusable UI piece of code? Make component! Nothing more. Just that easy.

Aren’t modules making a more coherent structure? Correct me if I am wrong, but I didn’t mention any practical benefit of this additional architecture layer yet.

Is it going to change?

Yes, the Angular roadmap gives all Angular developers a ray of hope. The proposal was explained and discussed in this “[Complete] RFC: Standalone components, directives and pipes — making Angular’s NgModules optional”.

Yet, pay attention to this statement:

This proposal is not trying to remove the concept of a NgModule from Angular — it is rather making it optional for typical application development tasks.
At the same time we believe that it paves the path towards greatly reducing the role of NgModule for typical development scenarios — to the point that some time in the future it would be possible and reasonable for us to consider removing it altogether.

To conclude

Getting rid of modules is the first step towards Angular architecture simplification. So far I see only benefits in that act.

Who knows maybe in the future Angular will adopt a functional components approach as React did instead of classes.

Frontend unit testing

Anton — Thu, 23 Dec 2021 10:32:13 +0000

Javascript was invented a few decades ago. Initially was used for small in-browser interactions. Though in recent ten years javascript passed through huge evolution. It is mostly related to the invention of SPAs (single page applications) and NPM package manager. Which gave superpowers to the already known Javascript. With those transformations, the code base started to become larger and more complex. A larger code base is more vulnerable to errors. In this article, we will see how to make a codebase resistant to errors. At least to reduce part of them.

What is Unit testing?

We are not gonna go into details about what the Units are. Briefly saying, software engineering best practices suggest separating the code into small components or modules. Such separation will increase the maintainability and readability of code.

Going back to our topic. Unit tests are responsible for keeping our code correctly functioning when introducing new changes. They are small interactions with specific functions or components. As a result of these interactions, unit tests expect to receive specific responses from the component/function. At least the core functions of an application should be tested.

To simplify, let’s use a real-life example. You want to buy a box of six eggs. What should you check?

Is it a box of eggs or something else
Are there eggs at all
Are there six eggs or less
Is there a broken egg
Are they the size you wanted

What if I don’t write unit tests?

Nothing happens. At least from first sight. But as the larger your codebase grows harder becomes to maintain it and debug. Sometimes you may introduce a bug and don’t mention it. Then after weeks of development, it pops up and crashes the application. You start panicking and debug every bit of your code. After hours or even days spent debugging you figure out the problem was in a small mistake.

What if somebody told you could’ve avoided this situation? Or at least reduce the number of them. One of the solutions is Unit tests.

Sometimes it may seem boring to write tests. You just want to be in the free flight with the code with creativity fireworks exploding every single minute of the work. Though I’d like to warn you (like your grandma) if start falling you didn’t take a parachute.

Yes, there are cases when you don’t need any tests. For example, you develop a prototype that never will go to production. Here is the goal not to develop a stable app, but a proof of concept.

How do they work?

In the modern javascript environment, there are a variety of libraries making testing comfortable for developers. Some of the most popular are Jest, Jasmine. They have built-in methods. The core are “expect” methods. Which take a method/component and check whether the output is the one we expect to receive.

Let’s take jasmine for example.

    describe("A suite is just a function", ()=> {
      **let **a;

      it("and so is a spec", ()=> {
        a **=** **true**;

        expect(a).toBe(**true**);
      });
    });

When to write them?

There are a variety of approaches to unit tests. Each developer has his own preferences related to testing. Also, each company has its guidelines and requirements for testing software.

TDD approach suggests writing tests beforehand and then implementing code. However, this approach fits systematic software development when almost everything is described already in the technical overview. In many cases, you choose solutions and write methods in the process. That means methods written before tests.

Even in that case I strongly suggest writing tests step by step. You’ve written a method, write unit tests. Otherwise, you end up with a long code with many methods or dependencies involved. And when you will start testing it can turn into a strong headache.

Mocking data

The goal of unit tests is to check specific units such as class, component, function. That means you need to ignore all non-relevant code. Yet many components have external dependencies on third-party libraries or other components. In this case, within the unit test we need to replace these dependencies with static code which will simulate responses and states.

Jasmine for instance has already built-in methods for mocking data. Such as createSpyObj or spyOn.

Test coverage

Each time you build tests ensure they are really testing what you need. There are many cases when test passes and it is green, but in the reality, it didn’t check anything or checked the wrong statement.

Another mistake could be not putting expectations to the test. But this case is easier to discover because testing frameworks such as Jasmine will write “NO EXPECTATIONS…” before each tets case lacking expectation. Even the test will pass, though you will see it’s useless.

Be careful with test coverage. You have to check whether all or most of the cases are covered by the test.

To conclude

The main goal of the unit tests is to provide stable work for development teams.

Let’s recap:

Test all possible case scenarios
Check the level of code coverage
**Mock **any external classes/services
Don’t test third-party libraries.
Write tests as soon as you progress with the development. Don’t wait until the end

Sources:

Jest
Jasmine
Cover gif. “Completely obliterate the car”.

How to create a simple CSS only dropdown

Anton — Sat, 18 Dec 2021 13:04:05 +0000

This is a small CSS tutorial I decided to write this morning. Maybe later I should do more.

Today's topic gonna be CSS based dropdown menu. The code itself was written from scratch. It took me around 30 minutes. The only external code was used is CSS reset.

I am using Pug to write quick HTML and SCSS.

The first thing is to create a dropdown container div.

Then put inside a button. It will serve as a trigger. Then we put inside an unordered list with a few items.

.dropdown
 button.trigger-btn Hover me
  ul.dropdown__items
   li.dropdown__item Menu item 1
   li.dropdown__item Menu item 2
   li.dropdown__item Menu item 3
   li.dropdown__item Menu item 4

Then we add padding, background color, etc.

For color selection, Material colors were used. There you can quickly choose some nice-looking colors.

Shadows for the dropdown were generated with a help of a CSS generator.

We finished with styles and HTML. Now, how actually does the magic works?

In order to have a dropdown appear on mouse-over we need to set :hover pseudo-class. When the .dropdown container is mouse-over.dropdown__items element becomes visible by adding display:block CSS rule.

Check out the code example to understand better how it works:

How to create a parallax on pure Javascript

Anton — Tue, 07 Dec 2021 10:58:24 +0000

Everyone at least once has seen parallax effects on a website. They could’ve been simple. Such as a static background on a specific spot while scrolling. On the other hand, these effects can be extremely complex. However usually visually this effect looks impressive.

Parallax always amazed me. How it’s done in web development. It seemed to me so complex and unachievable. Then after a couple of years of contemplation of beautiful websites using this technique I decided to give it a try.

What is parallax?

The meaning of the word “parallax” refers to a specific technique used in computer graphics. Multiple layers move at different speeds, while the user scrolls a webpage. This number of movements creates an optical illusion. To be honest the technique is not new. It was used in the early 1980’s Super Mario Bros game to create the sensation of depth. Then this graphic trick got a second life in web design.

Tech stack

As already mentioned above here I used vanillaJS (pure JavaScript). Pug templating language was used to accelerate work with HTML. As well as SCSS instead of pure CSS.

What was created and how it works?

It started as an experiment. Though at the end turned into a small library. It requires a small HTML and a few Javascript functions. We have specific classes. Each .prlx-item-inner can have an animation. Also, each one can have multiple animations. So you can combine for instance zoom with spinning.

This code can be used on any HTML website. Javascript (function () {} ) wrapping will prevent conflicting with any other library.

Reusable classes list

Directional movements classes: let, right,top,bottom
speed- — Can have any number. Ex.: speed-3
spin — spinning object
zoom — zooms out

To structure

The basic elements needed for this are the container and the number of inside elements which gonna is moving on scroll.

Here is the HTML code:

#prlx-container
  .text-top
    p Scroll down to see the parallax effect
  .row
    .prlx-item
      .prlx-item-inner.left.speed-3
    .prlx-item
      .prlx-item-inner.top.speed-2.spin
    .prlx-item
      .prlx-item-inner.right
    .prlx-item
      .prlx-item-inner.left.speed-5
    .prlx-item
      .prlx-item-inner.zoom.speed-2
    .prlx-item
      .prlx-item-inner.right.speed-5
    .prlx-item
      .prlx-item-inner.left
    .prlx-item
      .prlx-item-inner.bottom
    .prlx-item
      .prlx-item-inner.right.spin
  .side-dots

In this example I set .row element as position:fixed;. So it’s always will be visible.

.prlx-item-inner has to be position:absolute; this way we can control it with x,y (top, left) coordinates. It’s parent .prlx-item is position: relative;. That way it’s children will move relatively to the parent instead moving relatively the whole viewport.

Javascript

There are three functions responsible for movements. zoom(), spin(), move() respectively.

checkMovement() check which direction, speed and animation type is set to an element. ThenbindMovementsToElement() binds specific animations to an html element.

At the end of the file we have window.addEventListener(‘scroll’, ()=>{}) event which triggered each time scrolling happens and activates animations on html elements.

That’s it. Nothing more. The code is simple and quick.

Here is the code itself:

Conclusion

It started as an experiment. Though at the end turned into a small library. Maybe one day I will publish it on github. At the moment anyone can try it on codepen and use on his own website.

How I improved nested arrays performance in our MongoDB

Anton — Tue, 30 Nov 2021 20:10:15 +0000

How it started?

In 2019 I started to work on fanficus.com. Which is Russian speaking fiction writers/readers social network. Spent around a month thinking about how to structure the architecture of the web application. In the beginning, I didn’t know exactly what I am working on. Initially, it seemed a small side project for a few months.

When starting I decided to choose to MEAN full-stack (MongoDB, Angular, ExpressJs, NodeJs). However, it was a dilemma what to choose MySQL or MongoDB. Because previously I had some experience with MySQL and I knew SQL databases had a major market share in web projects. MongoDB was chosen because it is based on javascript objects, therefore it’s natural to use on the current stack.

The largest part of the web app is based on posts. They can be of different types and include a lot of parameters. Such as age rating, genres, tags, etc.

Understanding that the database has to be flexible I decided to avoid nested arrays of objects. Because that was creating a risk of misalignment between collections. For example, there is a post that has genres array objects. Genre contains title and id. But at the same time, there is a genres collection. Where all genres are listed. We use it when creating new posts.

post: {
  genres: [id1, id2, id3],
  tags: [id1, id2, id3]
}

Now, what happens if we rename a genre? in the genres collection, it is renamed, but in all posts containing the genre, it remained with the old name. So we end up with a post that contains inexisting genre.

Yes, you may say each time we update the genre we can update all the posts containing this genre. Though I wanted to avoid this obsolete load on the database.

The way was chosen is to store in the post only an array of IDs of genres. It seemed the most effective solution. Anyway, it was more optimal than going in an SQL way and having three collections: posts, genres, post-genre.

Problem

The website was released and worked well enough. Even on each request, it was populating all the posts with an age rating, genres, etc. As a result on the frontend, I was receiving the full objects and didn’t need to run additional queries.

However, after a few months number of posts increased. We started to mention slow loading times. After spending some time on the investigation figured out what was the issue. And the problem was in an ****array of IDs. Each post contained up to ten such nested arrays. Meaning each post had to run ten population commands.

PostModel.find({}).populate(‘genres’).populate(‘tags’).populate(‘ageRating’).exec();

It was not the only problem. The way we run search queries on posts also was impacted by the way we store nested IDs. Each time we run a search on the website it was seeking tags titles, then we took IDs and run a posts query.

const tagsFound = await TagModel.find({‘title’: { $in: keywordsRegArr }}).exec();
const tagsIdsArr = tagsFound.map( tag=> tag._id );
PostModel.find({tags:tagsIdsArr}).exec();

In addition to page load performance, we saw our MongoDB Atlas server was charging too much.

How it was solved?

After long arguments with myself, I saw that the most optimal solution will be to store the full objects inside each post. Yes, it was increasing database size. However, it was solving the main issue with performance and querying.

Now posts collection looked this way:

post: {
  genres: [{id: 1, title: 'one'}, {id: 2, title: 'two'}],
  tags: [{id: 1, title: 'one'}, {id: 2, title: 'two'}]
}

It was meaning now each time we search posts we don’t need to search tags to get their IDs. Now it’s just running **text search **over all posts.

One more important thing that was added is caching. For that one, I used node-cache npm package. Part of the queries is cached on the NodeJs. That way we reduce the load on the database. Some requests are cached for hours, some for minutes.

Result

As already was said, now we were able to run a text search query and avoid multiple populations.

Post objects were retrieved from the posts-collection directly without any manipulations.

As a result query and loading times were reduced at least by four times. And it’s on the current database which is in comparison to social networks is small.

Drawbacks

Now each time we change genres, age ratings, etc, we need to update all posts containing these objects. But these items change rarely, so we can absorb this one.
Then also I had to modify search queries from the client app. Because post-collection contained a nested array of objects instead of an array of IDs
Storage size increased. In the end, the database size didn’t increase significantly. We didn’t even mention it.

Conclusion

The project was released a year ago. At the moment we have 22k users and it’s growing. We have a lot of features implemented, though a lot more are in development. There are many issues we meet on the road. However, overcoming them and conquering the next mountain peaks.

Now the database refactoring is tested on our testing server and gonna be released soon.