DEV Community: Viktor Pasynok

Managing Complex Front-End Apps: Lessons Learned (and a Tool I Built to Help)

Viktor Pasynok — Sun, 02 Feb 2025 18:19:24 +0000

I’ve been working on large front-end applications for a while, and one of the biggest challenges isn’t just managing features—it’s managing the connections between them. Dependencies, startup order, feature toggles, conditional modules… it gets messy fast.

I recently hit a point where existing tools felt limiting. So, instead of hacking around the problem, I built a tool: app-compose.

It’s not another framework or state manager. Think of it as a lightweight system for:

Managing feature dependencies (both strict and optional).
Controlling startup sequences with minimal boilerplate.
Handling feature toggles without sprinkling if conditions everywhere.
Debugging why something started, skipped, or failed (because tracing this manually sucks).

The idea isn’t revolutionary, but it’s been a game-changer for how I organize complex apps. I also made sure the docs are clear, with simple examples and analogies to keep things beginner-friendly.

I’d love to hear how others manage this kind of complexity. What’s worked for you? What tools do you rely on?
And if you’re curious, here’s the project: GitHub link.

Why Feature Toggles Could Be Your Front-End's Worst Nightmare

Viktor Pasynok — Wed, 13 Nov 2024 16:03:41 +0000

Feature toggles (or feature flags) have become a fundamental part of front-end development. They provide a way to dynamically enable or disable features without deploying new code, making it possible to run A/B tests, roll out features gradually, or easily turn off problematic functionality. However, with all the benefits they bring, feature toggles can also lead to serious challenges.

The Hidden Complexity of Feature Toggles

When you start using feature toggles in a front-end project, everything may seem straightforward: add a toggle, check its value, and determine if a feature should run or not. But as your project scales and you add more toggles, the complexity increases exponentially. Here are some of the common problems that arise:

Configuration Overload: A small project might have only a handful of toggles, but larger applications can have dozens or even hundreds. Managing which toggles are on, off, or in some intermediate state becomes cumbersome. Developers might have to juggle multiple configurations for different environments, making debugging more difficult.
Interdependencies Between Features: A more insidious problem comes from the way features interact. Features that are meant to be toggled independently can have hidden dependencies. If one toggle changes the behavior of a shared component, another feature relying on that component might break in unexpected ways. It becomes harder to reason about the codebase, and simple changes can have unintended consequences.
Codebase Fragmentation: As you add feature toggles, your code starts to split into different execution paths based on toggle states. Over time, this can make the codebase hard to navigate. You may have conditional checks scattered throughout, and the readability and maintainability of the code suffer. Refactoring becomes a dangerous task, as ensuring all toggle states are handled correctly is tricky and error-prone.
Testing Challenges: To confidently release new features, you must test the application in all possible toggle configurations. As the number of toggles grows, the combinations become unmanageable. Even if you automate testing, it can become prohibitively expensive to cover every scenario, especially as features are turned on and off.
Performance Overhead: Feature toggles can also introduce performance issues. Checking a toggle’s state isn’t costly on its own, but when many toggles are checked repeatedly in the render process, it can degrade performance. Moreover, toggles often require infrastructure for configuration, increasing the load on your backend.

How Do We Manage Feature Toggle Complexity?

Handling feature toggles well requires thoughtful strategies and sometimes specialized tools. Some approaches include:

Centralizing Configuration: Instead of sprinkling toggle logic throughout your codebase, try to centralize it. Use a dedicated service or module to manage the state of all toggles and handle complex dependencies in one place.
Strict Dependency Management: Carefully track which features depend on others. Document these relationships and, if possible, enforce constraints in code to ensure that features are toggled in a way that makes sense.
Automated Testing and Analysis: Invest in automated tools that can analyze toggle coverage. Some systems can warn you when a change might break an existing toggle configuration or generate test cases for common scenarios.
Periodic Cleanup: Feature toggles shouldn’t live forever. Once a feature is stable and rolled out to all users, remove the toggle and the associated logic to simplify the codebase. A regular cleanup process can help prevent “toggle bloat.”

Introducing app-compose: A New Way to Manage Dependencies

When feature toggles are used in an application with many interdependent parts, managing these dependencies can feel overwhelming. This is where a tool like app-compose can help.

app-compose allows you to define features as isolated containers, each with explicit dependencies. Instead of having to manually track which features are ready or handle complex chains of conditions, app-compose orchestrates everything for you. By using app-compose, you can ensure that features only initialize when their dependencies are in the right state, significantly reducing the risk of hidden bugs or runtime errors.

Here’s a simple example of how app-compose can simplify dependency management:

