DEV Community: Nik Poltoratsky

How to Create an Admin Panel for Your PostgreSQL Database on Railway Cloud

Nik Poltoratsky — Tue, 12 Mar 2024 13:27:27 +0000

Creating an effective admin panel for your PostgreSQL database hosted on Railway Cloud can significantly streamline the management of your database records. This guide will walk you through the steps to build a fully functional admin panel using UI Bakery, a visual application builder. This panel will allow you to view, edit, add, and delete records, as well as filter data for easier access.

If you prefer video content, here’s my video explaining how to make an admin panel for the railway-hosted PostgreSQL.

Step 1: Connect Your Database to UI Bakery

Navigate to Data Sources in UI Bakery

Start by going to the data sources section within UI Bakery.

Connect to PostgreSQL

Click on the "connect" button and select PostgreSQL from the list of options.

Enter Database Credentials: Input the required credentials for your database. You can find these details in your Railway dashboard under your database's "variables" section. The necessary credentials include the database host, password, port, and user.

Connect Data Source

After filling in the credentials, click the "connect data source" button. Once connected, you should be able to see your database's table structure.

Step 2: Create a New Application

From your workspace in UI Bakery, create a new application. For this example, we'll name it "Clients Admin".

Create the First Action: This action will load data from your database table. Execute this action to ensure it works correctly and that the data preview is loaded.

First of all, press "Create action"
Then choose the "Clients" data source you've added in the previous step
In operation select Load Table
Finally, choose the Clients table to load

Execute the action to make sure everything is connected and works properly:

Step 3: Display Data

Configure a Data Table

Add a table on the screen to display the loaded data. Adjust the size, remove any unnecessary columns for clarity, and customize the display of certain data in columns settings.

Step 4: Enable and Configure CRUD Operations

First of all, scroll to the actions section of the table configuration and enable add, edit, and delete buttons.

Then scroll down to the triggers section and create new actions for On Create, On Edit, and On Delete triggers.

Editing Records

In newly created onEdit action choose:

Type - Clients data source
Operation - Update Row
Table - Clients

Then in Configure filter to update record(s) section define which records have to be updated - add an id filter that equals to the {{ui.clientsTable.editedRow.data.id}} - edited row id.

Toggle JS mode in Configure record fields to update section and pass {{ui.clientsTable.editedRow.data}} inside - updated record from the table.

After editing, execute the load action again to refresh the data displayed on your panel.

Adding New Records

In newly created onCreate action choose:

Type - Clients data source
Operation - Create Row
Table - Clients

Then in Configure new record fields section add {{ui.clientsTable.newRow.data}} - a new object submitted from the table.

After submitting a new row, execute the load action again to refresh the data displayed on your panel.

Deleting Records

In onDelete action choose:

Type - Clients data source
Operation - Delete Row
Table - Clients

In Configure filter to delete record(s) section define which records have to be updated - add an id filter that equals to the {{ui.clientsTable.deletedRow.data.id}} - deleted row id.

After deleting a row, execute the load action again to refresh the data displayed on your panel.

Step 5: Implement Filtering

Add a Filter Input

Place an input field (e.g., findByName) in your admin panel's header for filtering capabilities.

Configure Filtering

Link the input field to the load action with onChange trigger, adjusting the action to include filters based on the input value (e.g., records where the name matches the input value).

Conclusion

By following these steps, you have created a comprehensive admin panel for managing your PostgreSQL database on Railway Cloud with UI Bakery. This panel not only streamlines the process of viewing and manipulating database records but also enhances the efficiency of database management through filtering and CRUD operations. Join UI Bakery to further expedite your application development journey.

How to create Supabase admin dashboard?

Nik Poltoratsky — Tue, 13 Feb 2024 14:36:07 +0000

In this article, the database meets ui!

You will find how to build an Admin Dashboard on top of Supabase using UI Bakery:

Connect Supabase to UI Bakery
View Supabase data
Add form to edit records
Publish an app to make it available for your users

Supabase is an open-source Firebase alternative. It’s built on top of PostgreSQL and stuffed with many features such as database, auth, storage, REST, and GraphQL APIs. Everything is backed in a modern intuitive no-code UI. All that makes it a good choice for your database while UI Bakery will focus on the UI.

In this tutorial, I’ll show you how to create an admin panel for your supabase database using UI Bakery. Here is what we’ll build - an admin panel that can view data from the database and provides a user-friendly interface for records editing:

If you prefer video content, here’s my video explaining how to make a supabase admin.

Connect supabase to UI Bakery

First things first, let’s connect the supabase db to UI Bakery.

Open your supabase project, go to the “Project Settings” → “Database”. Here in the “Connection parameters” section, you’ll find the database credentials required for connection:

Now, in your UI Bakery workspace, go to “Data Sources” → “Connect”. In the connection form, fill in the credentials copied from the “Connection parameters” section of the database settings.

Press “Connect Datasource” and supabase integration is done. Now we can build an actual application.

View supabase data

In the UI Bakery workspace, click “Create app” → “Create new app”, fill in the application name, and click “Create app”.

Now you’re in an application builder. Here you can see 3 major panels:

Left - components list, here you will find components to add to the screen.
Right - Selected component configuration where you change component properties.
Bottom - actions panel - all the application logic lives here.

Let's focus on data first - create a new action that will load data from the connected supabase db. In the actions panel click “Create action”, choose your supabase database connected before, then “Load table” and finally choose a table to load. When configuration is done click “Execute action” to preview the data.

When data is loaded in UI Bakery we can start building UI. First of all, let's add a table to view records. Find the Table in the components panel, then drag-drop it on the working area.

Using the component settings panel configure what columns are displayed and change the title of the table:

At this stage, you have an application that loads data from the supabase database and displays it inside a good-looking table. Now it’s time to focus on records editing.

Add form to edit records

