Это видео недоступно.
Сожалеем об этом.
New in Angular 14 - Standalone Components and Optional Modules (2022)
HTML-код
- Опубликовано: 14 авг 2024
- Angular framework always evolves and gets better and better with every release. This time really big changes are coming with Angular 14! One of the most significant changes is Standalone components that allow us to build angular applications without @NgModules. Yes, it is still in Developer Preview mode, so the API might change but we can see already the direction and play around with it and start adjusting our libraries and projects. What do you think about it? Let's discuss it in the comments!
💥 Angular courses made by Dmytro - bit.ly/df-courses 💥
✂️ Use coupon RUclips_DISCOUNT to get a 10%-off discount ✂️
🕒 Time Codes:
00:00:00 - Intro;
00:00:28 - Motivation and Project onboarding;
00:04:58 - Updating project to Angular 14;
00:07:46 - Make the first Standalone component;
00:14:42 - Lazy-Loading and Standalone components;
00:19:00 - Bootstraping application without NgModule;
00:23:19 - Outro;
Initial project state on GitHub:
github.com/DMe...
Finished project state on GitHub:
github.com/DMe...
↙️ Short Frontend Snacks every week here:
Twitter - / decodedfrontend
Instagram - / decodedfrontend
LinkedIn - / dmezhenskyi
#angular #webdevelopment #ng
💥 Learn Angular Forms in-depth and start building complex form controls with ease💥
🔗 10% discount for the first 10 students - bit.ly/advanced-ng-forms-discounted
💡 Short Frontend Snacks (Tips) every week here:
Twitter - twitter.com/DecodedFrontend
Instagram - instagram.com/decodedfrontend
LinkedIn - www.linkedin.com/in/dmezhenskyi
How to material with standalone component?
how to use material with standalone component?
I really like the concept of modules. With modules you have the power to keep some components private and expose only the components you want to be referred in other components. From dependency management view you have more control which parts of your code have an higher dependency with others. Without modules it feels for my more like anarchie.
Totally Agree, Honestly i cant imagine Angular without Modules and if i were force to write code without them i would rather choose Vuejs or God forbid React......
@@starlite7249 😁
@@starlite7249 why? React doesn't use modules
@@starlite7249 breaks my heart just a little you didn't say svelte, if we all miss svelte that's a BIG miss IMO
You could combine both. Imagine your standalone components are like components from a library. They need to be dumb, meaning that they don't know anything about the project itself. And then you could have components in a module that are smart, they have services with business logic injected in their constructors. If you want to use your dumb components, just import them in your modules.
It is something similar to use a library like Material Angular, you needed to import the components you wanted in your module, and the components of Material are dumb because they know nothing about your project.
ще раз подивився відео, трішки освіжив скіли. дякую.
I think this new feature can be the turning point for angular. And more devs will use angular for smaller projects, this can make development fast like in other frameworks (react and vue). As we know, right now angular use for medium to large projects only.
Thanks for sharing this very fresh feature from RC. Your channel @Decoded Frontend is my favorite source of knowledge for Angular.
Thank you! Glad to hear that 😊
I was used to NgModules , but i think that Standalone component will be somehow connected to the new feature they have on roadmap. Let's go Angular, and Decoded Frontend, watching you from the start, you rock !
I really like this feature, but I think I will only use the standalone for dumny components. Module keeps the application organized, moving modulea responsibility to components could make the application a mess
I'm not alone
Thanks for video
ha, back to good old times) I remember NgModule was introduced in Angular 4. There were no modules since Angular 2 was introduced, so I remember the pain of migrating the existing projects to it
Hi, at first, I really appreciate your way of introducing 14. You just update 13 to 14 and showed what is changed along with the details. bravo.. Cheers🤘
Thank god. All this module boilerplate code was driving me crazy.
Thanks a lot. I appreciate your efforts.
Thanks, Denis!
Great video! Helped me a lot to migrate my own angular app (created for learning) to standalone components. I really appreciate!
I think total depending on standalone compnents will make the structure of projects messy in large scale projects but it still an optional till now so it is ok
Looking at the comment section, there's more people who dont mind NgModules than I personally expected.
Thinking about it, I think SCAM/inline modules is the best compromise, instead of having a separate file (traditional modules) or putting the imports inside component decorator (standalone), maybe the best is an in between, inside the component, declare an array of imports outside the decorator just called modules i.e const MODULES = ...
and import that into standalone.
I think this feature is more harmful than useful. Modules are exactly what makes Angular unique and more structured, unlike the garbage dumps in React and Vue . I think some Angularest will appear very soon, as it was with Svelte and Vue 3
Hi, I'm an avid browser-side only vue user. The whole backend ecosystem is a bad choice to me, whether its angular, react or vue. What makes vue a garbage dump for you? Because that's exactly how I feel about angular modules. It doesn't actually solve complexity issues of the program, only the framework. (Vue doesn't do this either, so I have same problem there)
@@msc8382 I'd have to agree with you. Getting rid of modules will only make things cleaner and less verbose. One thing I expect to be irritated with, however, is scrolling past this enormous @Component decorator in order to get to my component code. Perhaps this can be resolved with a plugin which auto-collapses that stuff.
@@msc8382 to me it's the fake props in a vue component, all to hide that it's really just a typescript class underneath. Too much magic imho.
@@stephenpaul7499 if you have enormous @Component decorator with a lot of imports it might be a sign that your component already violates the single responsibility principle and probably needs to be refactored and split into smaller pieces ;)
@@DecodedFrontend I concede that you are correct. I just upgraded my codebase and, to be honest, I couldn't find a reason to go with standalone components for precisely this reason.
I believe that Angular, while a floored framework (as they all are) probably scales better than any other fremwork precisely because of this separation of concerns.
Please keep up the good work with this channel. I admire what you're doing here.
Great features
Awesome!!!
Hey thank you for this update very briefly explained!, But this seems kind of tricky to import large number dependencies into a component everytime when you create a stand-alone component.
And yes it will be more tricky if you wish to convert your existing large application to this kind of architecture. But yes this feature is really nice.
Thanks for your feedback! :) Well... I understand your concern but from another side, if your component has a lot of dependencies then maybe it means that you violate the "single responsibility" principle and it is time to split it into smaller parts :) Regarding migration I think we have to wait a little bit and see what kind of best practices and patterns will be born from this new option like standalone components, I am quite sure there will be something.
@@DecodedFrontend 👍 I agree with you. Also this needs little more experiments from our side as well to find out new approaches to use this feature.
@@mogheshantanu exactly! That’s why this Developer Preview mode exists 😉
The standalone components can be used in pair with a small and well defined shared module with 3rd party librairies module (ngx-translate, fontawesome, ...) and mandatory Angular module like CommonModule.
It can reduces a lot imports in standalone component.
Excellent! Thank you very much dear friend for this informative video
Have been waiting this for the longest of time! It will be such a time saver.
Does this help reduce the bundle size?
Hi Pedro! I wouldn’t expect any significant change regarding bundle size but it needs to be tested of course. I am sure that soon we will see some benchmarks that will give the accurate answer to your question :)
Thanks for sharing this awesome feature , sometimes no need to declare module for every component we can make😀, i think this make some confusion for new comers.
This really confuses me xaxaxa
Thank you for your videos!!! You are top at Angular video bloggers!
I think it will be more user friendly especially to newcomers and it all looks and feels more intuitive that it did before with the modules.
Well, nice video, but I still think that it's usable for SCAM only, coz it's annoying to fill each component with imports property + I can import one module, instead of importing multiple components each time
I have to double check that I have hit the like button!, great job!
You're a brilliant instractor
Thank you for the explanations, it was really clear! I really like this approach, I feel like angular app architecture will be simplier with standalone components. I wish in the future there will be a way to lazy load a component when it appears in the template, without having to use the router.
Wow awesome👏, but refactoring could be difficult on large applications and that also depends on some third party libraries. It will also pave way for its popularity in general. Thanks for the update.
Yep, refactoring might take some time, for sure but maybe we will see some migration tool that could simplify it.. let’s see. And frankly, I would not hurry up to refactor big projects so far :)
3rd party libs are all compatible (in theory) with standalone components but many of them will definitely change the way we include and configure them but it won’t happen in one day and we will have enough time for smooth transition likewise it happened with IVY.
@@DecodedFrontend how to use material with standalone component?
Great video, thanks!!
What about shared modules that we used to create aiming to share pipes and components? How can we do this?
Good job on making such a great angular content, each video teaches me something new! Also thanks for creating such a great community in comments and speaking up on some real angular topics. Anyway I was waiting for this feature so long. Looking forward to upgrade my pet project.
Яшчэ раз шчыры дзякуй і Слава Украіне!
That was awesome, thanks, really simple really understandable.
Thanks you for this video, it was clear. I heard your mechanical keyboard, nice sound
After introducing standalone component, if that ngModule contains many dependencies, then need to imports them all in each component, so in this way code length will be even more bigger. I would be prefer to have ngModules and this is more organized.
May I know the exact reason this introduction?
Thank you!
Thank you so much for these great videos, great work.
What will happen to application architecture , Lazy loading , Routing, Dependency Injection, importing all the Material stuff into one Module etc etc. Angular very existence and the millions of Big projects made with it all revolve around NgModules what will happen to those???
Are we really throwing all those things away just for the people that do not understand how NgModules work???
I personally feel like this will be another option in our toolbox and not necessarily "the new way to go". It might work best for dumb UI components that can be reused across the entire app but don't have to declare a whole module for that small zero-dependency component. Just an opinion though; I could be wrong
Up to you
Wow. This standalone stuff will be really usefull.
awesome updates, thanks for sharing
Awesome content. A bit irrelevant but can you please share with us your mic model and what you use to process your voice? It sounds awesome, it's like voice's coming from the back of my head.
Thanks! Very helpful video :)
Not sure how exactly this makes it easy for new commers. Dont think ngModules are going anywhere cause even benchmarks dont show any benefits at all.
Thanks for your comment! :) For newcomers, it is fewer things to learn :) They don't need to care anymore about how will be configured providers from modules (both lazy and eager ones), they don't need to learn why we should export modules/declaratives, and so on. And for me, it is fewer things to explain :) On benchmarks, you will see no difference of course because modules do not impact run time (if you meant that).
@@DecodedFrontend seems the update is focused on trying to win react developers cause this will quickly become messy for large projects. But oh well typed forms is probably a worthy tutorial update for me. Thanks for your view.
@@g-luu Yes, typed forms would be so gooood
@Bryan Luu Most common issues for people new to Angular projects is circular imports. They have a shared module, multiple feature modules, etc. Then the designers decide to use a component in Feature area A in Feature area B. Now you have to rearrange those components to avoid importing one feature module into the other. It was pretty overwhelming for me when I started, and I have a lot of new-to-angular devs having the same issues.
With standalone components, you can easily avoid those situations.
@Bryan Luu as you mentioned this whole stupid move is just to win over more React Developers. I cant bear to imagine how will we go about Structuring Large Scale Enterprise projects without NgModules. Go see any Big React Application its a fucking nightmare to maintain......
I don't think that this is going to change shape of current Angular applications. This is more about new applications and libraries which you can make easily with this solution. Imagine rewriting apps with 30+ modules into those component dependency import hell 😁 anyway, thanks for great explanation!
Exactly, I don't see what the business case would be for doing this. What do developers gain from updating existing code? Cleaner code, sure, but if your code is well structured then the effort might not be worth it.
I have created a component with standalone is there a way to change it back to normal component
Hi! Just remove standalone: true from the @Component annotation and declare it in the ngmodule where this component is supposed to be used
Love it!!!!
Thanks!
Do you know, when angular team gets rid of zone or at least makes it optional when you create the app?
Unfortunately, I don't have such information.. but it is on Angular roadmap ;)
what's wrong with zone?
@@praktycznewskazowki6733 I wouldn’t say that something really wrong with Zone but Zone blow up the call stack and you have to deal with that all invokeTask(), runTask(), etc that can make debugging process slightly uncomfortable (of course you can blackbox it in the debugger but still…), also it is an additional dependency and we can decrease bundle size getting rid from Zone.
How will the change detection work without zone?
Will Angular turn into React without zone and change detection?
@@DecodedFrontend there're already solutions like rx-angular and ngrx/component, that work without zone
Always thankful for sharing amazing content. But this time I don't know why I'm not liking the standalone feature. By the way thanks again ☺️
Thank you so muc, I just started learning angular..and I see all other course are legacy versions... Could u please create or advise if there is any course on angular 14 with analytics website.. the other challenges with courses are data level permission, authentication and authorisation... If u could advise q course on these that wil help Sir.. :)
How is it possible to add tips during typing in the terminal tab? Like at 5:27
Is it necessary to make AppModule a standaolone component ? We can boostrap out the application via the appmodule and create other components as standalone? I think it would be cleaner that way.
no i also think appmodule making it standalone is right now unnecessary
Hi there!
Can you plz make a video about @rx-angular/state
Could someone let me know which editor color theme is used here in this video? Thank you.
I Liked standalone components concept, it can make our code more easily and small. In all of my applications i have ngModules declarating only one component, many modules code... Modules are necessary, not your mandatory!
Dude, дякую
🇺🇦
Hey. You have mentioned in the video that "who knows, maybe NgModules will be eventually removed in the future". Do you see any way (right now, with current standalone API) to implement configurable modules using forFeature(config) method, parametrized with configs (using standalone component way) or overriding lazyloaded route components with optional injection token configs? I am right that using NgModule for that goal is still the only way?
I think so the feature is good but also to be enjoyed with caution, I mean well it depends here on what you want. If I now only have a small widget which has little dependencies and is almost alone in the module, it makes sense.
But one advantage that modules have is for example which components we want to expose to the outside. And they are better configurable. So rather for more complex things. This does not necessarily make it easier for newcomers, because they have to think about what I want to achieve. Do I use a standalone component or rather a module.
But however I see that already before me if something new is there everything must be built so, in the case it is only an import. But the reality looks a bit different ;). Okay not every component needs all the imports that are defined but let it grow to 3 - 4 or more, then you may need another service that you define here because it should not necessarily run in the global scope.
This will get very ugly very fast.
I am currently trying that standalone component and my code become cleaner. Next job is angular without ngzone
Awesome video thanks a ton💖, I have one qn, how we can handle Singleton services in set of components, previously, Modules are taking care of this, is there any alternative way in this Architecture?
It seems like Angular is trying to provide an alternative in order to compete with React. By having the capability to use Modules as well as standalone components. I think by enabling the standalone components they will eventually have a schematic for smaller scale projects that don't require the heavy framework load.
Hmm i think we can replace the shared module by Standalone components
Nice video, thank you! I'm just curious, if it will be possible to have lazy loading for such standalone components without adding them to the routes. With the help of *ngIf , for instance.
I love the idea.
Some API like this would be nice:
Then, in combination with *ngIf or *ngFor, the standalone component would only be loaded the first time it shows up
introducing a new way of making a mess :-)
I'm still struggling to see what issue Standalone Components is solving?
So far it seems like the only benefit is getting rid of the modules file, but now you have to copy paste all those imports to every single component that needs them. It is not easier to just put them in one file, you know, the modules file? 😅
The only place I genuinely can see for this is a shared module that has little, if any dependencies, but is instead depended heavy on. So maybe a component library, i.e. the Angular Material project. It's really the only place I see this making sense 🤔
Can we use react npm package inside angular application.. is this possible??
Hi,
Yes you can. Google for “module federation” and “micro frontends”
I don't find it much beneficial but I see it creating extra overhead for each standalone component making build process slow.
It seems as if we can are creating a separate dedicated ngModule (with only one component inside behind the scene) for each standalone component.
It's no rocket science in it.
I don't know...looks like each component gets a module...
I think this feature is a good solution for the "dumb components".
Hi, Do you know if Standalone components are compatible with, for example multiple providers in app.module.ts? And with multiple .forRoot like ngx-translate?
Thanks you!
This latest update can be resume as the following analogy :
x ( a + b + c ) // Angular v13, simplified
a.x + b.x + c.x // Angular v14 ... bruh....
Component a imports whatever it needs, component b imports whatever it needs, component c imports whatever it needs....
What about making it the other way, you know, like we have now, component a, b and c uses everything that is imported from one place (x)
Up to you
If you prefer all shared imports to be at only one place, my guess is that you can create your own array of shared imports and then use it.
@Component({
standalone: true,
imports: [...YOUR_CUSTOM_SHARED_IMPORTS_ARRAY],
})
@@davidjournot1741 it would be nice if the compiler understands that imported components/pipes etc should automatically be injected into the component. Would avoid the double boilerplate
Awesome feature
Mah-jewel
I don't like it to be honest...
Following your user component example, what if that component, within its HTML, uses several components, such as :
> app-user-list
> app-user-edit
> app-button
> app-input, etc...
then I would need to import each of them in the imports component metadata? so the component metadata might end up looking like a freaking @NgModule ?!?! not to mention if we are using Angular Material, I would also need to import some modules in the component.....
What about pipes? what about directives... everything will be defined in the component... lmao, for that, I would prefer 100% define everything in the respective module and leave the components leaner...
Только мне все эти импорты-экспорты в модулях кажутся путанными и не интуитивными? Новая система, вроде, чуть попроще. Но не менее путанная.
Great feature but imports array is annoying. I hope it disappear in next versions. It seems that TS imports should be sufficient or be done behind the scene.
I do not like this approach of Angular 14, modules keep your work organized.
I also have some questions, what is the advantage to this approach, does it make Angular a better choice for lightweight applications.
If that is not the case, I do not see any valid reason for this change
meh, I am good with NgModule actually
One of things i love about Angular is its modularity...And they are trying to take it away from Angular. Without modules, it will be another react sh*t. Unreadable, unscalable and shitty structure !
Somehow there is a huge loss in your voice quality between the intro and the rest of the video.
angular is the worst framework ever
now remove the need to explicitly declare providers from the code my team has to write and handle that behind the scenes (some form of reverse tree shaking in the transpile??), the DI system is great (seriously, LOVE it), but I'd say still needs a bit more work to entice more DEVs to this platform for new/small projects, IMO providers were more obvious when you had to explicitly write the module files...now it feels odd to have to go to the main.ts file and {provide: XDirective, useClass: XDirective} though I expect I'll get over the odd feeling after more time with this