import { createContainer, compose } from '@grlt-hub/app-compose'

const fetchToggles = () => ({ referral: false });

const featureToggle = createContainer({
  id: 'featureToggle',
  start: async () => {
    const data = await fetchToggles();

    return { api: { data } };
  },
});

const referral = createContainer({
  id: 'referral',
  dependsOn: [featureToggle],
  enable: (deps) => deps.featureToggle.data.referral,
  start: () => ({ api: null }),
});

await compose.up([featureToggle, referral]);

Explanation:

fetchToggles: Fetches the feature toggles and returns an object indicating whether each feature is enabled or disabled.
featureToggle: A container that fetches the toggles. The data is made available via its api.
referral: A container that depends on featureToggle. It checks if the referral feature is enabled using the enable method. If the feature is not enabled, the referral container will not start.

With app-compose, taming the complexity of feature toggles becomes not just manageable but structured and efficient.

Docs
GitHub repo

How to create scalable, module-based applications with ease.

Viktor Pasynok — Thu, 07 Nov 2024 16:07:42 +0000

Modern applications thrive on modular architecture, adapting seamlessly to evolving business needs. To achieve true modularity, though, you need more than just independent components—you need an efficient way to bring them together. This means controlling how modules load, in what order, and with which dependencies. It gets even trickier when you want to turn off parts of the system without any traces in the code, like if/else statements, and without affecting the stability of other components.

The simplest example: imagine your application has numerous interconnected features. Sometimes, you need to disable one of them. Here’s the catch: some features may directly depend on it, while others may be affected indirectly (transitively). If you overlook these dependencies, your app might crash. And if you need to disable more than one feature, the combinations can become complex and error-prone. It would be ideal to have a way to explicitly describe feature dependencies and safely disable them without missing anything.

For instance, like this

const user = createContainer({
  id: 'user',
  start: async () => {
    const data = await fetchUser();

    return { api: { data } };
  },
});

const accounts = createContainer({
  id: 'accounts',
  dependsOn: [user],
  start: async ({ user }) => {
    const data = await fetchAccounts({ id: user.data.id });

    return { api: { data } };
  },
  enable: ({ user }) => user.data.id !== null,
});

const wallets = createContainer({
  id: 'wallets',
  dependsOn: [accounts],
  start: () => ({ api: null }),
});

...and expect something like this:

compose.up start

user: 'idle',     accounts: 'idle',     wallets: 'idle'
user: 'pending',  accounts: 'idle',     wallets: 'idle'
user: 'done',     accounts: 'idle',     wallets: 'idle'

# if user.data.id
user: 'done',    accounts: 'pending',  wallets: 'idle'
user: 'done',    accounts: 'done',     wallets: 'pending'
user: 'done',    accounts: 'done',     wallets: 'done'

# else
user: 'done',    accounts: 'off',      wallets: 'off'

compose.up done

I created the @grlt-hub/app-compose library, which makes this a reality.

The library offers convenient functions for creating and composing modules into a single system. Each module is encapsulated in a container with a clear configuration, including parameters like id, dependsOn, optionalDependsOn, start, and enable. Developers describe containers and launch them using compose.up fn, without the need to worry about the order of execution. This approach makes working with containers intuitive and close to natural language.

Provides a simple and intuitive developer experience (DX).
Designed with a focus on quality and performance.
Weighs less than 1.5 kB, making it lightweight.
Covered by 100% tests, including type tests.
Ensures high performance, suitable for scalable applications.
Includes debugging tools to facilitate the development process.
Offers the ability to visualize the system composed of containers effectively (including transitive dependencies and their paths).
Follows semantic versioning (semver), guaranteeing stability and predictability of changes with each release.

Ready to simplify your modular architecture? Dive into app-compose and experience efficient, scalable dependency management. Check it out and let us know how it transforms your projects!

Clean up your code with ease

Viktor Pasynok — Mon, 22 Jan 2024 14:30:00 +0000

Hi, I am the creator of the Pure Index tool. Its essential purpose is to clean your packages of unused exports with ease. In this article, I share a brief story of its inception.

I work in a monorepo that contains dozens of packages from which we build a website as a team. One of the problems we have encountered is dead code. For example, a TextCountDown component was written a couple of years ago, and the code where it was used was removed at some point. Ideally, the component should have been removed as well, but it wasn't. Yes, it was a mistake, but it happened, and we needed to find a way to prevent such situations in the future.