Drag’n’drop a form component from the components panel to the working area to the right of the table. When a component is in its place we have to configure it to display data from the selected row of the table.
Locate the Data field in the “Component settings” sidebar and reference the table’s selected row data using variable syntax - {{ui.clientsTable.selectedRow.data}}. Curly braces allow using variables in components settings fields. {{ui - means we’re referencing UI component from the workspace. {{ui.clientsTable - means we’re referencing a component called “clientsTable”, and {{ui.clientsTable.selectedRow.data}} means to get the data from the selected row of our table.

When the Data field is set, hit the “Regenerate structure” button and the form will apply the referenced table structure to itself so you don’t have to configure the form structure. It will just be the same as in your table.

To make this form update records in the database you have to scroll the “component settings” panel to the bottom and find the “Triggers” section. There hit “Add trigger”, select “On Submit” to trigger the action when the form is submitted, and click “Create action” to add a new action assigned to the “On Submit” trigger.

At the “Actions” panel a new empty action appears. In the opened popup select your supabase database we connected before → “update Row” → supabase table to update.

After that, we should configure an update behavior. In “Configure filter to update record(s)” type {{ui.clientForm.value.id}} - reference an ID of the record in the form.

Then, to the right of the “Configure record fields to update” field, click on the “JS” button:

This will turn the form into a code field, so we can just reference the whole form value using variable syntax {{ui.clientForm.value}}.

So this action does the following - it will find all the records with IDs equal to the entity ID and update all the fields changed in the form.

The last step we have to perform here is to reload data in the table.

Create a new action step below the “update” step, choose “Execute action” and in the “Action to execute” field choose the “loadClients” action. This configuration will trigger the “loadClients” action right after the database record is updated. So we’ll always have fresh data in the table.

Publish an app to make it available for your users

Finally, to make an application available for your users you have to publish it. Click the “Release” button at the top right corner and hit “Publish release”.

Now your supabase application is up and running! The only thing left to do is invite your users.
In the workspace, click on your email → “Users & Permissions”. There you’ll be able to invite your teammates to collaborate in your app.

Now you have a neat-looking supabase admin panel where you can view and edit your data.

Using UI Bakery builder you can add other features to your app, protect them using roles and permissions, adapt an app for mobile devices, customize the look and feel of your application using a theme editor, and many many more.

All of that in a fraction of a minute.

Join UI Bakery community and build applications in minutes - not months!

Open-Source Headless CMS in 2024

Nik Poltoratsky — Tue, 30 Jan 2024 13:08:38 +0000

In the roaring digital arena of 2024, the open-source headless CMS scene isn't just evolving; it's detonating with revolutionary fervor. These platforms aren't merely tools; they're the maverick spirits driving a relentless push against the digital status quo. Let’s dive headfirst into the anarchic world of the top 8 headless CMS platforms that are rewriting the code of digital rebellion.

You know what would be awesome?

If you check before we begin - low code builder with superpowers for dashboards and internal apps

https://uibakery.io
I am a software developer in a bootstrapped company UI BAKERY, which is an alternative to Retool.
Check UI BAKERY

Strapi: The Code Anarchist

⭐️ 58,615
https://github.com/strapi

Strapi isn't just coding outside the lines – it's tearing them up. This Node.js rebel yells defiance with its RESTful and GraphQL APIs, empowering developers to not just build but to conquer. It's a declaration of independence in the CMS world, a flag planted firmly in the territory of innovation and unrestricted creativity.

Keystone 6: The GraphQL Behemoth

⭐️ 8,700
https://github.com/keystonejs

Keystone 6 isn’t just stepping up the game; it’s smashing it with a sledgehammer. This GraphQL behemoth, with its Node.js roots, is tearing down walls and building empires of content that defy convention and embrace the extraordinary.

Ghost: The Underground Storyteller

⭐️ 45,000
https://github.com/tryghost/ghost/stargazers

Ghost is more than a CMS; it's a whisper in the digital night, a storyteller weaving narratives in the underground. For the bloggers and content punks, Ghost brings Markdown, mobile optimization, and a slick, streamlined approach to shaking up the content cosmos.

Directus: The Shape-Shifting Maverick

⭐️ 24,540
https://github.com/directus

Directus doesn't just adapt; it transforms. This platform is a shape-shifting maverick, constantly evolving and redefining what it means to manage content. Armed with GraphQL and REST APIs, it’s a chameleon in a world of monochrome CMSs.

Decap CMS: The Static Site Outlaw

⭐️ 17,300
https://github.com/decaporg

Decap CMS rides in like an outlaw in the static website world. It’s not just a tool; it's a revolution, bringing a Git-based system and intuitive editor to the static site landscape, leaving a trail of transformed, high-octane websites in its wake.

Payload CMS: The Customization Insurgent

⭐️ 17,084
https://github.com/payloadcms/payload

Payload CMS is where rebellion meets customization. This Node.js, Express, and MongoDB titan is smashing through the barriers of conventional CMSs, offering a realm where customization isn’t just a feature; it's a battle cry for unshackled creative freedom.

Tina CMS: The Editing Renegade of React

⭐️ 10,704

https://github.com/tinacms/tinacms

Tina CMS isn’t just playing with React; it’s setting it on fire. It's an editing renegade, transforming the React scene with inline editing capabilities that turn every keystroke into a radical act of digital defiance.

In 2024, these open-source headless CMS platforms aren't just part of the digital revolution; they're leading it. With each line of code, they challenge the norms, push the boundaries, and empower the rebels and dreamers. They aren't just building websites; they're crafting digital revolutions. Dive into these platforms, and join the headless CMS rebellion, where every click is a call to digital arms!

10 Web Dev Tips to Stay on the Wave in 2024

Nik Poltoratsky — Tue, 23 Jan 2024 09:34:28 +0000

Welcome to 2024's dynamic web development scene, where innovation is essential. This landscape is defined by rapidly evolving technologies and user needs, posing exciting challenges for developers.
In this exploration of the top 10 web development trends, I will uncover how each trend, from Progressive Web Apps to AI integration, is transforming digital creation and interaction. These trends aren't just about technology; they're shaping our digital future.
Before we begin:

Check UI BAKERY

https://uibakery.io
I am a software developer in a bootstrapped company UI BAKERY, which is an alternative to Retool.

1. Progressive Web Apps (PWAs)

PWAs are not just a trend; they're a paradigm shift. Imagine applications that load like regular web pages but offer functionalities like working offline, receiving push notifications, and having a presence on the home screen. The trick is in mastering service workers for offline capabilities and utilizing caches for speed. The challenge lies in designing for various form factors while keeping the app-like feel. PWAs are especially crucial for reaching users in regions with limited internet connectivity or on lower-end devices.

2. API-First Design

Gone are the days when APIs were an afterthought. In 2024, the API-first design is central to web development. This approach starts with a clear contract for the API, focusing on the endpoints, resources, and data formats before writing any code. The goal is to create APIs that are robust enough to serve as the backbone of both the front-end and back-end systems. This trend is driven by the rise of microservices and the need for better integration capabilities in an increasingly interconnected digital ecosystem.

3. Blockchain-Based Applications

Blockchain in web development extends beyond cryptocurrencies. It’s about creating a layer of trust and security in web interactions. Blockchain can be used for secure transactions, verifying identities, and ensuring data integrity. The decentralized nature of blockchain opens up possibilities for developing applications where data security and integrity are paramount. As a developer, understanding blockchain's implications on web architecture, data storage, and user authentication will be crucial.

4. Machine Learning in the Browser

Bringing machine learning to the client side with libraries like TensorFlow.js isn't just about personalization; it's about unlocking a new level of user interaction. This involves training models in the browser, which requires understanding both the technical aspects of machine learning and the ethical considerations of user data. The challenge here is to use these capabilities responsibly and create experiences that are both intelligent and respectful of privacy.

5. Motion UI

In an era where user attention is at a premium, Motion UI can be the difference between a good and great user experience. It's more than just aesthetics; it's about using animation strategically to guide user actions, provide feedback, and make web applications feel more intuitive. The challenge is to integrate Motion UI in a way that enhances usability without compromising performance. This requires a deep understanding of CSS, JavaScript, and the principles of animation.

6. Low-Code and No-Code Development

The rise of low-code and no-code platforms is democratizing web development, but it also raises the bar for professional developers. These platforms can accelerate development, enable rapid prototyping, and free up developers to focus on more complex aspects of web applications. Understanding how to leverage these platforms, integrate them into your workflows, and customize their offerings can give you a significant edge in the market.
UI Bakery is an example of low-code

7. Cybersecurity by Design

With the increasing frequency and sophistication of cyber attacks, a proactive approach to security is a must. This involves incorporating security practices throughout the development process - from initial design through development, testing, and deployment. It's about understanding the latest security threats, staying updated with security best practices, and developing a security-centric mindset.

8. Artificial Intelligence Integration

AI's role in web development is expanding rapidly. From enhancing user experience through chatbots and personalized content to automating backend processes, AI is becoming a staple in the web developer's toolkit. The challenge lies in understanding AI algorithms, managing data ethically, and integrating AI smoothly into web applications.

9. Extended Reality (XR) Experiences

XR is pushing the boundaries of web experiences. This involves integrating AR and VR elements into web applications, creating immersive and interactive experiences that go beyond the screen. This trend is not just about the wow factor; it's about exploring new ways to engage users, provide valuable experiences, and leverage the capabilities of modern browsers and hardware.

10. Voice Search Optimization

With voice assistants becoming increasingly common, optimizing for voice search is more important than ever. This is not just about keywords; it's about understanding natural language processing, structuring content for conversational queries, and ensuring that your web applications are accessible via voice commands. The challenge is to create content that is easily discoverable and navigable through voice, while also providing a rich user experience.

Conclusion

I hope you enjoyed the trends. Which trends did I miss?

Thanks from me and UI Bakery team ✨
These trends represent a mix of new technologies, evolving best practices, and shifts in user expectations. As developers, staying informed and adaptable is key to not just riding the wave, but shaping it.
Embracing these trends will not only keep your skills relevant but also enable you to innovate and lead in creating more effective, engaging, and secure web solutions. In the rapidly evolving world of web development, your ability to integrate these cutting-edge trends can set you apart and position you at the forefront of the digital future.
Remember, each trend offers a unique opportunity to expand your toolkit and perspective. So, keep learning, experimenting, and pushing the boundaries to create web experiences that aren't just functional, but truly remarkable. 🚀🌐

7 Programming Riddles That Even Elite Coders Can't Solve

Nik Poltoratsky — Mon, 20 Nov 2023 15:06:38 +0000

In 1996 Phil Karlton said:

There are only two hard things in Computer Science: cache invalidation and naming things.

This quote evolved in different ways and my favorite one is:

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

I’m not as experienced as the guys above however I have my personal list of annoying programming issues I’m facing frequently. This is this list - a collection of the complex topics in programming that have no solution yet backed by my stories (sure, original problems are included, looks like they’re eternal):

Cache invalidation
Scrolling
When to upgrade?
Naming things
N+1
Dates

Cache invalidation

In a nutshell, cache invalidation is a tough challenge. It’s been one of the most stubborn problems in programming for decades, and we're still hunting for the one solution to rule them all. Whenever this problem shows up, it eats away at our valuable time.

From my own programming journey, I've found that the major headache of cache invalidation isn't about deciding when it's time to invalidate the cache, balancing performance, and data accuracy. No, the real problem is Understanding that the problem comes from the cache.

The sequence usually unfolds like this:

The support team flags a concern - the customer changes things, and the system says it's okay, but the old information stays there.
You try to replicate it on your local machine or the dev or staging server – everything's flawless there.
Sure, you're diving in to understand more about the situation, asking questions such as:
- Did the update really go through?
- Is there a bug causing the system to claim success prematurely?
- If the update was implemented, was the data refreshed properly?
After a long and thorough check, you find that everything seems fine, but frustratingly, the problem doesn't happen very often.
Later, after spending many hours trying to fix the issue, you discover a hidden if/else statement that was added by someone who left the company two years ago.
Stop. Pause. Think. F*ck it. Suddenly, you realize it’s a unique caching setup for a specific situation that you wouldn't expect unless you knew about it beforehand. But really, how could you have guessed?

That's just one-half of the problem. What if the caching system lurks outside your code? My favorite troublemaker here is Hibernate. For those familiar with Hibernate, you know exactly what I'm talking about. For those who aren't, let's just say you're in for a big surprise.

Even after looking through lots of articles and videos, every few months, I encounter errors because of Hibernate. When it comes to caching, Hibernate can be a ruthless monster, ready to consume your peace of mind unless you handle it with extreme caution.

Scrolling

I have experience in both frontend and backend development, but with my roots in frontend, I've developed a firsthand understanding of the fascinating world of scrolls. Trust me, it's more twisted than one might expect.

Primarily, customization! These subtle elements in your browser are unique across different platforms - be it Mac, Linux, or Windows, and not to mention browsers such as Chrome, Safari, or Firefox. Even though their look differs everywhere, they resist you when you try to customize their look uniformly across platforms, which frustrates our design team.

The story takes another twist when we bring in our love for MacBooks and our preference for hiding scrolls in our browsers. Unintentionally, we blind ourselves to blatant scrolling issues that go off to see the world in production. Surprise, surprise, scrolls pop up in the most unexpected places!

To tackle this, we created a dedicated channel to post about any scrolling anomalies we come across:

Meanwhile, our design ideal remains the humble "Small Neat Scroll”

As a countermeasure against unleashing erratic scrolls onto the production stage, we developed a simple yet effective technique: Set scroll visibility to 'always' in Mac settings. Voila! This proved to be an efficient stopgap solution to trim down such issues in production. Who said all solutions must be complex?

Also, credit to my teammate Alex for using Firefox when the rest of us were sailing on the Chrome ship. Thanks to this, many pesky CSS bugs met their end.

So, here's a pro tip: use different browsers. Sure, you can opt for a complex solution like setting up a browser stack for your CSS issues, but it's not the feasible choice for every team. However, testing your project in two or three major browsers that your client uses can drastically help you nip issues in the bud.

But hey, it's not just my team battling these scroll-based outlaws. As we discovered, the world of coding is a lot more scroll-stricken than we had thought.

When to upgrade?

To upgrade, or not to upgrade – that is indeed one of our biggest questions in programming. The question of 'When to upgrade' has been a long-standing challenge. Essentially, it comes down to two main factors:

Developers are always keen on keeping step with the newest versions of libs and frameworks.
Managers are motivated to roll out the latest product versions to clients.

Now, let's delve right in and weigh the pros and cons in this see-saw of upgrading:

Pros:

Performance Boost: Upgrades can enhance your software's performance.
New Features: Upgrades often come with exciting new features, upping your tech game.
Bug Fixes: If you've been struggling with certain bugs, upgrades might be your savior.

Cons:

Potential Bugs: Every new addition comes with the risk of bugs. Bug fixes can be time-consuming and lower your confidence in the new code.
Breaking Changes: Upgrades are often tagged along with breaking changes. For instance, with Node 16 support being dropped by Angular 17, the adaptation time considerably increases.

Applying upgrades can undoubtedly bring many benefits, but they can also be a Pandora's box of unforeseen problems. You might wonder – How much work would it take to transition from Node 16 to Node 18 in a project? A simple version change, or a time-consuming search for the correct versions of all packages?

Personally, I'm on the cautious side when it comes to upgrades. However, some teammates are keen on them, and together, we've found a balance to keep our software updated, or at least close to the latest versions with minimal disruptions.

This is the case now, but before…

Backtracking a few years, we had an intriguing encounter with a new client, keen on deploying our software (https://uibakery.io/) on-premise. We provided them with a deployment guide, and surprisingly, they came back with a security report pointing out hundreds of issues, with tens of them as critical vulnerabilities!

Interestingly, all the major problems in our images could have been fixed easily with a regular update – potentially saving us from losing the client! This incident made us realize the power of staying updated. Since then, we've made it a point to perform security scans before any rollout.

In conclusion, finding the right time to upgrade is all about striking a balance and understanding your project's specific needs.

Naming things

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
—- Martin Fowler

One of the simplest, yet crucial undertakings in any coding project, is to appropriately name things. Seeing is believing, so let's look at two bites of code:

The first one, as you'll agree is a riddle, demanding a thorough read to decrypt its purpose.

public class LN {
    public static void main(String[] args) {
        B b = new B();
        b.s(1, "Harry Potter");
        b.s(2, "Lord of the Rings");
        b.l();
    }
}

class B {
    HashMap<Integer, String> m;

    B() {
        m = new java.util.HashMap<>();
    }

    void s(int i, String t) {
        m.put(i, t);
        System.out.println("Book added: " + t);
    }

    void l() {
        System.out.println("Book List:");
        for (java.util.Map.Entry<Integer, String> e : m.entrySet()) {
            System.out.println("ID: " + e.getKey() + ", Title: " + e.getValue());
        }
    }
}

The second one, in contrast, is reasonably transparent - a mere skim leads to an understanding of its functioning.

public class LibraryManager {
    public static void main(String[] args) {
        Library library = new Library();
        library.addBook(1, "Harry Potter");
        library.addBook(2, "Lord of the Rings");
        library.displayBookList();
    }
}

class Library {
    private Map<Integer, String> bookMap;

    Library() {
        bookMap = new HashMap<>();
    }

    void addBook(int id, String title) {
        bookMap.put(id, title);
        System.out.println("Book added: " + title);
    }

    void displayBookList() {
        System.out.println("Book List:");
        for (Map.Entry<Integer, String> entry : bookMap.entrySet()) {
            System.out.println("ID: " + entry.getKey() + ", Title: " + entry.getValue());
        }
    }
}

Appropriate naming is not just important in code. In fact, it’s often even more vital during team discussions. In my team, during discussions, we from time to time find ourselves deeply involved in intense arguing. Eventually, we come to understand that we all agree, but we have been using different terms to express our ideas.

In my view, assigning clear, descriptive names, and spreading these terms consistently across the team is one of the most crucial tasks in any project.

Why is this still a thorn in the side for many? The answer's simple: there isn't an automated linter/test/validator that can certify your naming conventions. Each member of your team comes with a diverse background, varied experiences, and unique views regarding variable names. To create harmony among these different factors takes a lot of time. If anyone knows an easy solution for this, I'd really like to hear it!

N+1

A few months ago, my colleague Vlad, also the CEO, summoned me to review a newly raised pull request (yes, our CEO is coding and it's another pain in the ass 🙃). The said PR is meant to augment how our clients manage their users on our platform. We work with Spring Boot in the backend, and this project update included a large SQL query that was about 150 lines long. Here's how our discussion went:

Nik: Vlad, great work on your PR. However, using 150 lines of SQL might be too complex, especially for those who see it for the first time. If you're busy with CEO work and we need to handle it, it could be tough. How about we try doing it in Java instead?

Vlad: Sure, Nik. I foresaw some performance optimization, but I'll go with your judgment.

Nik: Do we have clients to whom this change could impact significantly?

Vlad: Not yet, but the scope could unfold.

Nik: Exactly. Let's rewrite it in Java to make it easier to read. If we face problems that need SQL, we can change our approach later.

Vlad: Sounds good.

Henceforth, the PR was rolled out to production without a hitch, until, of course, we began expanding it to our on-premises clients.

One of the on-premises clients had already invited a significant user base. However, the new user-management page, introduced by Vlad, took 3+ minutes to load 🥳. Of course, we had then run into the N+1 problem. I was like:

The N+1 problem happens when you first make one query to get a group of main items (+1), and then you make additional queries to get related details for each of these main items (N). For N objects, you end up unleashing N+1 queries, akin to ordering several pizzas and then asking separately for each topping's ingredients!

Though the N+1 issue is relatively general, it became all too familiar to me with ORMs (Object-relational mappings), and REST-like APIs.

ORM

Imagine you have a fancy ORM (Object-Relational Mapping) tool. It fetches data from your database and simplifies your life until the N+1 problem steals the show. Ironically, ORMs mostly default to lazy loading – they grab only the primary object first, picking the associated objects only when required. It sounds apt until you're in an N+1 scenario. Suddenly, your database is overworking, and you're left pondering: "Did I just order a pizza, or did I start baking the dough myself?"

Let's take a look at Hibernate, an ORM tool I often use for examples. Imagine we have two things: Author and Book. These represent authors and their books in a library. In our example, each Book is connected to an Author using a special link called @OneToMany(mappedBy = "author"). This shows the relationship between the authors and their books.

@Entity
public class Author {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "author")
    private List<Book> books = new ArrayList<>();
}

@Entity
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    @ManyToOne
    @JoinColumn(name = "author_id")
    private Author author;
}

Suppose we aim at fetching a list of authors and their books through Hibernate. We might take this route:

List<Author> authors = entityManager.createQuery("SELECT a FROM Author a", Author.class).getResultList();

for (Author author : authors) {
    // This triggers the N+1 problem!
    List<Book> books = author.getBooks();

    // Do something with the books
}

In this example, Hibernate starts loading authors eagerly. However, it doesn't immediately fetch their corresponding books. As we pivot through the getBooks() method for each author, Hibernate charges forth with separate SQL queries for each author to load their books. This encapsulates the quintessence of the N+1 problem.

But don't worry, fetch joins can adjust our query to quickly get both the related books and their authors together:

List<Author> authors = entityManager.createQuery("SELECT DISTINCT a FROM Author a LEFT JOIN FETCH a.books", Author.class).getResultList();

With this, Hibernate collates both authors and their books in a single query, exiling the N+1 problem.

However, dealing with large datasets may not be easy, and debugging can be elusive if you don't know your way around. When facing performance issues around the database, my go-to step is to fully enable SQL logging. There, I spotted numerous queries, unraveling the N+1 problem at hand.

REST-like APIs

Now, onto the REST-like API territory. Visualize an API that returns a list of entities (like superheroes), each retaining a list of superpowers. Making an API request to get a list of heroes could trigger the N+1 problem. You obtain the list but would have to make an additional request for each hero's superpowers. It's like attending a superhero meet-and-greet, but each hero narrates their origin plot individually, and efficiency takes a hit.

Here's where GraphQL shines, enabling you to specify what data you require and its structure, avoiding excessive requests. Like ordering a combo meal instead of separate dishes, GraphQL encapsulates your request as a single comprehensive entity.

There are different ways to solve the problem, not just with GraphQL. Options like JSON:API work too. But mostly, GraphQL has become the most popular choice for this.

In summary, N+1 could potentially be the villain in the realm of programming, but gallant tools like GraphQL could come to the rescue and restore order to this digital pandemonium. Be wise, choose your heroes wisely.

Dates

Yes, once in a while, we all get slapped by the confounding inconsistencies of 'Dates.'

Regrettably, I don't have an engaging story to share, but I do have this list of date-related puzzles that left me scratching my head last year:

Varying Formats: No, 'Dates' are not a fan of uniformity. They stroll into your system bearing different getups, sometimes even within the same database or API.
Time Zone Tango: The dance between different time zones for client and server can get quite confusing.
The World Clock: Imagine dealing with clients operating in various time zones!
The Hour Offset Conundrum: Not all time zones proudly wear the one-hour badge.
Server-Time Zone Mismatch: The servers wandering in various time zones while the database sticks to its own is chaotic.
Leap Year and Leap Second: Because 'Dates' like to jump around a bit.
The Calendar Conversion: Converting 'Dates' between different calendars (like Gregorian, Julian, Lunar) is a formidable task.
Time Zone Twisters: Handling time zones with irregular offsets or historical changes is nothing short of a rollercoaster ride.
Distributed Systems or Microservices: Managing time zones in these scenarios typically calls for some hair-pulling.
On-Premises Deployments: Valid time becomes a puzzle when dealing with clients' on-premises deployments.

Dealing with dates in programming is much more complicated than it seems. It's just one part of the bigger challenge. Working with dates can be very confusing. In my experience, problems with dates are more difficult than issues with caching or naming. Or at least more irritating.

Finally

Finally, I want to say that all those problems are generally solvable - you can solve them in each individual case - you can name one variable properly, you can deal with scrolls on individual pages, you can design how you work with dates in your system and you can make sure that this exact controller method doesn’t have N+1 problem.

However, solving them in general is too hard and I don't think is possible - you can’t somehow force your team to name all the variables, functions, and classes properly. You can’t make one simple setup and make sure that all the scrolls in the system are always identical. You can’t add a few tests and make sure that dates in your system work correctly, necessarily there will be someone who will skip your rules and accidentally break the system.

What can we do here? We’re trying to use the Pareto rule and get 80% of results using 20% of the time - doing small simple steps to prevent most of the issues. Doing code reviews, doing hacks as explained in the scrolls section (enabling scrolls everywhere), doing testing for crucial flows, etc. We know we can't catch everything, so there might still be problems when it's actually deployed to production.

PS

This is a list of programming issues that I find particularly irritating. What are the coding challenges that annoy you the most? Please share your thoughts with me!

PPS

Hit a comment if you like the off-by-1 problem explanation.

Agile Angular modules configuration

Nik Poltoratsky — Tue, 10 Nov 2020 13:50:54 +0000

Follow me on Twitter at @NikPoltoratsky | Subscribe to the Newsletter | Originally published on howtomake.software.

If you already built a few Angular applications it might be you already spotted how it may be tricky to build easily configurable modules.

I mean, if you're building a reusable module it might be you need to configure it somehow. And if this module contains different entities (multiple components, services, directives, and pipes) it will be hard to configure them separately. It would be better to configure the whole module in one place.

For example, let's take a look at the Angular material dialog.

The angular material dialog contains multiple entities - components and services. And it provides us with the single point of configuration - MAT_DIALOG_DEFAULT_OPTIONS is the Dependency Injection (DI) token that allows us to configure all the material dialogs at the application at one place.

In this article, I'll be talking about how to configure Angular components and services using the Dependency Injection concept.

How we use DI most of all

The main idea of DI is to provide dependencies for different entities - components, services, modules, and so on.
The most frequent usage of DI in Angular is to inject services into components.

In that case, you're creating a service:

@Injectable()
export class MyService {}

And then, you're using it in component, easy as that:

@Component()
export class MyComponent {
  constructor(private service: MyService) {}
}

Even though this is the most popular way to use DI we have other ways to use it. Let's explore how to use DI for system configuration.
We're going to learn about system configuration but first things first, so, let's start with Injection Tokens 🥳.

Putting data in the DI

Injection Tokens is the Angular concept that allows you to put something in the DI system. For instance, you want to provide a configuration object for your app.
First of all, we need to create it:

const CONFIG = new InjectionToken("This is a configuration object");

And then, we need to provide it:

@NgModule({
  providers: [{ provide: CONFIG, useValue: { foo: "bar" } }],
})
export class AppModule {}

Finally, you can use it:

@Component()
export class MyComponent {
  constructor(@Inject(CONFIG) private config) {
    console.log(config.foo); // will be 'bar'
  }
}

Injection tokens allow us to put some data inside the DI container and then consume it everywhere. Using injection tokens we can build agile configuration systems for our applications. Let's do that! 🌈

Building configurable modules

Let's assume we have to build a component, for instance - dialog component. It will have tons of configuration options:

export interface MatDialogConfig<D> {
  viewContainerRef?: ViewContainerRef;
  id?: string;
  role?: DialogRole = "dialog";
  panelClass?: string | string[] = "";
  hasBackdrop?: boolean = true;
  backdropClass?: string | string[] = "";
  disableClose?: boolean = false;
  width?: string = "";
  height?: string = "";
  minWidth?: number | string;
  minHeight?: number | string;
  maxWidth?: number | string = "80vw";
  maxHeight?: number | string;
  position?: DialogPosition;
  data?: D | null = null;
  direction?: Direction;
  ariaDescribedBy?: string | null = null;
  ariaLabelledBy?: string | null = null;
  ariaLabel?: string | null = null;
  autoFocus?: boolean = true;
  restoreFocus?: boolean = true;
  scrollStrategy?: ScrollStrategy;
  closeOnNavigation?: boolean = true;
  componentFactoryResolver?: ComponentFactoryResolver;
}

Lot's of configurations here 🙃. And it's impossible to copy/paste it each time when you're using the dialog in your application.
Looks like it would be awesome to install global configuration first of all and then just overwrite at the place when we're using the dialog.
How to do that? Frankly speaking, quite easy:

First of all, we're creating an injection token that'll allow us to provide configuration for our dialog component:

const DIALOG_CONFIG = new InjectionToken(
  "This is a configuration object for our dialog component"
);

Then, in any place where we need it, we're just using it:

@Component()
export class DialogComponent {
  constructor(@Inject(DIALOG_CONFIG) private config) {}
}

@Injectable()
export class DialogService {
  constructor(@Inject(DIALOG_CONFIG) private config) {}
}

You can use it anywhere you need it. When we're using dialog we're providing configuration at the root level:

@NgModule({
  providers: [
    { provide: DIALOG_CONFIG, useValue: {...} },
  ]
})
export class AppModule {}

And then, all the instances of the dialog will share the same configuration out of the box.

However, this approach requires the user of the library to know about too many concepts. Generally, the user ought to:

import the module
provide configuration through the DIALOG_CONFIG
import and use the required services and components

But we have a solution that helps to reduce the number of concepts the user ought to know. Let's hide DIALOG_CONFIG from the user but still keep the ability to provide it outside.

Using forRoot/forFeature for module configuration

I bet you already saw and used the forRoot modules configuration with the RouterModule.

forRoot - is a convention that allows the authors of modules to provide a simple interface for module configuration. Let's see how to make it.

@NgModule({
  declarations: [
    // all the components and directive are declared here
  ],
})
export class DialogModule {
  static forRoot(config): ModuleWithProviders<DialogModule> {
    return {
      ngModule: DialogModule,
      providers: [{ provide: DIALOG_CONFIG, useValue: config }],
    };
  }
}

Above we have a DialogModule that declares all the components, directives, services, and other entities.

Also, it has a static forRoot method that returns ModuleWithProviders - an object with declared ngModule and all the providers that ought to be declared at the root level.

This is the reason why it's called forRoot. It's supposed to be called at the root level only. Otherwise, you might spot problems because of multiple forRoot calls.

Instead, modules authors provide us with forFeature level if their modules can be reconfigured at the feature level.

forRoot method receives config - the configuration object that will be provided at the root level and will be available for all the entities.

Then, we're using it:

@NgModule({
  imports: [
    // now we can do this:
    DialogModule.forRoot({}),
  ],
  providers: [
    // instead of this:
    { provide: DIALOG_CONFIG, useValue: config },
  ],
})
export class AppModule {}

As you can see above, this approach makes modules configuration seamless! And the user doesn't need to think about providing something, just calling the function! 😱

Looks cool, right? 🥳 Until it's not.

Why it's not a good idea?

It's an implicit approach. The problem is that if you're providing configuration somewhere in another place rather than in place when you're using it'll be hard to understand by the reader of the code.

Let's return to the example with the dialog. So, here I have a root configuration that defines some application wide dialog configurations:

@NgModule({
  imports: [DialogModule.forRoot({})],
})
export class AppModule {}

Then, in different feature modules I do the following:

@NgModule({
  imports: [
    // Providing another `closeIcon`
    DialogModule.forFeature({ closeIcon: "flower" }),
  ],
})
export class FooFeatureModule {}

@NgModule({
  imports: [
    // Providing another `closeIcon`
    DialogModule.forFeature({ closeIcon: "bar" }),
  ],
})
export class BarFeatureModule {}

After that, I'm just using the dialog:

@Component({})
export class MyComponent {
  showDialog() {
    this.dialog.show();
  }
}

Cool! Then, I'm returning to this code in a year and I need to check why do I have some configurations at the dialog? I'm checking the place where I'm calling and what do I see? You're right! Nothing! No configuration here. Hmm, then I have to go to my feature module and then to the root module. So, I need to check three places instead of one.

Moreover here, what if I didn't see this module before? What if I have no idea how this configuration works? In that case, it'll be pretty hard to figure out what's going on in the app and which configuration was taken into the account.

Don't overuse that approach. It'll help you configuring applications but overusing that idea will lead to hell. 😭

Recap

So, as you can see here, Dependency Injection is a powerful concept that can be used not only for services injection but also for configurations injection. It has many many more usages but we'll take a look at them in other articles.

Follow me on twitter to be notified about more cool content http://twitter.com/nikpoltoratsky.

Draggable Table with Angular CDK

Nik Poltoratsky — Tue, 25 Aug 2020 13:26:27 +0000

This article is originally published on howtomake.software.

What are we going to build?

In this article, I'm going to show you how to build a table with an ability to rearrange rows in it. 👇

What do we need for that?

Angular CDK

All the functionalities we need for the draggable table are bundled inside the Angular CDK package. Let's install it first of all:

npm install @angular/cdk

When the Angular CDK package is installed in your project it's a time to understand what exactly we're going to use from the package.

Angular CDK Table Module

Since we're building a draggable table, the first thing we need is table 🙄. Angular CDK Table Module allows us to build powerful tables easily. Let's take a look at how to do that.

First of all, we ought to import the Angular CDK Table into the AppModule:

import { NgModule } from "@angular/core";
import { CdkTableModule } from "@angular/cdk/table";

@NgModule({
  imports: [CdkTableModule],
})
export class AppModule {}

CdkTableModule allows us to use basic tables primitive directives: cdk-table, cdkColumnDef, cdk-header-cell, cdk-cell, etc. Let's discuss, how to use them.

Create Table

We need to create a table itself. Let's add a plain HTML table and mark it as the Angular CDK Table using cdk-table directive:

<table cdk-table></table>

Next, we need to configure the table structure. We can do so using directives provided by the CdkTableModule. Let's configure each piece one by one:

Header row configuration

Header row can be configured using cdk-header-row. This directive will let cdk-table understand that it's a template for the header row. Then, we're adding a cdkHeaderRowDef directive. It receives a list of columns to be shown.

<tr
  cdk-header-row
  *cdkHeaderRowDef="['position', 'name', 'weight', 'symbol']"
></tr>

Table row configuration

A table row can be configured using cdk-row. This directive will let cdk-table understand that it's a template for the table row. Then, we're adding a cdkHeaderRowDef directive. It receives a list of columns to be shown.

<tr
  cdk-row
  *cdkRowDef="let row; columns: ['position', 'name', 'weight', 'symbol'];"
></tr>

Table cells configuration

Now, it's a time to configure table cells:

  <ng-container cdkColumnDef="position">
    <th cdk-header-cell *cdkHeaderCellDef> No. </th>
    <td cdk-cell *cdkCellDef="let element"> {{element.position}} </td>
  </ng-container>

  <ng-container cdkColumnDef="name">
    <th cdk-header-cell *cdkHeaderCellDef> Name </th>
    <td cdk-cell *cdkCellDef="let element"> {{element.name}} </td>
  </ng-container>

  <ng-container cdkColumnDef="weight">
    <th cdk-header-cell *cdkHeaderCellDef> Weight </th>
    <td cdk-cell *cdkCellDef="let element"> {{element.weight}} </td>
  </ng-container>

  <ng-container cdkColumnDef="symbol">
    <th cdk-header-cell *cdkHeaderCellDef> Symbol </th>
    <td cdk-cell *cdkCellDef="let element"> {{element.symbol}} </td>
  </ng-container>

The most important part here is cdkColumnDef. It says which column we're configuring. As you remember, we just told the Angular CDK Table that we'll have the following columns in the table: ['position', 'name', 'weight', 'symbol']. Now we're using cdkColumnDef="name" to tell the table which column we're configuring here. We have pretty similar configurations for all columns. Let's dive inside columns templates.

Inside each column definition, we have two lines: one for the header cell or th and one for the row cell or td.

<th cdk-header-cell *cdkHeaderCellDef>Name</th>

This line configures a header cell for the name column. It tells the table that it's a header cell via cdk-header-cell directive. And marks it as a cell template with *cdkHeaderCellDef.

<td cdk-cell *cdkCellDef="let element">{{element.name}}</td>

While this line configures how the table row cell will look like. cdk-cell marks this element as a table cell. And *cdkCellDef="let element" directive marks it as a template and provides the link to the active row element.

But where we'll get those elements? Right now we have only the template and nothing similar to data! Hmm. The Angular CDK Table operates with the concept of datasource.

Datasource

What is Angular CDK Table data source

The data source concept describes how you can provide data to the Angular CDK Table. It can be done in three ways:

The simplest way is to use a plain javascript array. It ought to contain objects. And in that case, each object represents one table row.
Using Observable. In that case, you ought to provide a stream of arrays. The table will rerender each time that Observable emits a new array. (We'll use that approach for the data source in this tutorial).
Using DataSource object that implements DataSource interface that contains connect/disconnect functions. This approach is useful for more complex scenarios. Especially in cases when you need to clean up our data stream. This can be done using disconnect functionality.

How to attach data to the table?

First of all let's create an array with data:

export class AppComponent {
  private items: PeriodicElement[] = [
    {position: 1, name: 'Hydrogen', weight: 1.0079, symbol: 'H'},
    {position: 2, name: 'Helium', weight: 4.0026, symbol: 'He'},
    {position: 3, name: 'Lithium', weight: 6.941, symbol: 'Li'},
    {position: 4, name: 'Beryllium', weight: 9.0122, symbol: 'Be'},
    {position: 5, name: 'Boron', weight: 10.811, symbol: 'B'},
  ];
}

Then, we ought to push that data into the subject. That's required since we're going to change the order of rows during the drag and drop.

export class AppComponent {
  datasource = new BehaviorSubject(this.items);
}

After that, when we have a stream of data we ought to connect it to the table:

<table [dataSource]="dataSource"></table>

And that's it. Now we have a table and a data source connected to it. Now it's a time to make it draggable!

Adding Drag & Drop

All the functionalities we need for the drag and drop are bundled inside the Angular CDK DragDrop module. So, let's import it first of all:

import { NgModule } from "@angular/core";
import { DragDropModule } from '@angular/cdk/drag-drop';

@NgModule({
  imports: [DragDropModule],
})
export class AppModule {}

When DragDropModule is installed it allows us to use cdkDrag and cdkDropList directives inside our templates to make elements draggable. Let's see how it works.

cdkDrag

<tr cdk-row *cdkRowDef="let row;" cdkDrag></tr>

This is a table row we defined a few minutes ago. But now I added a cdkDrag directive here. This directive makes an element draggable.

cdkDropList

The next step is to define the container for draggable elements. Since in our case we're going to rearrange table rows, that means our draggable elements container is our table:

<table cdk-table cdkDropList (cdkDropListDropped)="drop($event)"></table>

I've just added cdkDropList directive here. It marks the table as a draggable elements container and allows us to intercept drop events using cdkDropListDropped directive output. So, when the user releases an element somewhere on the table we'll receive that drop event. Then, we'll be able to react on it and rearrange the data in the table's data source.

So, as you can notice above I've added drop callback to the cdkDropListDropped event. Let's implement it to make our table finally rearrangeable!!

import {CdkDragDrop, moveItemInArray} from '@angular/cdk/drag-drop';


export class AppComponent {
  drop(event: CdkDragDrop<string[]>) {

    // Rearrange the data in the array
    moveItemInArray(this.items, event.previousIndex, event.currentIndex)

    // Publish a new version of the data into the datasource
    this.dataSource.next([...this.items]);
  }
}

What's going on here? We're just receiving a CdkDragDrop event. It contains all the required information to move the item. It has a previousIndex and a currentIndex of the item that was moved visually by the user. Then, we can move it from the previous place to the new place using the moveItemInArray function provided by the Angular CDK DragDrop module.

And finally, we're just publishing a new version of data to the table! Easy as that! And here is the result 👇

Recap

At this tutorial, you learned how to make rearrangeable tables in Angular using Angular CDK Tables and DragDrop modules. I hope you get all the details and liked the article. If you have any questions, please, let me know on twitter, I'll try to help you.

If you're interested in more content about Angular CDK, follow me on twitter and subscribe to my newsletter🔥

Why reducer is reducer?

Nik Poltoratsky — Wed, 06 May 2020 10:54:36 +0000

Originally published at https://howtomake.software

In this article, I'm introducing my mental model of modern state management.

More exactly I'm talking on how ngrx works, why reducer is a reducer, and how it
is related to the JavaScript's array reduce method. All the statements here will likely be true
for any state management solution using redux concepts. So, if you're using Redux, you're welcome 🤓.

At this article we'll cover:

What is ngrx?
What is array reduce?
Understanding reduce concept
So, why reducer is reducer?

What is ngrx?

If you have no experience with ngrx or other redux like state management solutions, I would personally recommend you to
learn about them first. I would suggest you start at the ngrx getting started guide.

However, I'll still cover how it works briefly. Here is a diagram from the ngrx website:

ngrx operates with 5 major concepts:

State - represents the application state at the current moment.

For instance, if we're building a todo list application our state will contain the list of tasks:

interface State {
  tasks: Task[];
}

interface Task {
  text: boolean;
  done: boolean;
}

Action - describes unique events that trigger state changes or side effects.

const addTask = createAction('Add Task');
const removeTask = createAction('Remove Task');
const markTaskAsDone = createAction('Mark Task As Done');

Selector - describes how to select slice of the state to be consumed by the component.

const getTasks = createSelector(state => state.tasks);
const getCompletedTasks = createSelector(state => state.tasks.filter(task => task.done));

Reducer - describe how your application's state will change based on actions.

const reducer = createReducer(
  on(addTask, state => {
    // add task 
  }),
)

Effect - performs side effects, like interaction with the backend.

saveTasks$ = createEffect(
  ofType(saveTasks),
  mergeMap(tasks => {
    // save tasks here
  }),
);

So, the main idea of the ngrx is that your application has a single source of truth - your state. It's an immutable object that can be changed only by the reducer. You can use parts of the state in your components selecting them using selectors.

If you need to change the state, you need to fire an action. Then, your reducer ought to intercept that action and publish a new version of the state (the state is immutable and can't be changed, that's
why reducers don't change state, they just publish a new version of it).

If you need to perform some side effect, like persisting data at the backend, you're using effects that intercepts an action, performs side effect and fires new action to change the state.

With names of 4 concepts everything is clear:

State - application state
Action - a command to change the state or perform side effect
Selector - selects part of the state
Effect - performs side effect

But reducer's concept always was a dark horse for me.

Why is it called a reducer?
Does it have any relation to the JavaScript's arrays reduce method?
What was the intention to call it that way?

Now, I'll tell you answers to those questions! But before we dive into those sacred secrets, we ought to learn what is array reduce method 🚀

What is array reduce?

So, what is the array reduce method?

In fact, the reduce method accepts an initial state, then iterates over the array items and applies some transformations
to the accumulator based on each item. It handles items one by one. Each iteration returns a new version of the accumulator
that will be consumed by the next iteration. Here is the gif that explains it step by step.

Well, pretty easy, I'm right? I think it's a time to build a reducer concept
based on the reduce method 🥳

Understanding reduce concept

In this section, I'm going to take an array reduce method and build a reducer concept based on it.
First of all, here we have an array and a reduce call:

const array = [1, 2, 3, 4, 5];

const result = array.reduce((acc, item) => {
  return acc + item;
}, 0);

It consumes an initial value - accumulator, that is 0 and adds item to the accumulator at each iteration.
The next step is to aply an appropriate naming to it:

const actions = [action1, action2, action3, action4, action5];
const initialStoreState = {};

const result = actions.reduce((state, action) => {
  // perform some transformation
}, initialStoreState);

Now it looks like a reducer! Am I right? We're close!
Now, let's remember how we did state transformation at the reducer - using a switch/case statement!

const actions = [action1, action2, action3, action4, action5];
const initialStoreState = {};

const result = actions.reduce((state, action) => {
  switch (action.type) {
    case Action1:
      // apply some transformations
    case Action2:
      // apply some transformations
    case Action3:
      // apply some transformations
    case Action4:
      // apply some transformations
    case Action5:
      // apply some transformations
  }
}, initialStoreState);

Much better now, huh? Now, do you remember that ngrx operates with the immutable state objects? That
mean we can't just apply some transformations to the state, we also need to create a new state object each
time we do something at the reduce method:

const actions = [action1, action2, action3, action4, action5];
const initialStoreState = {};

const result = actions.reduce((state, action) => {
  switch (action.type) {
    case Action1:
      // apply some transformations
      return newVersionOfTheState;
    case Action2:
      // apply some transformations
      return newVersionOfTheState;
    case Action3:
      // apply some transformations
      return newVersionOfTheState;
    case Action4:
      // apply some transformations
      return newVersionOfTheState;
    case Action5:
      // apply some transformations
      return newVersionOfTheState;
  }
}, initialStoreState);

And we're done! Looks like a common reducer function, right? Or not? Something is still missing here...
I mean, at the code above we're iterating over an array of items. While when we're dealing with ngrx actions,
actions are not an array. It's a stream of events distributed over time.

What concept can help us to handle a collection of events distributed over time?

Of course, it's Observable!

Frankly speaking, Observable is intended to be a stream of events. But for simplicity and a better understanding of
my concept let's refer to it as just a collection of items distributed over time. Like an array, but distributed over time 😅.
Hopefully, you already get my point here.

const actions = new Subject();

// I can consume actions via subscribe
actions.subscribe(action => {

  // handle action somehow
})

// And can push new actions into the collection
actions.next(someAction);

Here I have a plain definition of actions collection. I can push something into that collection, also, I can consume items from that collection.

The next step is to create a state and to reduce it somehow.

const state = new BehaviorSubject();

// I can consume state via subscribe
state.subscribe(state => {

  // do something with it
})

// And can push new version of the state
state.next(newState);

I've created a state stream above. I'm using BehaviorSubject here since it holds the last state inside and I can consume it whenever I want,
even if subscribe on it after a new version of the state was pushed into the stream.

const actions = new Subject();
const state = new BehaviorSubject({count: 0});

// Listen for new actions
actions.pipe(

  // Get the latest version of the state
  withLatestFrom(state),

  // Perform actual reduce - create a new state version based on the latest state and an action
  map(([action, state]) => reducer(state, action)),

  // Publish a new version of the state
).subscribe(newState => state.next(newState));

// It's an actual reducer function!
function reducer(state, action) {
  return { count: action.count + state.count };
}

// Fire a new action
function onClick() {
  actions.next({count: Math.random()});
}

Above I have a very basic implementation of the ngrx store. Let's dissect it now!

const actions = new Subject();
const state = new BehaviorSubject({count: 0});

Here I have a stream of actions, and a stream of states.

// Listen for new actions
actions.pipe(

  // Get the latest version of the state
  withLatestFrom(state),

  // Perform actual reduce - create a new state version based on the latest state and an action
  map(([action, state]) => reducer(state, action)),

  // Publish a new version of the state
).subscribe(newState => state.next(newState));

Then, I'm listening for actions, getting the latest version of the state and applying a reducer function to the latest state and a new action.
This reducer function returns a new version of the state (Did you notice that our reducer function has exactly the same signature as it has
in ngrx? I think we're going the right way!)

After that, we're subscribing to the stream and publishing a new version of the state to the consumers.

// It's an actual reducer function!
function reducer(state, action) {
  return { count: action.count + state.count };
}

Here is a reducer function we built. It's a plain reducer function as it exists in the ngrx.

// Fire a new action
function onClick() {
  actions.next({count: Math.random()});
}

And finally, we have a click handler that fires new action.

As you can see now, we went from the array.reduce to the ngrx store step by step. We didn't built a real ngrx store. We built a super simplified version
that is intended to explain my mental model only. Hopefully, you get the idea 😅

Finally, I just want to formulate the idea.

So, why reducer is reducer?

Reducer is called reducer since it reduces a collection of events distributed over time and an application state. It does it the same way as array.reduce function with only one difference -
arrays are static, while collection of events are distributed over time.

Stay tuned and follow me on twitter!
Originally published at https://howtomake.software

Angular a11y: 11 tips on how to make your apps more accessible

Nik Poltoratsky — Thu, 20 Feb 2020 15:05:27 +0000

This article, its updates, and more recent articles are hosted on the new platform inDepth.dev

Nowadays approximately 15% of people have some kind of disability that doesn't allow them to use web applications in a common way - keyboard, mouse, touchscreen. That's where accessibility comes on to the stage.

Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections. You might also think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their ability or circumstances. (source: developer.mozilla.org)

I prefer thinking about accessibility as about help for future me. While developing accessibility features, I'm always asking myself a question: "what may happen to me in the future?". What if I broke my arm or something else happen to me? Will I be able to use an application without a mouse? Without the keyboard? With the screen reader?

Accessibility is not only for people with disabilities it's also about future you, about your old parents, who aren't able to interact with the web in a common way just because they're old.

Also, there're different types of applications that require accessibility. I'm talking about government websites. For instance, the United States government has a resource that describes how to make your application accessible enough: https://accessibility.digital.gov

And my mission for today is to introduce the most basic principles on how to make your application accessible. In this article, you'll find 11 tips that will help you make your Angular application more accessible.

Please note, that to use any of the techniques described below you should carefully go through the documentation. It’s easy to screw up accessibility when doing it without sufficient knowledge.

Use meaningful HTML
Natural content flow
Provide alternative content
Think about contrast
Don’t autofocus
Don’t outline: none
Use ARIA attributes
Use landmarks
Provide a unique title for each page
Use Angular CDK
Test for a11y

Use meaningful HTML

The first and the simplest way to start with the accessibility is to start using plain old HTML for its purpose. I mean creating meaningful or semantic HTML. Since HTML elements are always used by assistive technologies for multiple purposes we ought to make sure that HTML is done right in our Angular applications. Let me explain why it is important:

Built-in keyboard accessibility — native HTML elements always have built-in keyboard accessibility. Buttons are always focusable and clickable via keyboard, select elements are always navigable via keyboard and so on. If you’re building custom controls instead of using native HTML elements you’ll have to make them accessible by yourself.
Good content structure with headings, paragraphs, lists, etc. — What’s the most important here is that content structure is used by the most screenreaders for navigation. For instance, most of the screenreaders build a kind of additional menu from headings on the page and allow their users to navigate to any heading at the page.
No table layouts — Tables were created with the purpose to display structured data. However, tons of pages nowadays are using tables for layouts. This approach may lead to inappropriate behavior and unstructured reads via screenreader. By the way, some of the modern screenreaders know the difference between data tables and layout tables, however, right now we can’t completely rely on them.

I’ve mentioned only a few points above, however, we have more reasons why to use semantic HTML. To find more information, you can start at developer.mozila.org.

Natural content flow

HTML defines how elements are rendered and organized on a web page. It determines which element comes before another one, which one sits on top of another and so on. These rules that control the flow of content is called the HTML content flow.

Looks like the content flow from left to right and from top to bottom is the most popular content flow across the web. However, in different cultures, you can notice different content flow like the right to left. And it’s very important to keep HTML content flow feel natural for the user. Especially important here to keep tab order at the page feels natural. However, user experience and natural tab order can be easily screwed up via improper usage of flex boxes, floats, tabindex and other HTML features.

Reverse flex container — will mess tab order since elements positions will be different compared to the elements in the DOM.
Floats — CSS float introduces almost the same issue as reversed flex containers. It keeps the element at its place at the DOM but moves to another place on the screen.
tabindex — tabindex is created to modify tab order, so it’s quite easy to introduce a mess using this HTML attribute. tabindex attr accepts integer values that define an order of elements in tab order of the page. Negative values remove an element from the tab order, 0 inserts elements in the natural tab order, positive values jump the element to the front of the natural tab order. If there are multiple elements with a tabindex greater than 0, the tab order starts from the lowest value that is greater than zero and works its way up. That’s why positive values for tabindex considered an anti-pattern. You can learn more about tabindex usage here: https://developers.google.com/web/fundamentals/accessibility/focus/using-tabindex

As we learned above, incorrect usage of HTML and CSS can introduce unexpected tab order on the page. Keyboard users will never expect the improper tab order and it’ll be hard for them to get how to navigate through the application.

To learn more on natural tab order, please, check these articles:

Provide alternative content

When you’re creating non text content on the web page, please, make sure you’ve provided a text alternative for your content. Let me elaborate:

If your website contains images, charts, maps you ought to make sure this content has text alternatives for people who use screen readers. Since screen readers can’t read your images, charts, and maps you need to provide a text that contains all information from your infographics. For that purpose typically alt=”Description” attribute is used on images.
Websites with video content ought to have subtitles. Easy as that, people who can’t use speakers ought to have the ability to understand your content. And here, subtitles come on to the stage.
Empty alt for decorative images <img src=”…” alt=””>. While I mentioned that you ought to add alternative content for your graphical content, not each image has to be marked by the alt attribute. If you mark your decorative images with the alt attribute screenreader will try to announce them, however, it’s not what we want from decorative images.

Think about contrast

You have to be always thinking about a content contrast since this part of a11y affects almost all users of your application. If the content on the web page has low contrast with the background it’s really hard to read it even without any sight disabilities.

If you’re using google chrome, you can check a contrast of your content at the styles tab.

So, just select an HTML element, open its CSS properties and click at any color style. You may notice a new section at the bottom of the color picker that notifies you about the contrast ratio between element text and background.

At the image above, I have an issue with the contrast. Also, here you can notice two additional lines on the color palette and red signs along with A letters at the bottom. Those red signs with A letters indicate WCAG Conformance levels — a metric that indicates how accessible your website is. For the current situation with the contrast it means the following:

If your color above the top line (A Conformance level) — you have a minimum level of accessibility and does not achieve broad accessibility for many situations.
If your color between lines (AA Conformance level) — it’s ok. WCAG recommends you have at least AA Conformance level for your websites.
If your color below the bottom line (AAA Conformance level) — you’re great. However, AAA (the highest) level of accessibility can’t be achieved for all accessibility criteria.

Don’t autofocus

Autofocus is hard to get for screenreader users. Autofocus can dump screenreader users into your form with zero context, leaving them lost and confused on your page.

Autofocus can also confuse regular users, especially on mobile. So keep it simple, let people click into your inputs when they are ready. To learn more about autofocus issue please, refer to this article.

Don’t `outline: none`

It’s a pretty common approach to add outline: none style into global application’s styles since the default browser outline is ugly and can ruin your design. However, an outline is a must for keyboard users who aren’t using the mouse for interaction with your application. The outline allows them to see what section on the page is selected right now and helps them to navigate across your application.

So, the best approach is to keep an outline and just style it to fit application design. This is amazing since the outline is a common behavior for each website and will be easily recognized by the user.
Another way is to style focused elements another way: background, border or whatever. When using this approach, avoid using color alone as the only visual means of determining focus, as colorblind people may not be able to distinguish the focus state from the inactive state.
Also, if you finally decided to remove the outline in your application, you can control its behavior through JavaScript. Detect mouse users and hide outline for them, then, detect keyboard activity and show outline for them.
Finally, there is a native approach for hiding/removing outline for the user — The :focus-visible pseudo-class applies while an element matches the :focus pseudo-class and the user-agent determines via heuristics that the focus should be made evident on the element. You can read about it deeper here: https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible

For more information, I would suggest you refer to this article from a11yproject.

Use ARIA attributes

ARIA is shorthand for Accessible Rich Internet Applications. ARIA is a set of attributes you can add to HTML elements that define ways to make web content and applications accessible to users who use assistive technologies. When accessibility issues cannot be managed with native HTML, ARIA can help bridge those gaps.

There are three main components used in ARIA: Roles, States, and Properties:

Role — defines a type of user interface element. (button, menuitem, scrollbar)
States and properties— defines a state of an element (aria-checked, aria-labelledby, aria-activedescendant).

But remember the rule:

Use native HTML at all times, unless it’s absolutely, positively impossible to make an element accessible otherwise.

If you think something can’t be done using HTML, please, check it at HTML Accessibility site.

Use landmarks

This section is related to semantic HTML since HTML 5 introduced a number of semantic attributes that help screen reader users to perform navigation across the page. For instance, a screen reader will announce the start and end of each landmark on a page, and its web rotor will display a list of these roles/regions.

You can think about landmarks as about a set of anchors assistive technologies may navigate to. So, users may skip some sections or just go directly to a specific section of your web page.

Here is the list of the most common landmark: article, aside, nave, main, footer, header, etc.

However, in some specific situations (for instance, old browsers support), you need to change the behavior of the screen reader and here ARIA landmark attributes becomes handy. Landmark attributes are HTML attributes assigned to specific sections of your website. These attributes allow you to change the meaning of the specific landmark for the screen readers.

You can learn more about HTML and ARIA landmarks here: https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html

Provide a unique title for each page

A unique title for each page is a must for screenreader users since it’s the first thing that is announced by the screenreader. I bet it’s a quite big issue for Angular applications since Angular applications are single-page applications. And have one common title for each page by default.

However, it can be fixed using Title service provided by the Angular. It allows you to set a page title through the simple API.

export class AppComponent {
  constructor(title: "Title) {"
    title.setTitle('My Cool Page');
  }
}

Use Angular CDK

Since we’re talking about accessibility for Angular applications it’s must mention Angular CDK a11y package that allows you speed up accessibility development via providing implementations for common patterns. Let’s peek a boo on functionalities provided:

ListKeyManager — allows you to create keyboard navigable lists seamlessly.
Focus trap — traps a focus inside an element. Widely used for modal dialogs to trap a focus inside and not allow the user to tab out of the modal dialog.
Live announcer — provides the easiest way to announce something for screenreader users. It’s especially important for applications that have notifications and users with screenreaders. Since screenreaders can’t tell the user about notification by default.
Focus monitor — allows monitoring focus on an element and its descendants. It’s like listening for focus and blur events on the element, but packed into one service with the simple API and also allows you to understand how that element was focused — mouse, keyboard, touch or programmatically.
Styling utilities — a few SCSS utilities invented to help you building accessible components. It includes functionalities like the ability to hide elements from the screen while keeping them available for screen readers and helping you to target high contrast color schemes in your users.

Test for accessibility

If you decided to build an accessible application you ought to think about testing for accessibility. It’ll allow you not to miss something important while developing an app. Also, it’ll help you to deal with the regression.
There are two ways for testing a website for accessibility:

Manual testing — manual testing is often required since we can’t get all the issues using automated testing. Here is an amazing article on how to start manual accessibility reviews: https://developers.google.com/web/fundamentals/accessibility/how-to-review
Automated testing — in spite of we can’t get all the accessibility issues using automated testing we can save tons of time using it. So, please, check Tim Deschryver article on accessibility testing tools overview.

Conclusion

Hopefully, you already get that accessibility is a must for almost any type of web application. It improves user experience and removes barriers for almost any users and allows them to use web applications in a seamless way.

In this article, I’ve mentioned the most basic and important things you need to do to start with accessibility. Let’s make the web more accessible together!

Thank you for reading!

Useful resource:

Amazing Introductions for Accessibility:

Web Accessibility Initiative — https://www.w3.org/WAI/
The US Government guide on accessibility — https://accessibility.digital.gov/
Developer Mozilla Network — https://developer.mozilla.org/en-US/docs/Web/Accessibility

Guides and researches

https://webaim.org/

How to build accessible components

Nebular Hacktoberfest

Nik Poltoratsky — Thu, 03 Oct 2019 08:55:43 +0000

Hacktoberfest is started a few days ago! And you still have no idea on how to start your amazing journey into the open-source world and finally get your T-Shirt? I have an answer for you. One of the best ways to start open-source contributions is to help us with Nebular.

What is Nebular?

Nebular is a customizable Angular 8 UI Library with a focus on beautiful design and the ability to adapt it to your brand easily. It comes with 4 stunning visual themes, a powerful theming engine with runtime theme switching and support of custom CSS properties mode. Nebular is based on Eva Design System specifications.

How to start contributions?

Open issues at the GitHub repository
Search for issues for starters (issues which contain following labels on GitHub):
- help wanted
- good first issue
Deal with those issues!
Get your T-Shirt!

What's more important here, don't hesitate! Find interesting issues, deal with them and have fun! 🥳
Drop me a line if you have any questions - @nikpoltoratsky

Debugging - you’re doing it wrong. 10 techniques to find a bug in your code

Nik Poltoratsky — Tue, 23 Jul 2019 13:02:53 +0000

Do you remember those long, long hours spent on debugging? When you're staring at a codebase and can't figure out what exactly went wrong? You're not alone! I think all developers struggle with debugging from time to time. That's why in the article I'm going to tell you about my favorite approaches to finding bugs in the code.

Google error message
Console log everything
Use debugger
Problem localization
Create a few tests
Analyze logs
Ask a friend
Git bisect
Talk to a rubber duck
Tambourine Dancing

Google error message

I'm not going to sort those tips by usefulness but google error message is at the first place by a reason. I think, if you can't even understand an error message from the first sight, the easiest way to solve the problem is to google error message.

In most of the cases, the error message you are facing was googled before by someone else. We have a lot of beautiful places like StackOverflow and GitHub issues, where people aim to help each other. That's why you can not only find the answer but also steps to avoid such error or motivation why this error occurred in the first place. So, why not to google the error? It's the easiest way here.

Console log everything

I think it's one of the most popular ways to find a bug in the codebase - add a tenth of console.log(...) statements across the codebase, rerun the application and try to figure out what went wrong.

I like it, and from my point of view, it's the right solution for simple issues, which are already localized to a few classes. But it's always a bad idea to start seeking with console.log(...)s when you have no idea what's going on here and where that creepy bug resides. Because in that case you may miss something important not logged and you'll have to add console logs and rerun application multiple times until you find the cause of failure.

Use debugger

I don't think I have too much to say here. All developers know what debugger is and why to use it. Instead, I'm going to tell you about a small discussion that flared up the other day in the office with one of my teammates.

A few days ago, I was discussing different ways of debugging with one of my teammates (that's the reason why this article appeared). And I said that one of the most robust ways to find an issue is to use a debugger. Easy as that - you're setting breakpoints, then, performing some actions and going step by step through your codebase, observing how the state of the application changes. What can be more straightforward as that?

While my teammate introduced an exciting idea - when you're using the debugger, you are not training your analytical skills and critical thinking. The reason is that with debugger you're just staring at the window with variables and waiting for incorrect behavior. While when you're digging through the codebase without the debugger, you're more focused and trying to understand what's going on and learn something new each time you're seeking for a bug.

What do you think about debugger vs. manual investigations? Please, give me your ideas in the comments.

Problem localization

The key idea of the Problem localization method is to comment/remove a code step by step until you figure out what went wrong. It works especially useful in cases when you are writing an algorithm or some business logic a pretty long time without compiling and executing the application.

In such cases, I'm always doing something wrong, and the easiest way for me is to comment code partially and try to intercept disappeared errors. Then, repeat it until all bugs will be found and revamped.

In some cases it might be a good idea to use the binary search line approach when you comment half of the code (or remove half of the files) - then check if the error is still here. If yes repeat the same with the half of this half, if now - same with the other half.

Of course, this only works in particular cases when you are able to comment/ remove code parts still keeping it working.

Create a few tests

Ok, that's the crazy one, whereas it could be useful in some particular cases. From my sight, it works well when you have some algorithm that works incorrectly, and is too complex to write console.log's or go through it using the debugger.

In that case, it might be useful to write a few tests for it. Tests could help you localize the issue in the algorithm.

After that, when the bug is localized, and you know where to search, you may use another approach to fix it finally.

Analyze logs

Yep, I know you hate to analyze all those 10mb text files with logs. But quite often it could save you a few hours of debugging. Of course, logging has to be configured adequately first of all. Collected log files have to be kept during the appropriate amount of time. But if all conditions are met - you're lucky. It's like console logging, but you already have all console.logs on their places and can just read through actions performed on your system.

But unfortunately, quite often it's a dream... We're not always paying enough attention to logging.

Ask a friend

It's pretty obvious, but we're not doing it quite often. I think all of us have more experienced teammates at the office. Otherwise, we can find an expert across the internet. Don't be afraid, ok? People are always ready to help you!

But. You need to satisfy one requirement - check all the available sources of the information before asking somebody. If you're asking for help with something easy, which is written on the second page of the documentation, then. Well. Be ready to run away!

Git bisect

Git not only helps us to keep an application revisions history, but it also provides us with a few tools for debugging. One of those tools is a git bisect - tool for performing a binary search across your git history. It's quite useful in case you didn't work with the codebase for a while, and since your last intervention, a few hundred commits were added. And now, you encounter a bug and have no idea how and when it appeared. But you remember you didn’t have it in version 2.0.15, for instance.

In that case git bisect will help you. The idea is pretty simple, you start the debugging process with git bisect start, then, we need to mark the current version as bad version because we have a bug here - git bisect bad. After that, we have to tell git about a good working version: git bisect good 2.0.15. On that stage, setup is done, and we can start searching.

git bisect selects commit in the middle of bad-good range and checks out on it. Then, we have to check if we have that bug in this revision? If yes - run git bisect bad, if no - run git bisect good. Then, git will choose a new commit in the original bad-good range, and we have to repeat the process until a commit with the bug is found.

git bisect is a pretty powerful tool that's why a full description will be out of the format of the article, but here is a link with a good explanaition.

Talk to a rubber duck

It's one of the most potent methods of understanding what's going on in the code. The main idea is that you need to find a rubber duck, put it in front of yourself and then, explain your system to it, starting from general concepts and then going line by line. You can read more about it here. I like this idea and use it regularly, so, let me tell you a short story about how I used it the first time and even didn't notice it.

When I just started my career as the programmer, I was building an Android application which contained quite complex handwritten animations. I made one of those animations carefully, step by step, and everything was fine until I stuck.

I had an animation code for no more than 150 lines. And I couldn't find a problem why it wasn't working. I checked all the algorithms multiple times but still nothing. After staring at the screen for a few hours, I decided to ask a teammate for help.

I've started a detailed explanation of how that animation works, and in a minute, I found the issue! One of the methods implicitly converted float to int🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️. And It took me one minute to understand it when I tried to explain it in detail to my teammate.

That time I even didn't know that's it's a method of a rubber duck. I realized that, later. But I already understood how powerful it is.

Tambourine Dancing

It's my favorite way to solve problems with the software. All you need is tambourine. You need to dance around your workstation, knocking on a tambourine. It will be a big plus if you have a tambourine with the logo of technology you're working with. For instance, I have a tambourine which helps me to solve issues with my microservices:

But it's utterly useless for front-end applications.

Conclusion

Thank you for reading this! Hopefully, you've learned something new from the article. The last thing I want to reveal here for those of you who read the material to the end is that the most powerful way to deal with bugs and issues in the codebase is to write code without bugs. Just, ask your manager. 😅

Anyway, be focused and consistent. Do your investigation step by step and use the techniques mentioned above. And you'll resolve all your bugs efficiently.

Follow me on Twitter to staying tuned and let me know if you have any particular topics you would like to hear about!

Don't follow RxJS Best Practices

Nik Poltoratsky — Mon, 15 Jul 2019 09:50:13 +0000

Nowadays more and more developers learn RxJS and use it properly with best practices in mind. But we shouldn't. All those so-called best practices require to learn something new and to add additional code in your projects.
Moreover, using the best practices we're risking to create a good code base and make your teammates happy! 🌈
Stop being a gray mass! Break the rules! Stop using best practices!

Here are my suggestions to you on how to deal with those so-called RxJS best practices in Angular:

Don't unsubscribe
Subscribe inside subscribe inside subscribe inside…
Never use pure functions
Always subscribe manually, don't use async pipe
Expose subjects from your services
Always pass streams to child components
Marble diagrams? No, it's not for you

Don't unsubscribe

Everybody says that we have to always unsubscribe from observables to prevent memory leaks.

But I can't agree with it. Seriously, who decided that you have to unsubscribe from observables? You don't have to do that. Let's play a game! Which unsubscribe implementation of those Angular components is the best?

That one with takeUntil operator?



@Component({ ... })
export class MyComponent implements OnInit, OnDestroy {

  private destroyed$ = new Subject();

  ngOnInit() {
    myInfiniteStream$
      .pipe(takeUntil(this.destroyed$))
      .subscribe(() => ...);
  }

  ngOnDestroy() {
    this.destroyed$.next();
    this.destroyed$.complete();
  }
}

Or that one with takeWhile operator?



@Component({ ... })
export class MyComponent implements OnInit, OnDestroy {
  private alive = true;
  ngOnInit() {
    myInfiniteStream$
      .pipe(takeWhile(() => this.alive))
      .subscribe(() => ...);
  }
  ngOnDestroy() {
    this.alive = false;
  }
}

Exactly! Neither! Both takeWhile and takeUntil operators are implicit and may be hard to read 🤓 (sarcasm). The best solution is to store each subscription in a separate variable and then unsubscribe on component destroy in an explicit way:



@Component({ ... })
export class MyComponent implements OnInit, OnDestroy {

  private subscription;

  ngOnInit() {
    this.subscription = myInfiniteStream$
      .subscribe(() => ...);
  }

  ngOnDestroy() {
    this.subscription.unsubscribe();
  }
}

That works especially good in cases when you have multiple subscriptions:



Component({ ... })
export class MyComponent implements OnInit, OnDestroy {

  private subscription1;
  private subscription2;
  private subscription3;
  private subscription4;
  private subscription5;

  ngOnInit() {
    this.subscription1 = myInfiniteStream1$
      .subscribe(() => ...);
        this.subscription2 = myInfiniteStream2$
      .subscribe(() => ...);
        this.subscription3 = myInfiniteStream3$
      .subscribe(() => ...);
        this.subscription4 = myInfiniteStream4$
      .subscribe(() => ...);
        this.subscription5 = myInfiniteStream5$
      .subscribe(() => ...);
  }

  ngOnDestroy() {
    this.subscription1.unsubscribe();
    this.subscription2.unsubscribe();
    this.subscription3.unsubscribe();
    this.subscription4.unsubscribe();
    this.subscription5.unsubscribe(); 
  }
}

But that solution is not perfect yet. What could be done better? How do you feel? How could we make that code more clean and readable?
Yeah, I have the answer for you! Let's remove all that ugly unsubscribe statements at all.



@Component({ ... })
export class MyComponent implements OnInit {

  ngOnInit() {
    myInfiniteStream$
      .subscribe(() => ...);
  }
}

Excellent! We've removed all the redundant code and now it looks simpler and even saves us a bit of memory on our hard drives. But what will happen with myInfiniteStream$ subscription?

Forget about it! 😅 Let's leave that job for the garbage collector, otherwise, why does it exist, right?

Use subscribe inside subscribe inside subscribe inside…

Everybody says that we should use *Map operators to chain observables instead of subscribing inside subscribes to prevent callback hell.

But I can't agree with it. Seriously, why not? Why should we use all those switchMap/mergeMap operators? How do you feel about that code? Easy to read? Do you really like your teammates so much?



getUser().pipe(
  switchMap(user => getDetails(user)),
  switchMap(details => getPosts(details)),
  switchMap(posts => getComments(posts)),
)

Don't you think it too neat and cute? You shouldn't write code that way! You have another choice, take a look here:



getUser().subscribe(user => {
  getDetails(user).subscribe(details => {
    getPosts(details).subscribe(posts => {
      getComments(posts).subscribe(comments => {  

        // handle all the data here
      });
    });
  });
})

Much better, huh?! Always write code this way if you hate your teammates and don't want to learn new RxJS operators.

Be bright! Let your team members feel a bit of nostalgia with callback hell.

Never use pure functions

Everybody says that we should use pure functions to make our code predictable and easier to test.

But I can't agree with it. Seriously, why should you use pure functions? Testability? Composability? It's hard, it would be much easier to affect the global world. Let's take a look at the example:



function calculateTax(tax: number, productPrice: number) {
 return (productPrice * (tax / 100)) + productPrice; 
}

For instance, we have a function which calculates a tax - it's a pure function it will always return the same result for the same parameters. It's easy to test and compose with other functions. But, do we really need that behavior? I don't think so. It would be easier to use a function without parameters:



window.tax = 20;
window.productPrice = 200;

function calculateTax() {
 return (productPrice * (tax / 100)) + productPrice; 
}

Indeed, what can go wrong? 😉

Always subscribe manually, don't use async

Everybody says that we have to use async pipe in Angular templates to facilitate subscriptions management in components.

But I can't agree with it. We've already discussed subscriptions management with takeUntil and takeWhile and agreed that these operators are from an evil one. Though, why should we treat async pipe another way?



@Component({  
  template: `
    <span>{{ data$ | async }}</span>
  `,
})
export class MyComponent implements OnInit {

  data$: Observable<Data>;

  ngOnInit() {
    this.data$ = myInfiniteStream$;
  }
}

Do you see that? Clean, readable, easy to maintain code! Argh. It's not allowed. As for me, it would be much better to put the data in local variable and just use that variable in the template.



@Component({  
  template: `
    <span>{{ data }}</span>
  `,
})
export class MyComponent implements OnInit {
  data;

  ngOnInit() {

    myInfiniteStream$
      .subscribe(data => this.data = data);
  }
}

Expose subjects from your services

There is a pretty common practice to use Observable Data Services in Angular:



@Injectable({ providedIn: 'root' })
export class DataService {

  private data: BehaviorSubject = new BehaviorSubject('bar');

  readonly data$: Observable = this.data.asObservable();

  foo() {
    this.data$.next('foo');
  }

  bar() {
    this.data$.next('bar');
  }
}

Here we're exposing data stream as observable. Just to make sure it can be changed only through a data service interface. But it confuses people.

You want to change the data - you have to change the data.

Why add additional methods if we can change the data on the place? Let's rewrite the service to make it easier to use;



@Injectable({ providedIn: 'root' })
export class DataService {
  public data$: BehaviorSubject = new BehaviorSubject('bar');
}

Yeah! Do you see that? Our data service became smaller and easier to read! Also, now we can put almost anything in our data stream! Awesome, don't you think so?🔥

Always pass streams to child components

Have you ever heard about Smart/Dump components pattern, that can help us to decouple components from each other? Also, that pattern prevents child component from triggering actions in parent components:



@Component({
  selector: 'app-parent',
  template: `
    <app-child [data]="data$ | async"></app-child>
  `,
})
class ParentComponent implements OnInit {

  data$: Observable<Data>;

  ngOnInit() {
    this.data$ = this.http.get(...);
  }
}

@Component({
  selector: 'app-child',
})
class ChildComponent {
  @Input() data: Data;
}

Do you like it? Your teammates also like it. In case you want to revenge them, you need to rewrite your code in the following way:



@Component({
  selector: 'app-parent',
  template: `
    <app-child [data$]="data$"></app-child>
  `,
})
class ParentComponent {

  data$ = this.http.get(...);
  ...
}

@Component({
  selector: 'app-child',
})
class ChildComponent implements OnInit {

  @Input() data$: Observable<Data>;

  data: Data;

  ngOnInit(){
    // Trigger data fetch only here
    this.data$.subscribe(data => this.data = data);
  }
}

Do you see that? We're not handling subscriptions in the parent component anymore. We're just passing subscription to the child component.
If you follow that practice your team members will cry tears of blood during debugging, believe me.

Marble diagrams? No, it's not for you

Do you know what are marble diagrams? No? It's good for you!

Let's assume we wrote the following function and going to test it:



export function numTwoTimes(obs: Observable<number>) {
  return obs.pipe(map((x: number) => x * 2))
}

Many of us will use marble diagrams to test the function:



it('multiplies each number by 2', () => { 
  createScheduler().run(({ cold, expectObservable }) => {
    const values = { a: 1, b: 2, c: 3, x: 2, y: 4, z: 6 }
    const numbers$ = cold('a-b-c-|', values) as Observable<number>;
    const resultDiagram = 'x-y-z-|';
    expectObservable(numTwoTimes(numbers$)).toBe(resultDiagram, values);
  });
})

But, who the hell wants to learn a new concept of marble diagrams? Who wants to write clean and laconic code? Let's rewrite the test in a common manner.



it('multiplies each number by 2', done => {
  const numbers$ = interval(1000).pipe(
    take(3),
    map(n => n + 1)
  )
  // This emits: -1-2-3-|

  const numbersTwoTimes$ = numTwoTimes(numbers$)

  const results: number[] = []

  numbersTwoTimes$.subscribe(
    n => {
      results.push(n)
    },
    err => {
      done(err)
    },
    () => {
      expect(results).toEqual([ 2, 4, 6 ])
      done()
    }
  )
})

Yeah! It looks one hundred times better now!

Conclusion

You're a hero if you've read all the advice above. But. Well. If you recognized your train of thoughts, I have a piece of bad news for you. It was a joke.

Please, never do what I said in that article. Never let your teammates cry and hate you. Always strive to be a decent and neat person. Save the world - use patterns and best practices!

I just decided to cheer you up and make your day a little bit better. Hopefully, you like it.

Stay tuned and let me know if you have any particular Angular topics you would like to hear about!

DEV Community: Nik Poltoratsky

How to Create an Admin Panel for Your PostgreSQL Database on Railway Cloud

Step 1: Connect Your Database to UI Bakery

Navigate to Data Sources in UI Bakery

Connect to PostgreSQL

Connect Data Source

Step 2: Create a New Application

Step 3: Display Data

Configure a Data Table

Step 4: Enable and Configure CRUD Operations

Editing Records

Adding New Records

Deleting Records

Step 5: Implement Filtering

Add a Filter Input

Configure Filtering

Conclusion

How to create Supabase admin dashboard?

Connect supabase to UI Bakery

View supabase data

Add form to edit records

Publish an app to make it available for your users

Open-Source Headless CMS in 2024

You know what would be awesome?

Strapi: The Code Anarchist

Keystone 6: The GraphQL Behemoth

Ghost: The Underground Storyteller

Directus: The Shape-Shifting Maverick

Decap CMS: The Static Site Outlaw

Payload CMS: The Customization Insurgent

Tina CMS: The Editing Renegade of React

10 Web Dev Tips to Stay on the Wave in 2024

Check UI BAKERY

1. Progressive Web Apps (PWAs)

2. API-First Design

3. Blockchain-Based Applications

4. Machine Learning in the Browser

5. Motion UI

6. Low-Code and No-Code Development

7. Cybersecurity by Design

8. Artificial Intelligence Integration

9. Extended Reality (XR) Experiences

10. Voice Search Optimization

Conclusion

7 Programming Riddles That Even Elite Coders Can't Solve

Cache invalidation

Scrolling

When to upgrade?

Pros:

Cons:

This is the case now, but before…

Naming things

N+1

ORM

REST-like APIs

Dates

Finally

PS

PPS

Agile Angular modules configuration

Table of contents:

How we use DI most of all

Putting data in the DI

Building configurable modules

Using forRoot/forFeature for module configuration

Why it's not a good idea?

Recap

Draggable Table with Angular CDK

What are we going to build?

What do we need for that?

Angular CDK

Angular CDK Table Module

Create Table

Header row configuration

Table row configuration

Table cells configuration

Datasource

What is Angular CDK Table data source

How to attach data to the table?

Adding Drag & Drop

Don’t `outline: none`