I might look like dynamic props at first glance. But it's indeed statically typed. The NGRX does a great job telling TypeScript about the Types of all the props you define.

Well... I wish you would be right 😅 but it's still not that difficult sometimes to get more informations about the database used (even though this one on juice shop is really way tooooo easy 😊)

Good point here. You are absolutely right. Usualy the angular sanitizer prevents us from things like that. But the sanitizer wasn't used here. We can't control always the way npm Package Authors or other devs in our team are interacting with the DOM. The sanitizer just jumps in if we use the Angular API to interact with the DOM

OK.. So one way or another, someone explicitly bypasses the default security mechanisms built into Angular in order to allow the to be rendered. Another layer of security in that case, would be code reviews. Such efforts to bypass sanitization should be one of the key things reviewers should be on the lookout for during code reviews. Or an argument for paired programming where such implementation would immediately become a point of discussion, and using a Sanitiser like DOM purifier would come up immediately.

@@JonRista absolutely. That's why there is a security principle called "defense in depth" always have more prevention measurement applied than just one. Beside good sanitization the http security header Content-Security-Policy is a great second line of defense

Aye, agreed. I was just surprised that the was rendering at all in your example, as that is fairly unusual with Angular under normal circumstances. It takes explicit effort to bypass the built in measures to prevent that. That kind of thing is actually a good argument for paired programming, as it is the most proactive and efficient way to prevent such code from ever being committed in the first place. 😉

@@JonRista totally agree, this should be mentioned in the video when the is rendered, otherwise it looks like a major Angular bug, doesn't it ? Anyway, excellent presentation !

better then bad content, good video quality :')

Hey I am not 100% sure what you mean tbh. So Things you store in your browser can be accessed through a JavaScript API and are open to be stolen when you are attacked by a JavaScript injection - but it's not really like someones controlling your browser remotely.

Not really. It’s the official ecmascript syntax (es2022) and I decided to use it in this example. Saying this, the TypeScript private also has several benefits: it’s easier to debug (because it’s actually public after transpiling to JavaScript) and it comes with no performance overhead at runtime (for the same reason).

@@ManfredSteyer Thanks for clarification :)

I totally feel you. Using untracked or some wrapper around it like a custom explicitEffects helper or toObservable really helps to see what’s going on and to avoid issues.

Signals is the best thing that ever happened. What are you talking about ? ALL frameworks are moving (or have moved) to signals, and that is with a good reason. Fine grained change detection is amazing. Ditching zoneJS is amazing. I can't imagine not using signals by now.

@@LarsRyeJeppesen Signals are not the best thing and should not be used for everything. The second you need some asynchronous data it becomes a hassle with computed -> toObservable -> toSignal etc. They solve a tiny thing but people misuse them already.

@@andreashahn9037 the problem with signals right now is that they are not fully implemented yet and are experimental, like you said with asynchronous requests: The angular http client still uses observables and has no signal support. Moving to signals is a good choice and getting rid of zone.js, but signals should with care until they are production ready.