How to casually change the entire way Angular components work

My Angular course: angularstart.com/
We recently looked at a new proposed format for Angular components that was developed by the community. This video takes a look at how this was accomplished on a technical level and how we can learn from other people's contributions to open source software.
The pull request: github.com/analogjs/analog/pu...
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Want to build mobile apps with Angular?: ionicstart.com
#angular #analogjs
0:00 Introduction
0:46 The basic idea
1:16 How to learn from PRs
1:39 Creating a TypeScript project
1:55 Installing packages
2:18 Parsing the file
2:54 Creating the target component
3:50 Using ts-morph
5:17 Thoughts
- More tutorials: modernangular.com
- Follow me on Twitter: / joshuamorony

[@JoshuaMorony]

Did you know I have a weekly newsletter? Keep up with my content and other cool stuff I find: mobirony.ck.page/4a331b9076

[@chaos_monster]

Teaching AST, without mentioning AST :D nicely done

[@JoshuaMorony]

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

[@NikiHerl]

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

[@craigritchie8470]

Educational wise this is a great video. Thanks. New style wise… if you saw the 1000+ line *.ts files I deal with and the 1000+ line *.html files I deal with on a daily basis there is no way you’d be advocating for this single file format. LOL!

[@JoshuaMorony]

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

[@maksimhyena]

So basically, you want to turn Angular to Svelte?

[@lukebennett3189]

Seems like it

[@JoshuaMorony]

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

[@lukebennett3189]

@@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

[@Dorchwoods]

Yes, that would be great. Haha

[@krzysztofprzybylski2750]

​@@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.

[@MonaCodeLisa]

When you put it like that it's much easier to follow :) definitely helps I so want to contribute and due to that huge skill miss-match between what I typically do, and what I see people doing I just feel like - maybe I should just sit back and observe. There is sooooo much to be observed, it really is like a hit in the face at first, but also so very very inspiring and a great learning source. Thank you for sharing this interesting, positive and encouraging video 👍

[@shemmuthanga6352]

Great content as always. Thank you for showing us how simple some of this seemingly complex technologies are when we break them down to smaller bits and chunks

[@3pleFly]

Thanks to you I understand the basics of how this works and I think I am starting to lean towards adopting this in the future :)

[@rubenheymans1988]

I really don't get how this is better? separated files are great and readeable

[@akuoko_konadu]

Have been doing react and nextjs for over 3 years, and now my work requires me to learn Angular, and this has been a fun channel i discovered, learning new things day in day out, thanks Joshua 🙌 What distro of neovim do you use? And can you do a video about how to set it up for Angular and React development?

[@JoshuaMorony]

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

[@akuoko_konadu]

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

[@it-s-me-mohit]

Awesome video

[@maid768]

With this new format, how would I add an html template of the child component (app-child) inside the parent components template (app-parent) Before you would write like template: app.child.component.html

[@leiayuri]

Hi, would you know if I have a component A which extends a directive B. And in comp. a I am in injecting a service A with inject and inside of the constructor I am also calling super and injecting the service A. The question is, am I creating 2 instances os service A? Thanks in advance.

[@Tomas-ir8xl]

Any videos coming about signal inputs coming in Angular 17.1 very soon?

[@JoshuaMorony]

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)

[@jerrytab4276]

welcome to Vue🎉

[@ianokay]

I don't like putting TypeScript in a tag and pretending it's native HTML, that seems tacky and disingenuous. is doing the same too right?. What's the purpose of such "faux-ity" and misdirection? 😑🤷‍♂ It's removing some clarity and honesty (you can call this "boilerplate" I suppose 😑) in favor of a dishonest representation, which I don't really get the point of. Do we favorite "simplicity" (which is also obscurity and dishonesty) in replacing an actually more straight forward representation, because the latter is more characters? 🤔 Isn't that just an issue better solved with tooling?

[@neociber24]

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.

[@JoshuaMorony]

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

[@ChauTran-xc4ld]

@joshua lang=md on the template for example

[@deefdragon]

@@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?

[@JoshuaMorony]

​@@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

[@SeySvK]

no thanks, I like how separated it is right now

[@AbhinavKulshreshtha]

The best thing about open source, even if angular core doesn't accept this new format, someone will simply create a preprocessor transpiler to convert .ng file into core syntax. Most probably by extracting the logic from analog.

[@marianbencat6658]

If angular go with this formát, half of thé developers Will leave And new incomers Will go better with Vue / react. Keep this ONLY As experiment.

[@porcinetdu6944]

Really hope it never comes, love the OOP approach

[@JoshuaMorony]

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

[@toxaq]

@@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.

[@JoshuaMorony]

@@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"

[@toxaq]

@@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.

[@JoshuaMorony]

​@@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)?

[@Alex-bc3xe]

Looks like Vue or Svelte I think I don't know exactly anymore but seems too.

[@toxaq]

Now can someone do this and let us have AngularNative?

[@redfox2k8]

What's wrong with the original Angular format? I mean separation of concerns is there for a reason.

[@marianbencat6658]

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

[@JoshuaMorony]

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

[@redfox2k8]

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.

[@JoshuaMorony]

​@@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.

[@CitizenCayne]

Now that's Svetle-like. Things to come for Angular? A matter of fact, I think Angular should switch to versioning like Angular verson [YY-...] just like Samsung Galaxy naming convention like S23 Ultra --> S24 Ultra, etc I'd also LOVE to see the developer community STOP using "Hello" or "Hello World!" We are LONg pass he day when they "ping" the interest to send the first message of hello

[@sivuyilemagutywa5286]

If Angular adopts this format, this will kill Angular, I use Vue or Astrojs for simple or static website, but for bigger projects I always use Angular. I am not a fan of JSX, I don't like working with Vue syntax its painful to work with Vue template, but I tolerate it for simple projects. I have never used Analog so I have no comments.

[@jpffinc]

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

[@sivuyilemagutywa5286]

​@@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.

[@rezonant]

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

[@sivuyilemagutywa5286]

​@@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.

[@supirman]

This just feels like going back to the old php days of one huge mess of a file with thousands of lines. I, for one, strongly prefer the segmented multi-file approach.

[@user-hs9uf8fg5k]

trash