Nicolas Gehlert

question for angular experts… can somebody point me to some good resources for signals? especially for larger (existing) applications? Everything I've seen so far focuses on learning Angular or new applications. I currently don't see any benefit in trying to mix both patterns 🤔

@cassidoo @lemonsqueezy never heard of this platform before, but I managed to buy a beautiful iPod design on the first try ;) My new favorite wallpaper

It's 2024 and I still don't know how to make an easily downloadable file without making a mess so I plopped this on @lemonsqueezy for free if you want it for yourself! cassidoo.lemonsqueezy.com/buy/982b1603-4…

I made a fun lil wallpaper for my phone!

The reason I changed my mind about signals is because RxJS is truly bad at synchronizing states efficiently and ergonomically. But there are other things for which it is currently the _only_ good tool. Angular supporting developers who don't want to use RxJS feels like worse than a waste of time. It's like working to support devs who don't like TypeScript. Or devs who want jQuery interop. It's going to lead to a lot of projects with redundant concepts and disjointed styles, having promises here and observables there, developers not knowing which to use when, and overall writing more imperative spaghetti code. Part of Angular's identity is to be opinionated about best practices. But maybe declarative code is still controversial. How about we give more time to the community to work with RxJS + signals before spending resources on dropping the RxJS dependency? Can you find Svelte developers who hate Svelte Stores? They are very similar to observables, yet I haven't heard of a split in the Svelte community over stores. Will we ever know if the community is split because some developers hated the experience of Angular + RxJS, or RxJS itself? By assuming it's RxJS itself, aren't we creating a larger split in the community, and basing it on an improbable assumption? I believe it's improbable, given how many hoops we've had to jump through using RxJS in Angular up to now. After 8 years we finally have a way to write reactive code that uses component inputs, and a smooth way to access it with RxJS. Can't we rest for a minute and see if attitudes towards RxJS change before doing something drastic? If devs have been _tolerating_ RxJS before, won't it be easier to tolerate now? If I had my wishes, the Angular team would recognize that RxJS is heavily used in Angular apps today, and spend resources on tutorials and documentation for RxJS + signal patterns. After a year, reassess. I think people would be surprised at how smooth learning Angular in this paradigm could actually be. I'm a GDE but I know as much about Angular plans as any other developer. But it seems like they actually are set on removing RxJS as a dependency. I predict that 2/3rds of new Angular projects will not use RxJS at all. 1/3rd will, and will understand why, having intentionally chosen it, and therefore code cleaner apps. So the community will have a fairly clean split between 3 types of apps: janky legacy RxJS + Angular, new Angular sans RxJS with varying amounts of spaghetti code depending on complexity, and highly declarative Angular + RxJS codebases. Angular Query will become more popular in the generic Angular codebases. Those devs will gradually think more reactively because of that. And eventually most projects will start to use RxJS again, if AI hasn't taken all our jobs by that point. But the history of web development has been a bumpy but definite trend towards more and more declarative coding styles. Anyway, nothing is risk-free and maybe all of this is worth widening the split in the community, because appealing to newcomers is so important at this time. It's not my decision. I just know that I will have fewer job opportunities in the future that I actually want. Going back to an imperative paradigm to me is as unappealing as going back to JavaScript from TypeScript. I wish I had more time to work on this stuff, because my highest priority at this time is to show how simple RxJS could be with the right advice/tutorials. Maybe I can help some developers make decisions that will lead to less buggy code.

@housecor didn't see it in another answer, the same thing is possible with switch as well. you can create a guard function like `function guard(_value: never): never {throw new Error('');}` and call this in you default. If you add a new value there will be a compile time TS error

In TypeScript, I often prefer to use a Record over a switch statement. ✅ It's easy to read. ✅ It's typically less code. ✅ It's safer. With a switch, I have to do extra work to assure it's exhaustive. With a Record, if I forget to handle a case, it won't compile.

is AngularJS still a thing?

@syntaxfm seems like this could've been prevented with a unit test 😜🙃🙃

A brutal Big Brother bug causes complete chaos. This one is serious business. Strap yourself in 😬.

.@MrBeast leading the way 🔥

Die neue TV-Heimat der #NFL knipst die Lichter an! Das lange Warten hat ein Ende – am Samstag feiert die NFL im Rahmen der Preseason ihre Premiere bei @NITRO. 💥🏈 Erstmals meldet sich die TV-Crew aus unserem neu konzipierten Live-Studio. 👀 ℹ️ on.rtl.de/9/Studio

@ddirkinho dann bin ich mit 140k ja noch relativ weit vorne :D aber trotzdem viel zu weit weg 😂

📣 Thrilled to share Angular v16! It's the biggest release since the initial rollout of Angular making large leaps in reactivity, server-side rendering, and tooling 🔥 blog.angular.io/angular-v16-is…

Definitely an interesting take. I like your points 👍 I feel like most people are too afraid to argue against the Signals RFC because it's "hype" and "shiny"…

@EsumePatrick Sehr informative Videos. Mir raucht jetzt schon der Kopf obwohl nur die "einfachen Formations" gezeigt wurden 😂

Wie schon im #footballbromance Podcast erwähnt: #bromancetaktikschule geht in die nächste Runde 👊🏽 Diese Woche: Trades,Shifts and Formations . Educate yourself 😘 #bromanceyoutube #coaching #nfl #americanfootball #rannfl #rannflsüchtig #coachesume

@niksalsflausen Finanztipps

are there any examples out there for a self-hosted distributed cache for NX that do not use the NX cloud service?

@LukaFurlan_ @t3dotgg

@t3dotgg I feel like the examples are tailored to support inferrance and do not really show real world usage. I've never had any issues that were described in the video and Ive been using typescript for years. Im all for explicit return types

The Case Against Return Types, new video up now youtu.be/I6V2FkW1ozQ

@niksalsflausen wo kann man die probieren? 😅

@Enea_Jahollari @angular I feel like they are solving a problem I'm not really having. I see that the boilerplate is less, but don't really like the Array exports or barrels as you still can directly import the component itself. Will there be eventually support for true standalone services?

@gehlertn @angular Standalone components are components that import their template dependencies instead of being declared in a module and getting their deps from the module imports. Standalone cmps are easier to think about and use. NgModules will be replaced by simple arrays. That's it.

whats the common understanding in terms of @angular standalone components? will they replace ngModules? do ngModules still have their place? will they be removed eventually? 🤔

It's that time again when we start preparing to release another major version of AG Grid and there is a lot in this one! 😊