Forem: Daniel Ostrovsky

Structuring AI Response for Better API Alignment

Daniel Ostrovsky — Thu, 13 Feb 2025 07:55:10 +0000

Ever tried to make AI-generated responses fit into a strict JSON format or an API contract and found it frustrating? You’re not alone. In this article, we’ll keep it simple and show you practical ways to align flexible AI outputs with structured API requirements. By the end, you’ll have a solid example and some tips to make this integration process much easier.

The Challenge

AI responses, especially those generated by large language models (LLMs), are often unstructured or semi-structured. While they are excellent at processing complex tasks and generating natural language, their outputs don’t always align neatly with the structured formats required by APIs. This discrepancy can lead to issues such as:

Parsing complexity: Converting free-form text into a structured format can be error-prone.
Inconsistency: Variability in AI-generated responses can disrupt API workflows.
Performance overhead: Additional processing to align AI responses with APIs can impact latency.

Practical Example: AI Agent for Flight Booking

Clarify Missing Details: The AI should ask the user for additional information, such as the departure location and travel dates. Example exchange:

User: "Find me a flight to London."
AI: "From which city are you departing, and what are your travel dates?"

Generate a Structured Payload: Once the user provides the necessary details (e.g., “From New York on February 1st, returning February 28th”), the AI should create a payload that aligns with the flight booking API’s schema. The payload might look like this:

   {
     "from": "New York",
     "to": "London",
     "dateOut": "01/02/2025",
     "dateBack": "28/02/2025"
   }

Options for Structuring AI Responses

Prompt Engineering

Provide detailed instructions in the system message, explicitly outlining the desired JSON structure for the response. Include examples of the required format.

{
  "from": "<CityName if provided>",
  "to": "<CityName if provided>",
  "dateOut": "<Date in Format DD/MM/YY if provided>",
  "dateBack": "<Date in Format DD/MM/YY if provided>"
}

If some data is missing, return:

{
  "enhanceRequest": "<Add here request for missing data>"
}

JSON Schema Response Format

Utilize OpenAI’s JSON Schema response format to define a schema that the model follows, ensuring responses are in the desired JSON format.

Implementation Example:

const desiredSchema = {
  name: 'flight_search',
  strict: false,
  schema: {
    description: 'Search for flights with departure and return dates.',
    parameters: {
      type: 'object',
      properties: {
        from: { type: 'string', description: 'The departure city name.' },
        to: { type: 'string', description: 'The destination city name.' },
        dateOut: { type: 'string', format: 'date', description: 'The outbound flight date' },
        dateBack: { type: 'string', format: 'date', description: 'The return flight date' }
      },
      required: ['from', 'to', 'dateOut', 'dateBack']
    }
  }
};

const completion = await openai.beta.chat.completions.parse({
  response_format: {
    json_schema: desiredSchema,
    type: 'json_schema'
  },
  model: 'gpt-4o-2024-08-06',
  messages: [{ role: 'user', content: 'Find me a flight to London.' }]
});

Adding a System Message for Better Accuracy:

const completion = await openai.beta.chat.completions.parse({
  response_format: {
    json_schema: desiredSchema,
    type: 'json_schema'
  },
  model: 'gpt-4o-2024-08-06',
  messages: [
    {
      role: 'system',
      content: `You are an API assistant. Respond in JSON format. If some data is missing, return:
      {
        "enhanceRequest": "<Add here request for missing data>"
      }`
    },
    { role: 'user', content: 'Find me a flight to London.' }
  ]
});

Pros & Cons

Pros:

Ensures strict adherence to the desired JSON structure.
Reduces the need for extensive prompt engineering or post-processing.

Cons:

May require initial setup to define appropriate schemas.
Limited to models and platforms that support JSON mode.

Conclusion

Aligning AI responses with API requirements is crucial for building reliable and efficient integrations. By defining clear schemas, fine-tuning models, and implementing robust validation, developers can bridge the gap between unstructured AI outputs and structured API inputs. As AI continues to evolve, these strategies will be essential for creating systems that are both intelligent and practical.

About me site: https://danduh.me/
Follow me on

Feel free to ask a question.
Thanks a lot for reading!

How to Use ESLint Like a Sane Developer (JavaScript & TypeScript Edition)

Daniel Ostrovsky — Thu, 13 Feb 2025 07:39:39 +0000

Ah, ESLint. The unsung hero standing between your codebase and complete anarchy. And yet, some developers still treat it like an oppressive overlord rather than the lifeline it actually is.

