Forem: Andreas Nicolaou

Say Goodbye to Try-Catch Blocks Forever!

Andreas Nicolaou — Sun, 17 Aug 2025 20:50:11 +0000

Error handling is a necessary but often frustrating part of JavaScript development. Wrapping functions in try…catch blocks clutters your code, making it harder to read and maintain.

Wouldn’t it be great if you could automate error handling while keeping your code clean and functional?

That’s exactly what @andreasnicolaou/safe does.

This lightweight library automatically wraps your functions and promises in a safe execution environment, ensuring errors are caught without the need for repetitive try…catch blocks.

Why Use @andreasnicolaou/safe?

No more try…catch spam — Keep your code clean and readable.
Works with both synchronous & asynchronous functions — No need to handle errors separately.
Customizable error logging — Integrate with logging tools like Sentry.
Functional programming friendly — Compose operations without error-handling clutter.
TypeScript optimized — Enjoy full type inference and guards.
Framework-agnostic — Works seamlessly with React, Node.js, Deno, and more

To install @andreasnicolaou/safe, simply run:

npm install @andreasnicolaou/safe

For full usage details and API documentation, visit the official npm page:

npmjs.com

Stop using CSS Class Selectors in Jasmine Tests: Here's a Better Way

Andreas Nicolaou — Sun, 17 Aug 2025 20:46:58 +0000

When writing end-to-end or integration tests, how we select elements matters. A lot.

If you've ever updated a class name in a component and had half your test suite crumble like a stale cookie, you've experienced first-hand why CSS classes aren't the most stable way to identify elements in tests.

That's exactly why I built @andreasnicolaou/eslint-plugin-no-classes-by-css an ESLint plugin designed to enforce better testing practices by preventing the use of CSS class selectors in By.css() calls.

https://www.npmjs.com/package/@andreasnicolaou/eslint-plugin-no-classes-by-css

Let me walk you through the why, the what, and the how.

Why Avoid CSS Classes in Tests?
In Jasmine (and Protractor) tests, a common pattern for locating elements is:

element(By.css('.login-button'));

Looks fine, right? Until your designer decides to rename .login-button to .btn-primary, and now your test is broken-not because the app changed functionally, but because the selector changed superficially.

Using class selectors tightly couples your test code to styling decisions. This is fragile and leads to:

Brittle tests that fail on non-functional changes
Hard-to-maintain test suites
Poor separation of concerns

IDs or tag-based selectors tend to be more semantically meaningful and less likely to change arbitrarily.

The Plugin: @andreasnicolaou/eslint-plugin-no-classes-by-css

This ESLint plugin enforces a simple rule: Don't use CSS class selectors in By.css().

It flags the following:

// ❌ Not allowed
element(By.css('.my-class'));

But allows these if configured:

// ✅ Allowed (with allowIds)
element(By.css('#submit-button'));
// ✅ Allowed (with allowTags)
element(By.css('button'));

Getting Started
1. Install the plugin
Depending on how ESLint is set up in your project:

# If ESLint is installed globally
npm install -g @andreasnicolaou/eslint-plugin-no-classes-by-css

# Or locally in your devDependencies
npm install -D @andreasnicolaou/eslint-plugin-no-classes-by-css
@andreasnicolaou/eslint-plugin-no-classes-by-css

npmjs.com

2. Configure .eslintrc

{
  "plugins": [
    "@andreasnicolaou/no-classes-by-css"
  ],
  "rules": {
    "@andreasnicolaou/no-classes-by-css/no-classes-by-css": [
      "error",
      {
        "allowIds": true,
        "allowTags": true
      }
    ]
  }
}

Configuration Options

allowIds: (default: false)
Allow ID selectors like By.css('#user-id')
allowTags: (default: false)
Allow tag selectors like By.css('input')
disallowClasses: Always true
Disallows selectors like By.css('.username-field')

Real-World Example
Bad 👎

const loginButton = element(By.css('.login-btn'));

Better 👍

const loginButton = element(By.css('#login'));

Even Better
Use a dedicated test ID or data attribute with a custom selector strategy.

Autofix?
Not yet. The plugin currently does not support autofix, since rewriting selectors correctly often requires human context.

But it will warn you, and that's a great first step toward cleaner tests.

Final Thoughts

Tests should be resilient and easy to maintain. By avoiding class-based selectors, you're building test suites that are more stable, more semantic, and less prone to breaking from visual or stylistic changes.
If this sounds like a headache you've dealt with before, give @andreasnicolaou/eslint-plugin-no-classes-by-css a spin. Drop it into your config, commit to better practices, and spend less time debugging fragile selectors.
Let's write tests that can stand the test of time.

Thanks for reading! If you found this helpful, share it with your team - or better yet, drop a star on the GitHub repo. ✨

Toastify: The Lightweight, No-Dependency Toast Notification Library for Your Web Apps

Andreas Nicolaou — Sun, 17 Aug 2025 19:37:15 +0000

When building modern web applications, user notifications are essential for enhancing UX. Whether it’s success messages, errors, or general information, toast notifications offer a seamless way to communicate with users. However, many notification libraries come with unnecessary bloat, dependencies, or limited customization options.

Enter Toastify, a fast, lightweight, and fully customizable toast notification library designed to provide clean and efficient alerts with zero dependencies.

In this article, we’ll explore why Toastify is the perfect choice for developers who want simple yet powerful toast notifications in their projects.

Why Choose Toastify?

No Dependencies
Fully Customizable
Flexiple API

npm install @andreasnicolaou/toastify

Live demo: View here

If you like what you see drop a ⭐️ here: Git Repo

Looking for a client-side expression language compatible with Symfony Expression Language?

Andreas Nicolaou — Mon, 03 Feb 2025 19:36:01 +0000

A TypeScript implementation of the popular Symfony Expression Language! This library allows you to evaluate complex expressions client-side, fully mirroring the functionality of the PHP version.

Use it to create dynamic and flexible expression-based logic on the frontend while keeping it in sync with your Symfony/PHP backend.

Features

Full Symfony Compatibility — Works just like Symfony’s Expression Language.
Rich Syntax — Supports numbers, strings, operators, functions, and object/array access.
Custom Functions — Extend functionality by registering your own functions.
TypeScript Support — Fully typed, making it seamless to use in TS projects.
Client-Side Execution — Evaluate expressions directly in the browser.

Installation

npm install @andreasnicolaou/typescript-expression-language

For full usage details and API documentation, visit the official npm page:

@andreasnicolaou/typescript-expression-language - npm

TypeScript implementation of symfony/expression-language. Latest version: 1.3.0, last published: 11 days ago. Start using @andreasnicolaou/typescript-expression-language in your project by running `npm i @andreasnicolaou/typescript-expression-language`. There are no other projects in the npm registry using @andreasnicolaou/typescript-expression-language.

npmjs.com

Demo

Why Use This Library?

Eliminate Duplicate Logic — Write expressions once and use them both client-side and server-side.
Consistent Behavior — Ensure frontend and backend calculations match perfectly.
Lightweight & Fast — Optimized for speed, with minimal dependencies.
Safe (no eval, uses AST)
You can add custom functions & operators
Great for UI features, use in feature flags, search filters, validation rules, dashboards, etc
Dynamic rules without code changes, let users/admins define filters, formulas, or conditions in text.

Get Started Today!
This library is open-source and actively maintained! If you find it useful, consider giving it a ⭐️ on GitHub: expression-language

Install via npm at: expression-language