-
Notifications
You must be signed in to change notification settings - Fork 26.6k
Description
Which @angular/* package(s) are relevant/related to the feature request?
No response
Description
Is Angular Becoming React?
I've been watching Angular's "evolution" with a certain sour taste.
One of the things I like most about Angular (and have always defended) is the separation of components and services, the separation between ts, html, scss, and spec code. These separations have always been self-documenting.
From version 19 onward, there has been an evolution and an "arbitrary devolution."
If I use "ng g c feature," the files "feature.ts," "feature.html," "feature.scss," and "feature.spec" will be created. The component will be named "Feature."
If I use "ng g s feature," "feature.ts" and "feature.spec" will be created. The service will be named "Feature."
If I needed to use both features in the same component, I would have to perform an import that doesn't make sense, like:
import { Feature } from '../../components/feature';
import { Feature } from '../../services/feature';
Having to use AS for naming makes even less sense.
On the other hand, if I used previous versions, everything would be clearer, like:
import { FeatureComponent } from '../../components/feature.component';
import { FeatureService } from '../../services/feature.service';
In my opinion, we're on a path of no return when it comes to transforming Angular's good features into React, and I'd like to suggest that the architecture team consider keeping some "old" patterns for future versions.
For micro frontends, it might make sense, but for large systems, it doesn't. Saving object names could be done by the compiler, but it wouldn't hinder the smooth development process with a saving that hinders rather than helps.
Proposed solution
The proposal is to follow the KISS standard and keep it simple without saving characters because it doesn't make sense for those who are developing solutions with the most complex types of technology and solving the size "problem" in the compiler.
Alternatives considered
As a workaround, there could be CLI command line parameters that keep it simple and not simply destroy legacy.