If you’ve ever had to wade through a swamp of inconsistent formatting, wildcard imports, and the occasional var (because some people just want to watch the world burn), this guide is for you. Let’s settle this once and for all: ESLint is not optional.

Why Bother With ESLint? (Aka: Why Do You Hate Yourself?)

Look, I get it. Some of you see code as art, a beautiful, free-flowing expression of logic and creativity. That’s adorable. But guess what? You’re not the only one maintaining it.

Here’s what happens when you don’t use ESLint:

Your pull requests turn into petty wars over semicolons and indentation.
Your codebase resembles a Jackson Pollock painting—if he painted with spaghetti.
Tabs and spaces become indistinguishable, and chaos reigns.
Debugging turns into archaeology, except instead of uncovering history, you uncover suffering.

And no, TypeScript’s type system isn’t a replacement for ESLint. It won’t stop you from writing unreadable garbage—it will just type-check your unreadable garbage.

Installing ESLint: Because Apparently, This Isn’t Obvious

Step 1: Install It

Yes, really.

For JavaScript:

npm install eslint --save-dev  
npx eslint --init

For TypeScript (because everything TypeScript-related requires extra steps):

npm install eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin --save-dev

Step 2: Configure It

When running npx eslint --init, you’ll answer some questions. Choose wisely—or just use a preset because nobody has time for existential crises over linting rules.

For TypeScript, your .eslintrc.json should look something like this:

{
 "parser": "@typescript-eslint/parser",  
 "extends": ["plugin:@typescript-eslint/recommended"]  
}

Congrats! You now have ESLint. But don’t get comfortable—there’s still plenty of nonsense to fix.

Popular ESLint Rule Sets: Because Smarter People Did the Work for You

Airbnb — The rule set for those who enjoy being micromanaged.
Google — Because if it’s good enough for Silicon Valley overlords, it’s good enough for you.
StandardJS — For people who like strict rules but hate semicolons.
Meta (Facebook) — For React developers who don’t like admitting they actually enjoy React.
TypeScript-Specific — If you’re using TypeScript, just extend plugin:@typescript-eslint/recommended and move on.

Example ESLint config using Airbnb’s style guide:

{
 "extends": ["airbnb", "plugin:@typescript-eslint/recommended"]  
}

Tweaking ESLint Rules: Because Your Team Has ‘Special’ Needs

ESLint comes packed with a massive set of rules—over 500 of them—designed to enforce coding standards, eliminate potential bugs, and make sure your code doesn’t look like a deranged monkey wrote it.

Managing ESLint Rules

Example of tweaking rules in your ESLint config:

{
 "rules": {
   "no-console": "warn",
   "eqeqeq": ["error", "always"],
   "complexity": ["warn", { "max": 10 }],
   "camelcase": ["error", { "properties": "always" }]
 }
}

TypeScript-Specific Rules

Example TypeScript rule configurations:

{
 "rules": {
   "@typescript-eslint/no-explicit-any": "error",
   "@typescript-eslint/naming-convention": [
     "error",
     { "selector": "variable", "format": ["camelCase"] }
   ]
 }
}

Disabling Rules Inline

console.log("Debugging"); // eslint-disable-line no-console

Or, disable a rule for a specific block:

/* eslint-disable no-console */  
console.log("Debugging");  
console.log("More debugging");  
/* eslint-enable no-console */

Overriding Rules Per File

{
 "overrides": [  
   {
     "files": ["**/*.test.js"],  
     "rules": {  
       "no-unused-expressions": "off"  
     }  
   }  
 ]  
}

Plugins and Extending ESLint Further

To use a plugin, install it via npm and extend it in your .eslintrc:

npm install eslint-plugin-react --save-dev

{
 "extends": ["plugin:react/recommended"]  
}

Automating ESLint Fixes

npx eslint . --fix

Creating a Custom ESLint Rule

module.exports = {
 meta: {
   type: "problem",
   docs: {
     description: "Ensure all 'await' expressions are wrapped in try/catch",
     category: "Best Practices",
     recommended: false,
   },
   messages: {
     unguardedAwait: "Unprotected 'await' detected. Wrap it in a try/catch to handle errors properly.",
   },
 },
 create(context) {
   return {
     AwaitExpression(node) {
       let parent = node.parent;
       while (parent) {
         if (parent.type === "TryStatement") {
           return;
         }
         parent = parent.parent;
       }
       context.report({ node, messageId: "unguardedAwait" });
     },
   };
 },
};

