How to casually change the entire way Angular components work 

I would still advocate for it because I would also be advocating for breaking up those components ;)

lol didn't really think about that - it wasn't a conscious decision to *not* mention ASTs but also I wanted this to focus more on "what can we learn directly from this PR" rather than specifically being a tutorial on what ts-morph is/what it does

I was thinking along the same line "Tell me parsing is powerful without saying parsing is powerful"

Seems like it

Unless there's anything else I'm missing that distinguishes Angular from Svelte besides the component authoring syntax, then I guess so

@@JoshuaMorony there’s nothing wrong with Svelte, I quite like it, but I preferred Angular over say React, because of its OOP design. Just a personal love that’s all

Yes, that would be great. Haha

​@@lukebennett3189interesting. I would do away with OOP, but I like that Angular is an opinionated framework. There's one way to do routing. There are established patterns enforced or strongly suggested by the framework. That way I can look at a new-to-me Angular project and understand what's going on.

I'm not using a distro but you can see my config here if you like: github.com/joshuamorony/nvim

@@JoshuaMorony thanks, maybe I'll clone yours 🌝 My own is very shiny but it's slow as hell

For me having the logic and HTML on the same file makes so much sense because you are manipulating one with the other. The only reason I don't like this is because community split.

These things don't specifically have to be there but I think the main motivation is that it is a format that makes delineating the specific parts easier (i.e. how should we distinguish which part is the template, which is the logic, which is the styles) and also because this particular formatting plays nicely with syntax highlighting/IDEs. It's also similar to conventions in other frameworks But, with enough work, the way the sections are distinguished could be just about anything

@joshua lang=md on the template for example

@@JoshuaMorony if the goal is to "delineating the specific parts easier", couldn't that be accomplished by just putting the separate parts in separate files? like angular already supports?

​@@deefdragon I don't know specifically how complicated this would make the implementation but hypothetically yes, just about any approach could probably be done. But at least from my view the SFC aspect is an important aspect of this proposal so there would still need to be some way to handle this for SFC as well

I do have a couple of videos planned involving signal inputs but not sure when I will release them (and signal inputs are available now in the 17.1 RC btw)

Hypothetically if you had to use just this new approach, what would you miss about the OOP approach?

@@JoshuaMoronyseparation of concerns. I like that I think of the code as the view model and the template as the view. Putting it all in one file is convenient but will lead to spaghetti.

@@toxaq this doesn't really have anything to do with OOP though, and even in the case of SFC it also doesn't really change anything in terms of actual code architecture, there is still three distinct places for the template/styles/logic, those three places just happen to be in the same file. In my opinion, this is a better representation of separation of concerns, because all of the things related to a specific concern (e.g. "rendering a button" or "displaying a list of data") are closer together - I don't see a "concern" as "this is the template part of this component" and "this is the logic part of this component"

@@JoshuaMorony I wasn't commenting so much on OOP as "what I'd miss". Although in relation to OOP, its a stretch to say that page level vars are the same encapsulation as getters and setters on a class. I stick with my SoC argument. You could argue that they're all the same thing when combined on the page, my mental model is clearly different. I'm thinking in the page class about what I want to push through to the view. I tried Svelte and hated it. It became spaghetti for me with what ran in the server and what ran on the client. Maybe I just didn't wait long enough for that mental model to kick in. The seperate files was one of the reasons I jumped in to AngularJs in 2012. It felt natural and I'm super glad that Angular14+ is finally delivering on the promise. I don't have anything against the format/idea, I just wouldn't pick it and hope Angular doesnt confuse the waters by offering it.

​@@toxaq so would it be fair to say (in summary) that the key things you prefer about the existing approach is the ability to define multi-file components and also having more strict control over what is exposed to the template? Although it's possible it seems unlikely that this new format will allow multi-file, but exposing variable statements as something other than protected only might be more likely. Hypothetically if both of those things were implemented, would you prefer the proposed format (e.g. ability to get rid of mandatory decorator metadata + class)?

Nothing just coming react fanboys tryint to destroy another good framework with their 20years old cykled mechanics

Nothing specifically wrong with it imo, the SFC argument is a separate thing for me anyway I already use SFC with the current Angular format regardless and don't view the separation of technologies into different files as relating to separation of concerns. In my view, the code that relates to a specific concern should be co-located, having them in separate files just decreases their proximity (i.e. I see a "concern" as "rendering a list of data" not "this is the html for the list component"). If we could leave the SFC argument aside though, the new format just looks like an obvious improvement to me. The only real loss there is if you want to use inheritance with components which is generally not recommended anyway - otherwise there is nothing lost, but a lot less boilerplate and less concepts (like decorators) necessary

Well components in Angular are very flexible, this flexibility comes from being able to configure it via the decorator. Think about standalone components, how are you supposed to manage imports, providers and stuff like that? Decorators are a very popular pattern in higher level languages. Yes your approach may seem „simpler“ at the first glance, but keep in mind that Angular is an Enterprise Framework with support for all kinds of complexity and project size. If your goal is a „simple“ component, maybe it’s just not the right tool for the job (although recent changes by the Angular team making it more and more universally usable)? Thinking about Vue or Svelte.

​@@redfox2k8 the new format loses none of these things though, defining metadata is optional with this approach and it removes some of the need to add imports at all because a component can just be imported once and used directly in the template rather than also needing to add it to the imports of the decorator, its standalone by default, and it isn't necessary to define a selector for components (but you can if you want). However, with the new format you can also use "defineMetadata" to add the same things you would to a component with a decorator. This new format isn't just losing a bunch of features, it is just doing them in a different way - the only features that would really be lost is OOP stuff like inheritance since classes aren't being used, but inheritance isn't really generally recommended anyway.

And what is the difference between the template in angular and vue? What’s cause pain in vue template for you?

​@@jpffinc Before Previously in Vue, the Options API was the default, and I used to prefer setting up with Class Components due to my Angular background. Typescript felt like a hack with that setup. Then Vue 3 introduced the Composition API, which is similar to Angular's Class Components syntax in terms of functionality. However, a key difference is file separation. In Angular, you can have separate HTML, TypeScript, and SCSS files for each component, while Vue typically combines these into a single .vue file (Single-File Component). This file separation is a point of debate. Some developers prefer the one-file approach of Vue, while others (like myself) appreciate the organization and clarity of separate files. Ultimately, the choice depends on personal preference and project needs. In my opinion a lot of people who like Angular are not fans of javascript.

I agree, I use Angular exclusively and I'm not interested in this at all

​@@jpffinc Single-file components are a key difference in Vue. Instead of separate files for HTML, CSS, and Javascript, Vue uses a single .vue file (e.g., mycomponent.vue) for each component. While Angular allows both approaches, I initially tried replicating an Angular setup in Vue 2, including a clunky TypeScript integration. Vue 3 made integrating TypeScript much smoother, but transitioning from my preferred structure was a learning curve. Angular provided everything I needed out of the box: router, forms, services, HTTP, and TypeScript integration. Its structure felt familiar due to my experience with Java, C#, and PHP. While I appreciate Vue's flexibility, I ultimately found Angular's approach more aligned with my preferences and existing knowledge.