Angular 5 does not allow function calls within decorators

Question

Angular 5 does not allow function calls within decorators

I encountered an issue while building a Progressive Web App (PWA) from my Angular application. When running ng build --prod, I received the following error:

ERROR in app\app.module.ts(108,64): Error during template compile of 'AppModule'
Function calls are not supported in decorators but 'Environment' was called in 'environment'
'environment' calls 'Environment'.

The error seemed confusing as I had already added export to the class, which is evident from the code snippet below:

environment.prod.ts

import { BaseEnvironment } from './base-environment';
import { ProspectBuilderModel } from '../app/models/prospect';

export class Environment extends BaseEnvironment {
  production: boolean = true;
  prospectBuilderModel: ProspectBuilderModel = {
    buildQuote: false,
    // other properties...
  };
}

export const environment = new Environment();

base-environment.ts

import { ProspectBuilderModel } from '../app/models/prospect';

export abstract class BaseEnvironment {
  abstract production: boolean;
  abstract prospectBuilderModel: ProspectBuilderModel;
}

app.module.ts

...
 ],
  imports: [
    BrowserModule,
    AppRoutingModule,
    FormsModule,
    MultiselectDropdownModule,
    ReactiveFormsModule,
    HttpModule,
    ToastrModule.forRoot(),
    BrowserAnimationsModule,
    NgxMyDatePickerModule.forRoot(),
    PopoverModule.forRoot(),
    ModalModule.forRoot(),
    ServiceWorkerModule.register('/ngsw-worker.js', { enabled: environment.production })
  ],
  providers: [
...

If anyone has ideas on how to resolve this error, please let me know.

angular typescript progressive-web-apps

Answer 1

Answer №1

Encountered the same issue, here are some potential solutions (if dynamically loaded properties are not a concern):

1. Utilize an object as your response.

This approach may result in losing default properties and details regarding "to implement" properties.

2. Implement static classes:

In this scenario, you may lose 'to implement' properties since abstract statics are not feasible. However, you will still retain the types and defaults.

// default.env.ts
export class BaseEnvironment {
  public production: boolean = true;
  public specialPropToImpl: boolean = true;
}

// your.env.ts
export class Environment extends BaseEnvironment {
  public specialPropToImpl = true;
}

export const environment = Environment;

3. Implement default properties object, interface, and object assignment:

This method allows for retaining the 'to implement' properties, types, and defaults, albeit it may be slightly cumbersome to implement.

// default.env.ts
export interface EnvProperties {
  production: boolean;
  specialPropToImpl: boolean;
}

export const defaultEnv = {
  production: true
};

// your.env.ts
export const environment: EnvProperties = {
...defaultEnv,
specialPropToImpl: true
};

4. Introduce just one additional static variable from environment

A straightforward solution which involves maintaining your subclasses, however, every env file must have it. This method could work well considering new environment files are typically created by replicating existing ones.
Depending on the production value, you would need to manually adjust the variable value.
While not incredibly flexible or easy to maintain, this solution is simple.

// your.env.ts
export const enablePwa = true

// app.module.ts
import {environment, enablePwa} from 'env.ts'
//...
ServiceWorkerModule.register('/ngsw-worker.js', { enabled: enablePwa })

Answer 2

Encountered the same issue, here are some potential solutions (if dynamically loaded properties are not a concern):

1. Utilize an object as your response.

This approach may result in losing default properties and details regarding "to implement" properties.

2. Implement static classes:

In this scenario, you may lose 'to implement' properties since abstract statics are not feasible. However, you will still retain the types and defaults.

// default.env.ts
export class BaseEnvironment {
  public production: boolean = true;
  public specialPropToImpl: boolean = true;
}

// your.env.ts
export class Environment extends BaseEnvironment {
  public specialPropToImpl = true;
}

export const environment = Environment;

3. Implement default properties object, interface, and object assignment:

This method allows for retaining the 'to implement' properties, types, and defaults, albeit it may be slightly cumbersome to implement.

// default.env.ts
export interface EnvProperties {
  production: boolean;
  specialPropToImpl: boolean;
}

export const defaultEnv = {
  production: true
};

// your.env.ts
export const environment: EnvProperties = {
...defaultEnv,
specialPropToImpl: true
};

4. Introduce just one additional static variable from environment

A straightforward solution which involves maintaining your subclasses, however, every env file must have it. This method could work well considering new environment files are typically created by replicating existing ones.
Depending on the production value, you would need to manually adjust the variable value.
While not incredibly flexible or easy to maintain, this solution is simple.

// your.env.ts
export const enablePwa = true

// app.module.ts
import {environment, enablePwa} from 'env.ts'
//...
ServiceWorkerModule.register('/ngsw-worker.js', { enabled: enablePwa })

Answer 3

Answer №2

It seems like your code was functioning properly until you inserted the line ServiceWorkerModule.register('/ngsw-worker.js', { enabled: environment.production })

Typically, when we reference the environment variable in the app module, it usually points to the environment files automatically created by Angular CLI (which serve as constants and are exported accordingly). I have never attempted to instantiate a class object and pass it in the app module before. This could be the root of the issue.

Consider simply passing true directly into this line instead of fetching it from an object to test if that resolves the problem.

Answer 4

It seems like your code was functioning properly until you inserted the line ServiceWorkerModule.register('/ngsw-worker.js', { enabled: environment.production })

Typically, when we reference the environment variable in the app module, it usually points to the environment files automatically created by Angular CLI (which serve as constants and are exported accordingly). I have never attempted to instantiate a class object and pass it in the app module before. This could be the root of the issue.

Consider simply passing true directly into this line instead of fetching it from an object to test if that resolves the problem.

Answer 5

Answer №3

Check out the code snippet below for the solution I eventually figured out. Hopefully, this will be useful for anyone facing a similar issue in the future. Basically, all I did was tweak my environment file to avoid creating an instance of the Environment class. It seems like Angular doesn't quite approve of instantiating it:

export const environment = {
  production: true,
  prospectBuilderModel: {
    buildQuote: false,
    buildAcknowledge: false,
    buildOrganizationInfo: false,
    buildFinancialInfo: false,
    buildTradeInfo: false,
    buildPermissiblePurpose: false,
    buildUserSetup: false,
    buildPackageSelection: false,
    buildPaymentOptions: false,
    buildOrderOptions: false,
    buildVerifyOrganizationInfo: false,
    buildDocusignAuthorization: false,
    buildDocusignContract: false
  }
}

Answer 6

Check out the code snippet below for the solution I eventually figured out. Hopefully, this will be useful for anyone facing a similar issue in the future. Basically, all I did was tweak my environment file to avoid creating an instance of the Environment class. It seems like Angular doesn't quite approve of instantiating it:

export const environment = {
  production: true,
  prospectBuilderModel: {
    buildQuote: false,
    buildAcknowledge: false,
    buildOrganizationInfo: false,
    buildFinancialInfo: false,
    buildTradeInfo: false,
    buildPermissiblePurpose: false,
    buildUserSetup: false,
    buildPackageSelection: false,
    buildPaymentOptions: false,
    buildOrderOptions: false,
    buildVerifyOrganizationInfo: false,
    buildDocusignAuthorization: false,
    buildDocusignContract: false
  }
}

Angular 5 does not allow function calls within decorators

Answer №1

1. Utilize an object as your response.

2. Implement static classes:

3. Implement default properties object, interface, and object assignment:

4. Introduce just one additional static variable from environment

Answer №2

Answer №3

Similar questions

Using computed properties with Nuxt's `head` property can result in error messages being displayed

React Type Mutation response feedback is a valuable tool for receiving input

What is the reason for typescript's lack of a "function" type?

How to exit a dialog in an Angular TypeScript component with precision

Retrieve data upon component mounting and deactivate the query in React-query

Angst with the Angular Command Line Interface

Oops! The module "rxjs/Subject" seems to be missing the exported member "Subject"

Evaluate the Worth of a Property Established in a Subscription

having difficulty applying a border to the popup modal

Tips for incorporating recursive HTTP requests into an Angular2 service to efficiently retrieve data in advance

The index access type cannot be used with T[Key extends keyof T]

Determining the Type<> of a component based on a string in Angular 2

"Looking to personalize marker clusters using ngx-leaflet.markercluster? Let's explore some ways to customize

Acquiring information from a Service and saving it in a Child component - Angular version 11

How to arrange table data in Angular based on th values?

Capturing a webpage through Record RTC integration with Angular

The user type is not yet loaded from Firestore when the view is rendered

Downcasting on "this" is not supported in Typescript

Refresh Angular component upon navigation

ngFor filter based on user input