To enable it in .eslintrc.js:

module.exports = {
 rules: {
   "no-unguarded-await": "error",
 },
};

The Final Word: Lint or Suffer

Either use ESLint, or prepare to spend your life debugging a codebase that looks like it was written by a caffeine-fueled raccoon. Your choice.

About me site: https://danduh.me/
Follow me on

Metaprogramming in JavaScript/TypeScript Part #3 (Dependency Injection)

Daniel Ostrovsky — Tue, 20 Sep 2022 04:14:40 +0000

This is the third article in the "Metaprogramming in JavaScript and TypeScript" series.

First two:

In this article, we will consider such a concept as dependency injection.

And in this example, we will try to understand the principle of Metaprogramming and get acquainted with the reflect-metadata library.

Let's start right away with an example:

Suppose we have three classes:

1) MoviesService — should return information about movies to us, preferably with comments.

2) CommentsService — works with comments.

3) CrudService — a standard service for working with API services

The initialization of the MoviesService class would look like this:

And it seems everything looks logical, but it's not good enough :).

Indeed, in the constructors of each one of the classes, I have already indicated which dependencies are necessary to initialize this class … so why do we need this again during initialization?

And what if, for unit testing, we need to substitute a certain CrudServiceStub instead of CrudService? There is also the issue of CrudService being SingleTone and not being initialized twice (MoviesService and CommentsService). All this, of course, can be solved in the old ways, but we are not here for this :)

Let's start with decorators.

Simple and even empty decorator

Since the decorator is a regular function, after compilation into JS, we will get:

But if we use this as decorator…

Now JS will look completely different:

We are interested in the __decorate functionOr rather the line:

Reflect.decorate(decorators, target, key, desc);

In order to understand what it does, let's add a console.log. To our decorator.

And the decorator itself will also be added to the CommentsService class

And so, we see that Reflect.getMetadata(‘design:paramtypes’, target)returns a list of dependencies of the class being decorated. Where this information comes from, it is better to read in the original source.

To simplify, TypeScript will automatically add the metadata to Reflect (store/object).

Let's try to decorate the class method

In other words, Reflect is an object that stores some data. What data? The metadata. TypeScript in this object adds information about the types in the signatures of the class and methods and the types that these methods return.

Knowing all this and having access to the Reflect object, we can write the following function:

All dependencies will be automatically resolved.

However, this is still not ideal — for example, CrudService it will be created twice. But at the beginning of the article, we talked about singleton.

To begin with, for a more straightforward implementation, instead of the resolve function, we will create an Injector and add the necessary functionality to it.

This may not be the most elegant solution, but it will work as an example :)))

Summing up:

I hope I managed to talk about the following points in this article:

Reflect on a class is a kind of object into which TypeScript adds information about the types in the constructor, the types of method signatures, and the types that these methods return when compiling.

With the help of the reflect-metadata library, we can get this information and use it for our purposes.

In the following article, we will analyze how to add the information we need to the Reflect object and how we can use it.

If you like this article, comment and react ♾️ times.

Follow me on Twitter, Medium Dev/To for blog updates.

Check out my website and Youtube for videos and public talks.

Feel free to ask a question.

Thanks a lot for reading!

Metaprogramming in JavaScript/TypeScript Part #1

Daniel Ostrovsky — Mon, 15 Aug 2022 13:01:00 +0000

Descriptor.

I would like to present to you a series of mini-articles, which describe the metaprogramming basics and techniques.
Generally, I will write about the use of certain techniques in JavaScript or TypeScript

This is the first article in the series

So, what is metaprogramming?

Metaprogramming is a programming technique in which computer programs have the ability to treat other programs as
their data. It means that a program can be designed to read, generate, analyze or transform other programs, and even
modify itself while running. In some cases, this allows programmers to minimize the number of lines of code to express a
solution, in turn reducing development time.

The definition is pretty complex, but the main benefit of metaprogramming is quite clear:

“… this allows programmers to minimize the number of lines of code to express a solution, in turn reducing development time”.

Actually, metaprogramming has so many forms of practical application, that the discussion on “where metaprogramming ends
and the programming begins” might never get an accurate answer.

I have formulated the following rules for myself:

1) Metaprogramming should not define, change or affect the business logic by any means.
2) If the metaprogramming-related code is removed, the program should not be seriously affected.

