What Is Your Biggest Struggle in Angular?
What would you want to see if you could have a streamer share how to do something in Angular? What are your pain points?
Posted Jul 6, 2022, 2:57 PM UTC
3188
Having my coworkers follow just the simplest best practices
22
This one made me laugh. So many arguments over this topic...
As something realistic, do you want to see how to set up lint rules and prettier to enforce best practices?
4
I think the default @angular-eslint rules are already pretty good to go (but surely you can configure them more to the teams need).
What really would interest me and what I am currently not finding time for is the whole topic of custom decorators and advanced typescript in general, but that's not really an specific Angular topic. If I had to pick something Angular related that I really have 0 experience, it would be Angular Universal.
6
The most powerful thing you can do to improve your Angular (after the basics) is to improve your Typescript. Getting better at Typescript gives more power to your components and methods. I agree with this idea.
I tend to shy away from decorators in Typescript for several reasons. The biggest reason is that decorators don't update types when used. For example, if a decorator adds properties to a class, Typescript doesn't recognize this in the code that tries to access that property.
I do use the decorator pattern and proxy objects.
5
And also, the TS knowledge is transferable to React/Vue/Etc.
5
That's exactly why! I feel like I have learned quite a lot around Angular and most its features along many patterns and paradigms, but like you say, I want to improve my Typescript to find better solutions for certain data types.
While I was thinking more about your OP question, I never really found useful documentation about advanced content projection besides ng-content and templaterefs inside a component itself. I feel limited in my abilities to be flexible with passing projected content including some kind of state around.
2
Preach! Just build this new component like every single other component in the project. How hard is that?
1
r/angular vs r/Angular2 is definitely doing measurable damage to Angular
21
Can you explain to me what you mean? Is this a struggle when working in Angular?
3
they just mean that there are 2 subreddits dedicated to the exact same thing and neither subreddit wants to shut down and consolidate lol
16
Risking a ban for saying it, but r/angular2 is the subreddit that should shut down and redirect. Add all the mods to r/angular .
Easy.
16
gasp Burn the witch!
3
Angular makes more sense, but Angular2 is larger. So I guess that's why there's a disagreement
3
I haven't seen any evidence of actual moderation on the singular one. So many self promotional garbage pieces there.
1
It's a struggle when working in Angular because people just duplicate their posts to both forums. Angular2 has (had?) more members, so people are directed here first, but Angular2 is years old and doesn't make sense as a name. The justification that it's "Angular2+" doesn't hold water, because even then, most people know them as AngularJS vs Angular.
When someone is new to Angular, which they're most likely to ask questions, they're going to go looking for a subreddit. This sort of disorganization and confusion is friction that pushes people away and to other frameworks.
3
I had no idea that r/angular existed before this post. I didn't realize the community was split like that. Thank you for pointing this out.
5
Part of this problem comes from them naming it "angular 2" when it was a compatible but completely different framework from angular 1. This problem is so pervasively confusing that if you ask me, has done much much more damage to its popularity than anything else could have.
1
rxjs is my biggest struggle. Every time I think I get it I find some code that I have to go read about each and every operator and how they work. Then I forget all that and have to do it all over again the next time.
That and the ng documentation. Some is good, but some is really lacking.
Also there are times when stuff just doesn't work and there are no error/warning messages and you just have to guess why. Can really take a long time to fix those things.
18
I second Rxjs. Especially with realistic examples, those marble diagrams make my brain hurt.
15
I could use a critique on this then: https://ngserve.io/rxjs-tutorial-understanding-the-basics/, curious if this alleviates some confusion.
Curious if my diagrams make anymore sense than those marble diagrams. I created them for mergeMap, concatMap, and switchmap.
5
Great job man
3
Thanks for the article, I didn't understand concatMap, mergeMap or switchMap before reading, I now have a better understanding of them.
Here is my critique :)
* Explain acronyms on first use. e.g. SSE
* "Developer confusion arise if the observable differs in the execution context. Ā This type of difference could be obscured by an operator, which in the implementation of that operator utilizes a Subject." - I have no idea what this means. What do you mean by "execution context"? What is an "operator" referring to?
* "Subjects create multicast event streams that share the same execution context." - Again, what do you mean by "execution context"?
* "the number of shopping cart items places in the header near navigation links" - poor grammar, should be "the number of shopping cart items may be placed in the header near navigation links"
* You give an example of multicast, but not unicast
* It's confusing to have a code example using switchMap before switchMap is explained (you should at least say it will be explained further below)
* I don't understand the MergeMap diagram
* What are the R values representing?
* Why is there a blue R1 and then a red R1?
* In this setup do you only get the messges of users that have joined after you?
* "Contestants choosing the correct answer first and validating answer in an ordered sequence matters as requirements on order of correct answers." the grammar here is confusing, I think you are trying to say something like "Contestants choose an answer, the answer is validated in the sequence they were chosen, then the requirement of who chose the correct answer first can be determined."
* Switch map, I would drop the gym analogy, stick with the type ahead.
* The summary:
* Copy the mergeMap, switchMap and concatMap summary lines to the top of the relevant sections of the article. People can then read the summary, then the explanation, then the summary again at the bottom of the page.
* "There a multicast and unicast observables. Ā Multicast emit the same values to their subscribers, while unicast emits different values of the observable." - I am still not sure what unicast means and where I would want to use different ones in my apps.
3
RxJs is a big struggle until it "clicks." RxJs is the backbone of most reactive designs in Angular components. Thank you.
9
Yep, I habe the same feeling A lot of my colleagues struggle with the imagination of this kind of stream that comes from an observable. I had this problem as well but after solving some pretty difficilt problem with observables with multiple user inputs and so on it just made sense in my brain
2
Huge Rxjs chains that combines multiple data sources, should handle sorting and pagination that the user intersects with. I fail to do things like this without using various variable flags .
3
This is an interesting topic. I would definitely like to explore the tradeoffs with this.
1
Then I forget all that and have to do it all over again the next time.
That's pretty much on you tho... I understand not knowing obscure operators like audit, but you'd expect everyone to know the big 4: switchMap, map, filter and tap
1
Understanding module architecture/properly setting up lazy loading. I always get errors doing this and it's a lot harder to debug than the actual code.
14
I really like this idea too. I like to use nx to help with my modules and libraries. Is that something that would interest you?
3
NX isn't what facilitates Angular architecture like lazy loading. It helps developers build applications with monorepo-styled folder structure.
There are aspects where NX can leverage custom webpack configurations to really tailor the build at a JavaScript module level, but I don't think that's what the OP was getting at.
2
I understand that. I am asking if using nx to help separate modules and libraries is interesting on top of lazy loading.
3
Why is it hard to setup Lazy Loading?
1
You have to realize a lot of devs are on their own. It can be difficult to find good resources. It may not seem difficult to you because you had good resources. This is why I like to ask questions like this. What I think a new dev might want is often way off.
1
Designing components around view encapsulation. On React the componentization process came much easier for me because I would just copy paste some JSX into a component and it would just work.
With angular, before I make the component, I need to understand how the view encapsulation is going to mess up the CSS and I always get confused about when should I put rules in :host selector vs applying them from the outside using the component selector.
I'm also not very good at making the component flexible enough for outside styling.
9
I think extracting components can be a struggle in any framework. I like this idea. Thank you.
2
Angular error handling is a decade behind any other framework out there. I still can't believe my eyes when I see these straight out of 2008 console, so called, debug errors. They say nothing, lead nowhere and has no meaning.
The whole debugging approach is next to nonexistent, actually, especially if you came from react, where developing experience has a high priority.
One more thing. It looks like Angular documentation has been written by s machine or, by someone who really hates plain and straightforward terminology. Like just today I've bee reading about pipes. Did you know that async pipe "unwraps a value from an asynchronous primitive." Wtf is asynchronous primitive?? What is this a reference to - JavaScript, TypeScript, something Angular? When I just started using angular I hoped I'd crack its documentation language within a couple of months. It's been a year and I'm nowhere near...
8
I know the Angular team is working on making errors more friendly. Digging into debugging strategies and how to find the actual error is a great idea. Thank you.
3
Most of the time I see errors thrown by zone.js and I have to dig very deep into the call stack to see what actually caused the error. It's frustrating.
3
Wtf is asynchronous primitive
A container for async data. Eg. Promise and observable.
Now ... forwardRef I cannot understand
2
Thanks! That's what I called a straightforward explanation. :)
I've sort of got the idea of what this is after digging some Computer Networks docs, but why angular guys are doing this to me - a frontend gal?)
ForwardRef is a tough one. š so far I've been using it without really uderstanding what it is ))
1
forwardRef is useful for times when you need DI to work for instantiating something, but that something hasn't been defined yet. For example, if you have a query string that is based on a http query. Your service can instantiate during startup and then another service can define the injection token for the query.
2
So it's more a "futureRef" than a forwardRef?
Or does it actually forward a reference of something to something?
2
I have to use it when html input field value should be different from formControl value.
Eg FormControl - 1000000, <input> - 1,000,000
1
I never used it. Never found a use for it.
1
[deleted]
1
I think with "asynchronous primitive" they mean observables
1
Apparently, primitive is a single package of data in "network science". So async primitive is anything that comes in asynchronously.
I still think it's was totally unnecessary to formulate it like this. )
1
Route reuse strategies seem to be a crapshoot sometimes
6
What do you mean by route reuse? I have some ideas about what that could mean, but I would like to know what it means to you.
(PS, this Saturday, we are going to be doing some Router related stuff)
1
https://angular.io/api/router/BaseRouteReuseStrategy
For example if you navigate down a router tree in a sidemenu-ed app, and then switch to another route, and navigate back to your original tree, the original state could be completely retained.
The route reuse strategy defines that. But Iāve found it kinda flaky.
2
Thank you. I'm not too familiar with this, but I'm willing to fail in front of people to figure it out. š
1
People who dont use it hate it, ive not done a interview with a company who use another framework not stress how much they hate Angular
6
I guess the only thing we can do for perception is to work to change it. I don't understand the hate, but it exists. I wear ng-conf t-shirts a lot, and it amazes me how many people will go out of their way to tell me Angular sucks in public. š¤·
1
Every single person who doesnt/hasnt used it lol
1
When to use ngxs (or whatever) vs events vs input annotations on the component. For an opinionated framework, it lacks opinions in this area so the code ends up doing it different ways.
The lack of free components is a problem. I canāt justify the cost of a paid set but it would be nice to have a wider set of free components.
Writing good unit tests is a lot harder than writing good code. Thereās a lot of boiler plate and magic incantations that if you get wrong breaks the rest.
5
Imo state managers like ngxs or ngrx are almost always overkill. Services with observables emitted by private subjects should be enough for most cases.
I hate unit testing in angular too. Wish they went with jest as default and made things simpler
3
The issue arises where state is stored on a service, then something external updates that state in a mutable manner and causes side effects/hard to debug bugs.
State management solutions almost always enforced immutability to ensure everyone who cares about that data always has the latest. NgRX takes it to the next level by implementing the redux pattern to enforce separation of concerns. While I personally like Akita better, NgRX tends to be the defacto solution since it's most widely used. On top of that, but the maintainer is a former Angular and Nrwl core team member, so he knows his shit.
5
Then don't mutate your state. Learn how to push new objects into the services behaviour subjects. You don't need the derange insanity of a store to enforce data immutability.
3
Services with observables emitted by private subjects should be enough for most cases.
When all you want is to pass data around, you are right.
State Management solutions are for more complex issues
3
Never use a store, stores are a form of malpractice. If you implement a store in your Angular app you are sabotaging the projects velocity, wasting your employers money and destroying your ability to onboard junior devs. If you think that NgRx has bought sanity to your codebase then you had a terrible codebase.
There has never been an instance where a store is an appropriate pattern for a modern web app. It became popular in the React world where it was primarily used to solve prop hell, a problem Angular never had and has now fallen out of favour in new React projects.
Every single line the NgRx advocates regurgitate is just not true, it has never been the standard way of doing enterprise state management, there is no magic line in the sand where complexity is solved by adding more complexity.
I use NgRx as a red flag in interviews. If the project uses it I don't take the contract, if a candidate hints they like the pattern I don't hire them.
3
This is what I meant in my original comment. Half the people say an ngrx store is great, half hate it and another half don't really care.
I've gone through various iterations of using events and input annotations, to use a service exposing observables and using async pipes in the components to a full blown ngrx store.
I found ngrx stores just a bit to abstract and verbose for the relatively straightforward stuff I was doing.
My homegrown services started to look more and more like parts of a store so I felt I was re-inventing the wheel. I've ended up with ngxs at the moment as a reasonable compromise that lets me get on with other stuff without worrying about the complexity getting out of hand.
1
Lots of good ideas in this comment. Thank you.
1
The NgRx advocates. Stores are a horrible pattern that don't belong in modern web apps. People who recommend them to Angular newbies are a cancer to the ecosystem.
4
Redux in general is a terrible pattern with lots of unnecessary boilerplate. You have to write so much code for most basic state changes it's ridiculous.
Handling asynchronous actions via NGRX effects is also tedious.
2
I don't see writing complex forms here as an answer. Fill a form with dynamic input fields that maybe have sub forms etc. Too complicated so I try to avoid such a scenario :P Any tip is appreciated tho.
3
Form composition and decomposition are two important topics. This is a great idea.
1
Advanced component template feateures. ViewChild, TemplateRef, passing context down etc.
Extending Angular components also feels very tedious. I know I can use custom directives to modify components to certain degree, but it feels more like a hack than legitimate way.
3
These are excellent topics to explore. Thank you.
1
I can't get my HTML in my app.component to update while changing the value of a variable in double brackets from another component. I feel like I have tried everything at this point.
2
This comes down to probably something with change detection. This is an excellent fundamental problem that I can show. Thank you for the idea.
3
This Stackblitz I put together might be helpful: https://stackblitz.com/edit/angular-ivy-hfcnvs
1
It's not my biggest struggle but something you could certainly talk about that many Angular developers could stand to learn is component design.
Even the very basic smart/presentation/container component paradigm is something I see some people not executing properly.
2
Great point. Proper component use and event/state handling is a gray topic. Thank you.
3
Love it! It's hard to put myself in the shoes of a beginner at times and this highlights things well, even per my writing skills.
I appreciate the thorough list!
I'll make updates per your suggestions.
2
Actually having devs that understand what a lock file is and merge it when it changes.
1
I love this idea. Learning about your environment will always help when problems arise. The different lock files are essential. Thank you.
3
Writing decent unit tests for components that have a bunch of observables and rxjs operators.
I think unit testing is a great idea. RxJs and observables make it more complicated and less predictable. I have some patterns I like to follow. Thank you for the idea.
RxJS doesn't make things more complicated and less predictable if you're familiar with reactive programming. Since this is a central pillar for Angular, you can really tell the difference between a good developer vs a great one based on their ability to work with RxJS while building scalable and reactive solutions.
Marble testing is a great way to test reactive functionality.
Been a fan of Shai Reznek's ObserverSpy for testing observables.
I will have to investigate this. I haven't used it.
You are right. It really doesn't if you have experience. For new devs, RxJs testing patterns are not what they expect.
I absolutely despise marble testing.
But you can treat pipelines as sync until nothing async is present in them so you can write easier tests with them. Otherwise I just make mock observers and check how they were called. Good enough for me.
This is one of the patterns I like to use. I haven't used marbles testing in years. The Rxjs team advised against them unless you are creating operators.
Just test behavior and not implementation.
That's a bingo