Support Angular @Component decorator alias

[flashios09]

It seems that prettier is not parsing the Component import statement and using the hard string "Component" to detect if it's an Angular component or not(node.callee.name === "Component") which means that this would work:

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

@Component({...})
export class ButtonComponent {}

But this will not:

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

@Page({...})
export class PostsPage {}

-> Prettier will not be able to detect the template since the callee name is Page.

Same thing for this:

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

@Layout({...})
export class AdminLayout {}

-> Prettier will not be able to detect the template since the callee name is Layout.

The Component decorator name in Angular is so "generic", could be used as a Component, Page(route) and a Layout, using an alias will make it easier to read and understand.

Adding a support for those aliases is so easy too, all we need is to change one line:

// src/language-js/embed/utils.js
const angularComponentObjectExpressionPredicates = [
  (node, name) => node.type === "ObjectExpression" && name === "properties",
  (node, name) =>
    node.type === "CallExpression" &&
    node.callee.type === "Identifier" &&
    // node.callee.name === "Component" &&
    ["Component", "Layout", "Page"].includes(node.callee.name) &&
    name === "arguments",
  (node, name) => node.type === "Decorator" && name === "expression",
];

Now prettier will detect the new component aliases Page and Layout :)

[rubiesonthesky]

Regarding the open PR, Wouldn’t it be better to change the code understand any alias name instead of hard coding these Page and Layout names? I haven’t seen this convention in Angular ecosystem. I don’t doubt that it exists but I feel like that it isn’t something that is regarded standard way. And prettier would need to start to add all the aliases that people request.

I could be wrong and this is something that Angular is promoting in their style guide. If that it’s the case, then this change makes a lot sense.

[flashios09]

@rubiesonthesky I have updated the code, now it will support any alias name :)

[sosukesuzuki]

I am against adding this feature.

But I am not familiar with Angular, so let me ask a question. Is this rule common among people who write Angular? Or is it only needed by you and your team?

[flashios09]

I am against adding this feature.

@sosukesuzuki This is not an Angular feature and it will not affect the way you write the code, which means you can still use the @Component with prettier.

But I am not familiar with Angular, so let me ask a question. Is this rule common among people who write Angular? Or is it only needed by you and your team?

The common rule, or let's say a good practice among people who write code(doesn't matter which language/technology) is to have a good naming:

"A good name should give you a good idea about what the variable contains or function does. A good name will tell you all there is to know or will tell you enough to know where to look next. It will not let you guess, or wonder. It will not misguide you. A good name is obvious, and expected. It is consistent. Not overly creative. It will not assume context or knowledge that the reader is not likely to have."

This is a great article to read about the importance of naming in programming https://wasp-lang.dev/blog/2023/10/12/on-importance-of-naming-in-programming

As i said before, the @Component naming is so generic, so using an alias will make the code easier to read and understand, you will not need to guess if this is a component or page or layout:

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

@Component({/*...*/})
export class MyComponent { /*...*/ }

With the current generic @Component naming, you need to read the code to understand what this component is used for :(

import { Component as Page } from '@anguler/core';

@Page({/*...*/})
export class DashboardPage { /*...*/ }

Ah ok, this is the dashboard page, no need to read the decorator template +500 lines or the class properties/methods :)

import { Component as Layout } from '@anguler/core';

@Layout({/*...*/})
export class AdminLayout { /*...*/ }

Ah ok, this is the admin layout, no need to read the decorator template or the class properties/methods :)

[fisker]

I suggest use language comment instead.

@Page({
    selector: 'posts-page',
    template: /* HTML */ `
        <h1>My App</h1>
        <app-todo-list></app-todo-list>
    `,
})

[sosukesuzuki]

Thanks for the reply.

I know that naming things appropriately is good practice. But what I am saying is that implementing a new feature is a trade-off for new complexity.

If this rule is something that is widely used in the Angular community, then I think it is worth accepting the complexity for this feature. But if this rule is just for you and your team, then I don't think it is worth to increase complexity of Prettier.