Descriptor

In JavaScript, metaprogramming is a fairly new trend, having the descriptor as one of its fundamentals.

Descriptor is a kind of description (meta information) of a given property/method in an object.

Understanding and correctly application of descriptors will allow you a lot more than just create and modify methods or
properties in your objects.

Descriptors are also helpful in understanding how to operate with decorators, which is the topic of my next article.

Let’s take an apartment and describe it as an object, with it’s own properties:

let apt = {
  floor: 12,
  number: '12B',
  size: 3400,
  bedRooms: 3.4,
  bathRooms: 2,
  Price: 400000,
  amenities: {...}
};

Let’s determine which properties can and cannot be changed.

For example, it is impossible to change the floor or the total size of the apartment, while the number of rooms or
bathrooms can be changed.
As a result, we have the following requirements: to make it impossible to change the floor and size properties in apt
objects.

To solve this task, we will need descriptors for each of these properties. To get the descriptor, use the static method
getOwnPropertyDescriptor, which belongs to the Object class*.*

let descriptor = Object.getOwnPropertyDescriptor(apt, 'floor');
console.log(descriptor);
// Output
//{
//  value: 12,
//  writable:true,
//  enumerable:true,
//  configurable:true
//}

Let’s take a closer look at the next:

value — this is the value assigned to the floor property at a certain moment

writable — defines whether it is possible to change the value

enumerable — defines if the floor property can or can’t be enumerated — (more on this later).

configurable — defines the ability to make changes on the descriptor object.

To prevent the floor property from changing after initialisation, it is necessary to set the writable value to false.
The static defineProperty method is used to change descriptor properties. Its input parameters are the object itself (
apt), property name (‘floor’) and the descriptor.

Object.defineProperty(apt, ‘floor’, {writable: false});

In this case, we pass not the entire descriptor object, but only the writable property having the false value.

Now let’s try to change the floor property value:

apt.floor = 44;
console.log(apt.floor);
// output    12

The value has not changed, and when using the ‘use strict’, an error message will be shown:

” Cannot assign to read only property ‘*floor’ of object ‘…*

Now it is impossible to change the value. However, we can still revert the writable to true and modify the floor
property value. To avoid this, we have to set the configurable property value to false

Object.defineProperty(apt, 'floor', {
  writable: false, configurable: false
})

Let’s make one more attempt to change the value of any of the property of our descriptor…

Object.defineProperty(apt, 'floor', {
  writable: true, configurable: true
});

We get the next:

“TypeError: Cannot redefine property: floor…”

Let’s sum it up:

To make the value of the property unchangeable, it is necessary to specify the configuration of this property:
{writable: false, configurable: false}.

//This can be done when initialising the property:
Object.defineProperty(apt, 'floor',
  {value: 12, writable: false, configurable: false});

//Or after the initialisation:
Object.defineProperty(apt, 'floor',
  {writable: false, configurable: false});

In the end, let’s consider an example with a class:

class Apartment {
  constructor(apt){
    this.apt = apt;
  }

  getFloor(){
    return this.apt.floor
  }
}

let apt = {
  floor: 12,
  number: '12B',
  size: 3400,
  beds: 3.4,
  baths: 2.
};

Let’s change the getFloor method:

Apartment.prototype.getFloor = () => {
  return 44.
};
let myApt = new Apartment(apt);
console.log(myApt);
// output will be changed.
// 44

Now let’s change descriptor of the getFloor method

Object.defineProperty(Apartment.prototype, 'getFloor',
  {writable: false, configurable: false});

Apartment.prototype.getFloor = () => {
  return 44.
};
let myApt = new Apartment(apt);
console.log(myApt);

// output will be original.
12

Back to enumerable.



let otherApt = {
  floor: 12,
  number: '12B',
  size: 3400,
  bedRooms: 3.4,
  bathRooms: 2,
  price: 400000,
  amenities: {}
};

let keys = Object.keys(otherApt);
console.log(keys);
// Output
[ 'floor', 'number', 'size', 'bedRooms',
  'bathRooms', 'price', 'amenities'
]

In other words, we can iterate the properties of the object using for … in.
What if one of the properties, e.g. amenities, should not be available for iteration?
This can be done by setting {enumerable: false} in our descriptor

Object.defineProperty(otherApt, 'amenities', {enumerable: false});
const keys = Object.keys(otherApt);
console.log(keys);
// Output
// [ 'floor', 'number', 'size', 'bedRooms', 'bathRooms', 'price' ]

