magbeat

joined 1 year ago
9
Angular 18 is out (blog.angular.dev)
submitted 4 months ago by magbeat to c/angular
5
submitted 4 months ago* (last edited 4 months ago) by magbeat to c/angular
 

Adding fallback content for ng-content got a lot easier with Angular v18

4
submitted 5 months ago by magbeat to c/angular
 

Was waiting for a long time for jest to replace karma. It seems there is a new test runner overtaking jest for Angular testing: Web Test Runner.

[–] magbeat 2 points 11 months ago* (last edited 11 months ago) (1 children)

When you are developing a UI library (as we are) we want to support the old API for some time and mark is a deprecated. So one would add a second @Input() of type ScheduleEvent[] leave the old API be as Course[] and mark it as deprecated. In the next major version you could then retire the old API.

 

Great usecase for the transforming @Input properties.

We will have to refactor a huge (and I mean huge) component for a customer in the near future. The consuming teams should not notice any of this. transform could be very useful for this.

6
submitted 11 months ago by magbeat to c/angular
 

Never heard and never used this feature of Angular v16.

 

Has anyone already switched to Jest? Has anyone already gained experience with Playwright Component Tests in Angular?

3
submitted 11 months ago* (last edited 11 months ago) by magbeat to c/angular
 

Nice article on how to use the Angular Schematics to convert a project to all standalone components and about what the schematics actually do in every step.

[–] magbeat 4 points 1 year ago
[–] magbeat 1 points 1 year ago

Yes, you are right. Long living branches are the problem.

In this case it is a completely new project in the workspace (of course depends on the library in the workspace). It is a POC that has been postponed again and again by the customer due to priorities.

I think it's probably best to isolate the branch and take it out of the workspace. When it is ready, we can integrate it back into the workspace.

[–] magbeat 6 points 1 year ago

As @[email protected] said you can use multiple configuration providers. We usually have local appsettings.json files, even per machine appsettings.<HOSTNAME>.json and then use Environment Variables that are stored in a vault for the production environment. We add the appsettings.<HOSTNAME>.json files to .gitignore so that they don't get checked in.

    var env = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
    configuration.AddJsonFile($"appsettings.{env}.json", optional: true, reloadOnChange: true);
    configuration.AddJsonFile($"appsettings.{Environment.MachineName}.json", optional: true, reloadOnChange: true);
    configuration.AddEnvironmentVariables();

Then you can provide the secrets as environment variables in the form of DATA__ConnectionString

view more: next ›