What tools would have helped at that point? ESLint? Perhaps, but ESLint would not have identified TextCountDown as unused because it was exported from a file. And that's where ts-prune came on the scene. Its first run was both a disappointment and a joy for us. The significant number of unused exports displayed in the console meant that removing them would reduce the code base's size, build time, etc. We removed hundreds of such exports and all the dead code in a few iterations. That's how it seemed to us...

Packages have index files (index.ts, for example) that describe what the package exports. ts-prune showed all exports from these files as unused, which was a false positive. Some exports were dead, perhaps whole packages, but not all. The reason was in the import paths. There was no direct connection between import {smth} from 'my-package' and export {smth} from '~/src/index.ts'. Maybe it was possible to somehow configure ts-prune to handle this, but we found a case that wouldn't help.
There is a ui-kit package whose code is stored in another repository, and the package itself is used in other products and internal systems.That's when I decided to create Pure Index. In combination with ts-prune, it allowed the automate the process of searching for dead code as follows:

search for all unused exports from the index file
delete them
run ts-prune inside the package to remove the dead code

Finding unnecessary exports involves:

collect all package exports into exports Set
traverse all files where package import may occur
if the import is found, remove it from exports Set
if the size of the exports Set became equal to 0, then exit with success
if the exports Set size is not equal to 0, then exit with an error

Pure Index handles this task in ~400 ms even for large repositories, for example, when analyzing ui-kit in two repositories that contain more than 15'000+ .ts and tsx files. Of course, Pure Index's algorithm is a bit more complex. You can read about it in the "How Does It Work" section.

As an added bonus, Pure Index allows you to collect all X package imports within a repository. For example, you want to find out how many functions from lodash you use. Just run pure-index -u lodash, and you'll get a complete list.

Pure Index is available on GitHub. Just follow the link and start using it.

P.S. I will be happy if you give a star to the repository and share your opinion about the tool 🌿

Exports in package.json

Viktor Pasynok — Sat, 06 Mar 2021 18:01:32 +0000

Hi there! I'm a front-end developer and ship my code via npm-packages.

Once upon a time, I faced problems that led me to the usage of exports field in package.json

Problem #1

Packages may export functions with the same names but doing different things.

Let's look at 2 state managers: Reatom and Effector. Both of them have a function called createStore. If we try to export it from the one package (name it vendors) we'll get this:

// @some/vendors/index.ts

export { createStore } from '@reatom/core';
export { createStore } from 'effector';

We're faced with a name conflict. This code doesn't work. We can repair it with an as syntax:

// @some/vendors/index.ts

export { createStore as reatomCreateStore } from '@reatom/core';
export { createStore as effectorCreateStore } from 'effector';

Not that pretty? Yeah, It kills DX.

On the other hand, I propose to avoid the necessity of writing as every time and resolve name conflicts. Here is an example:

// @some/vendors/reatom.ts

export { createStore } from 'reatom';

// @some/vendors/effector.ts

export { createStore } from 'effector';

In 2 different files we write exports as usual and then import needed realization of createStore:

// someFile.ts

import { createStore } from 'vendors/effector';

Problem #2

Most likely vendors package contains not only a state manager. It could contain another one lib. Runtypes, for example.
Without using exports for vendors imports will look like:

// someFile.ts

import { createStore, Dictionary, createEvent, Record } from 'vendors';

It looks mixed. In my opinion, it will be better to write something like:

// someFile.ts

import { createStore, createEvent } from 'vendors/effector';
import { Dictionary, Record } from 'vendors/runtypes';

It would be nice to encapsulate the names of libraries. It could be useful for refactoring.

// someFile.ts

import { createStore, createEvent } from 'vendors/state';
import { Dictionary, Record } from 'vendors/contract';

Solution

exports field in package.json helps us to achieve our goal.

// package.json

"exports": {
  "./contract": "./build/contract.js",
  "./state": "./build/state.js",
  "./package.json": "./package.json"
},

We just say to bundler how to resolve imports.

But if you use TypeScript you need to do one more thing.

There is a field named types in package.json. It allows us to specify the location of package types.

Unfortunately, the type of types is a string. We can't specify types for both contract and state. What should we do?

Field typesVersions resolves this problem.

// package.json

"typesVersions": {
  "*": {
    "contract": ["build/contract.d.ts"],
    "state": ["build/state.d.ts"]
  }
},

We do the same thing as for js files but for d.ts. And make types working.

Conclusion

Of course, the goal of exports not only a creation vendors packages. It could help us to improve DX.

For example, base import from Effector looks like:

import { createEvent } from 'effector';

For supporting old browsers it looks like:

import { createEvent } from 'effector/compat';

What else kind of problems exports resolves? You can see here.
Also, you can see the repository with an example here.

Thanks!