The amenities property remains a part of the apt.prototype.

console.log(otherApt.hasOwnProperty('amenities'));
// Output
// true

Takeaway

I hope this article will shed a little more light on what descriptor is and how you can use it.

If you like this article press like button ♾️ times.
Feel free to ask a questions.
Follow me on Twitter and Medium and my website for blog updates.
Thanks a lot for reading!

The flexible way to adopt UX/UI in Angular app according to user’s permissions.

Daniel Ostrovsky — Sun, 14 Aug 2022 17:53:00 +0000

In many projects, there are authentication processes (more or less). A lot of “best practices” were written in all known technologies and so on, and so forth.

But what happens after the user made the login? After all, he by far cannot do everything. How to define what he can see and what not. What buttons he has the rights to click on, what to change, create and delete.

In this article, I want to consider the approach used for solving these problems in a web application.

To begin with, the present/effective authorization can take place only on the server. On front-end, we are able just to improve UI and UX. We can hide the buttons on which the user has no rights to click, or prevent him from reaching the pages, or to show the message that he does not have the rights to do a certain action.

And here arises the question, how to make it as correctly as possible? Let’s start by defining the problem.

We created a Todo App and it has different types of users:

USER — can see and update all the tasks (check/uncheck), but cannot delete, create and see statistics page.
ADMIN — can see all the tasks and create new ones, but cannot see statistics.
SUPER_ADMIN — can see all the tasks, create new ones and delete them, and also can see statistics.

In this a situation, we can use the “roles”. However, the situation can change a lot. Imagine ADMIN user with permissions to delete tasks. Or USER with access to see statistics. A simple solution is to create new roles.

But on large applications, with massive user role system, we will quickly get lost in a huge amount of roles…

And here we recall the “user rights” permissions. For easier management, we can create groups of several permissions and attach them to the user. It is always possible to add specific permission to a specific user.

This kind of solutions can be found in many large services: AWS, Google Cloud, SalesForce and so on. Also, similar solutions have already been implemented in many frameworks, for example, Django (Python).

I want to give an example of implementation for Angular applications. (On the example of the same ToDo App).

First, let’s define all possible permissions.

Divide into features. We have tasks and statistics.
We define possible actions with each of them. Task: create, read, update, delete. Statistics: read (in our example only viewing).
Create a MAP of roles and permissions.

export const permissionsMap = {
    todos:{
        create:'*',
        read:'*',
        update:'*',
        delete:'*'
    },
    stats:'*'
}

In my opinion, this is the best option, but in most cases, the server will return something like this:

export permissions = [
  'todos_create', 
  'todos_read', 
  'todos_update', 
  'todos_delete', 
  'stats',
]

Less readable, but also not bad at all.

This is how our application looks when the user is already authenticated but UI/UX is not yet adopted according to user’s permissions:

Let’s look at the USER’s permissions:

export const USERpermissionsMap = {
    todos:{
        read:'*',
        update:'*',
    }
}

Navigation:

USER cannot see the statistics, it means he basically cannot navigate to this page.

For such situations in Angular, there are Guards, which are used at the Routes level (documentation).

@Injectable({
    providedIn: 'root'
})
export class PermissionsGuardService implements CanActivate {
    constructor() {
    }

    canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> | boolean {
        const userPerms = getPermissions();
        const required = route.data.permission;

        const isPermitted = checkPermissions(required, userPerms);

        if (!isPermitted) {
            alert('ROUTE GUARD SAYS: \n You don\'t have permissions to see this page');
        }

        return isPermitted;
    }
}

Pay attention to the object in data.permissions = 'stats', these are exactly the permission that the user needs to have, in order to have access to this page.

Based on the required data.permissions and USER’s permissions PermissionsGuardService will decide whether or not to allow access on page ‘/stats’.

getPermissions(); a helper function that returns an object with user's permissions.
checkPermissions(); checks if required permission is part of user’s permissions.

export function getPermissions() {
    let userPerms;
    // In our example we using stor as a single source of truth. 
    // Full implementation can be found here https://github.com/danduh/ngx-to-do-permissions.

    const store: Store<any> = AppInjector.get(Store);
    store
        .pipe(
            select(userPermissionsState),
            take(1)
        )
        .subscribe((_p) => {
            userPerms = _p ? _p : {};
        });
    return userPerms;
}

export function checkPermissions(required: string, userPerms) {
    // 1) Separate feature and action
    const [feature, action] = required.split('_');

    // 2) Check if user have any type of access to the feature
    if (!userPerms.hasOwnProperty(feature)) {
        return false;
    }

    // 3) Check if user have permission for required action
    if (!userPerms[feature].hasOwnProperty(action)) {
        return false;
    }

    return true;
}

Hiding Elements

Now, our USER cannot navigate to the statistics page. However, he still can create tasks and delete them.

To make USER unable to delete tasks, it will be enough to remove the red (X) from the task line.

For this purpose, we will create a custom Structural Directive.

@Directive({
    selector: '[appPermissions]'
})
export class PermissionsDirective {
    private _required: string;
    private _viewRef: EmbeddedViewRef<any> | null = null;
    private _templateRef: TemplateRef<any> | null = null;

    @Input()
    set appPermissions(permission: string) {
        this._required = permission;
        this._viewRef = null;
        this.init();
    }

    constructor(private templateRef: TemplateRef<any>,
                private viewContainerRef: ViewContainerRef) {
        this._templateRef = templateRef;
    }

    init() {
        const userPerms = getPermmisions();
        const isPermitted = checkPermissions(this._required, userPerms);

        if (isPermitted) {
            this._viewRef = this.viewContainerRef.createEmbeddedView(this.templateRef);
        } else {
            console.log('PERMISSIONS DIRECTIVE says \n You don\'t have permissions to see it');
        }
    }
}

<!-- 
  Similar to other Structural Directives in angular 
  (*ngIF, *ngFor..) we have '*' in directive name
  'todos_delete' -> is an Input() for directive 
  as a required permission to see this btn.
-->
<button
    *appPermissions="'todos_delete'"
    class="delete-button"
    (click)="removeSingleTodo()"> X
</button>

Now USER does not see the DELETE button but can still add new tasks.

Adopt element state:

If we remove the input field, the whole look of our application will ruin. The correct solution in this situation would be to disable the input field.

Let’s try pipe for this.

<!-- 
  as a value `permissions` pipe will get required permission
  `permissions` pipe return true or false, that's why we have !('todos_create' | permissions)
  to set disable=true if pipe returns false
 -->
<input class="centered-block"
       [disabled]="!('todos_create' | permissions)"
       placeholder="What needs to be done?" autofocus/>

@Pipe({
    name: 'permissions'
})
export class PermissionsPipe implements PipeTransform {
    constructor() {
    }

    transform(required: any, args?: any): any {
        const userPerms = getPermissions();
        const isPermitted = checkPermissions(required, userPerms);

        if (isPermitted) {
            return true;
        } else {
            console.log('[PERMISSIONS PIPE] You don\'t have permissions');
            return false;
        }
    }
}

And now the USER can only see the tasks and change them (check/uncheck). However, we still have Clear completed button fully functional and available for USER.

Decorators:

Suppose that we have the following requirements from our Product Manager:

The ‘Clear Completed’ button should be visible to everyone and always.
It should also be clickable.
In case USER without corresponding permissions presses the button, an error message should appear.

Constructional directive will not help us, nor does pipes.

It is also not very convenient to register the check for permissions into component functions. All we need is to check permissions between the click and the execution of the bound function.

In my opinion here it is worth to use the decorators.

@Component({
    selector: 'app-actions',
    templateUrl: './actions.component.html',
    styleUrls: ['./actions.component.css']
})
export class ActionsComponent implements OnInit {
    @Output() deleteCompleted = new EventEmitter();
    constructor() {
    }

    // Our custom decorator, as a param we pass required permission
    @Permissions('todos_delete')
    public deleteCompleted() {
        this.deleteCompleted.emit();
    }
}

export function Permissions(required) {
    return (classProto, propertyKey, descriptor) => {

        const originalFunction = descriptor.value;
        descriptor.value = function (...args: any[]) {
            const userPerms = getPermissions();
            const isPermitted = checkPermissions(required, userPerms);
            if (isPermitted) {
                originalFunction.apply(this, args);
            } else {
                // Should throw/log error, but for better visibility will use alert()
                alert('PERMISSIONS DECORATOR says \n you have no permissions');
            }
        };

        return descriptor;
    };
}

And our final result:

Conclusion

Maybe it’s not the best solutions. But this approach allows us to easily and dynamically adapt our UX in accordance with the permissions that the user has.

Repo Link

Thanks to Peter Pshenichny