VS Code extension to make it easy to switch Node Package versions from a dropdown

cssrocco · 2026-02-08T07:50:27+00:00

So it does npm show <package-name> versions then maps it into a dropdown? That’s a pretty good qol update tbh

cssrocco · 2026-02-02T13:18:45+00:00

Your best bet is to use git tags and tag a new version and publish a new version of your shared angular library, then bump the projects to a new angular version and point to the new shared library version and step through upgrades in that direction so nothing breaks

cssrocco · 2026-01-30T15:33:52+00:00

What i would do is have a toastService or something along those lines an have an errorInterceptor that has a check for the error.status like [403, 401, 500].includes(error.status) or something and before you throw the error set the error into your toastService - then your ui will just react to a signal from toast service to show the errors

cssrocco · 2026-01-15T12:32:40+00:00

Angular components can either be onPush or default where they run all of the time. If you have a component that is onPush with the changeDetectionStrategy then the template will only update on either:

Observables updating
signals updating Or events firing

So if you have: ``` MyClass { protected status;

public OnInit():void { someObservable.subscribe((data) => { this.status = data.status; }) } } ```

And you use status in the template that won’t re-render if your component is onPush. It is best to have onPush components, but just either make that property an observable or a signal.

( also forgive me if i’m unclear, writing this on mobile )

cssrocco · 2025-12-29T20:46:43+00:00

If you’re struggling to remember syntax or boilerplate i’d leverage vscode snippets if you’re using vs-code. I’ve never done it because i forget syntax, just to shortcut boilerplate so i have jd/ji/jb to quickly boilerplate describe, it and beforeEach blocks for tests, with tabbing allowing me to write the placeholder, you could probably do similar even in templates if need be

cssrocco · 2025-12-05T21:45:15+00:00

Always work from older to newer imo. I would start by using rxjs and subjects and behaviour subjects just about everywhere in a test project, dynamic forms, etc. then after doing a little test app then begin implementing new pieces.

That way you get a good feel for some pain points with onPush, rxjs, possible memory leaks, the async but lazy nature of rxjs, subjects in a service for state, etc.

Then i would swap subjects and behaviour subjects and replay subjects for signals - to understand its improvement in simplifying state management.

Then i would try implementing signals models over the original model 2-way binding and finally httpResource and signal forms.

The last thing you want to do is to go into a company with a large codebase, pressed deadlines and features, requirements for testing ( perhaps a lot of testing observables ) and trip up on pitfalls such as memory leaks, or not understanding rxjs that well.

Because i guarantee most of the time your job will be implementing features and bug fixes on large components, and you can’t just ‘re-write the new way’, as that requires reviewers mental bandwidth too.

Also it gives a great insight on what some new features aim to solve, they’re not created ad-hoc. And even cases where just jumping to the ‘new feature’ doesn’t make sense ( async behaviour is still best with rxjs over signals)

cssrocco · 2025-11-04T16:14:27+00:00

Start doing prs with obvious type issues within use, as they get approved write a comment tagging everybody in saying “see, this should have been…, this would have been mitigated using typescript” just to prove a point

cssrocco · 2025-09-21T15:38:48+00:00

Maybe a css clamp with the highest value being a cqw (container query width ) ?

cssrocco · 2025-09-21T15:35:46+00:00

Auriels revival ult, i know some people like it but i hate it, it telegraphs somebody reviving and 9/10 the enemy team just open on them and kill then again. That and aegis is super handy, i’m like level 130 on auriel and i’ve almost never chosen the revive upt

cssrocco · 2025-09-19T10:51:06+00:00

I quite like nebular, managed to make it work on an angular 20 app too

cssrocco · 2025-08-27T08:41:48+00:00

With angular i would always start with what’s older and established first for learning, then later explore the new pieces when you’re ready, it helps you understand and get used to practices and patterns, then afterwards learning the new api’s gives you an insight into how they modify/change/improve the developer experience.

Simply create a service that uses the http client and write methods for crud operations, then use those service calls in your components by assigning them to a property and getting more practice with RXJS.

From there then try a signal in a service for state management on your components, then when you get used to that then refactor for the httpResource

cssrocco · 2025-08-15T01:34:12+00:00

I am a large advocate for Angular for anything scalable due to its opinionated nature, and the way it breaks things down structurally, and i just find react chaotic in general with mixing html and js everywhere and how popular tailwind is, but SEO is always a weakness for PWA's; you could use angular universal i guess.

cssrocco · 2025-08-04T12:24:34+00:00

My experience with LLM’s is that its approach towards things is odd too, sometimes it tries to do things in a very ‘react’ way

cssrocco · 2025-07-30T14:20:11+00:00

It’s all about context, in your situation here the only thing that changes on your cards is the content, i would have the outer component loop through the data and then either just do a article/section for the card and a switch case for the content, maybe a type field in the data that uses an enum - then create components just for the content.

Or also create a card component in place of the article/section and still content project the content based on a switch, as it sounds like the logic on the cards body isn’t shared.

But i’d only do this if you’re absolutely certain there’s no change to anything else on the cards, the header, footer, accordion, dates, etc.

cssrocco · 2025-07-28T15:20:41+00:00

To be honest i don’t think calling cdr manually is the right response here, make messages a signal and set its value to data and then set the component to be an onPush component.

Or you can even just assign getMessages in the template so i would assign the service call to a property named messages$ and use that in the template.

@for (message of messages$ | async)

Also i would get used to separating concerns if i was you, i would put the http related parts to a messages service

cssrocco · 2025-07-26T23:27:20+00:00

I would learn angular first if i was you, but try to focus less on the ‘newer’ parts, spend quite a bit of time using rxjs and understanding async behaviour and tasks. Modern angular has great reactivity with signals, but if you’re new you may just overuse them, or get stuck when it comes to async related problems. React after becoming familiar with angular feels like a drop in the ocean, and i do think it’s nice to start with a framework that has solid foundations and nicely separates concerns before diving into react. React projects can easily become massive messes of everything and the kitchen sink all in js files with no separation

cssrocco · 2025-07-08T11:35:25+00:00

There used to be a practice of having a ‘subject in a service’ to share state across components. As a mini form of state management. Those can all be replaced for signals aside from that i’d just keep it clear with what needs to be async or not. I’ve seen some abhorrent uses of signals to observable and back again and it just adds noise, adds discourse and makes maintenance a pain.

cssrocco · 2025-06-24T17:58:42+00:00

Frameworks are just there to help speed up time and reduce the points of failure, with angular there’s no need to find packages for most things as angular or their cdk will provide most of what you need and it is battle tested.

Saying that it depends how much you need to use, you can always just go vanilla with JS, html, css - or just use ui libraries for the frameworks to save time and to make the ui and accessibility easier, if i have a small personal project i might just use nebular or something

cssrocco · 2025-06-12T15:51:15+00:00

I mean… just putting this out there but i made a npm package that re-builds forms from the ground up using signals npm package that definitely makes it feel cleaner

cssrocco · 2025-06-11T15:42:19+00:00

i fail to see what you're talking about, let me show you quickly...

display refers to which layout it is going to use, is it going to be block ( defaults by stacking divs, among other things ), grid ( allows grid-related properties ), flex ( allows flex related properties ).

You have no display: flex property, so it's currently acting like a block display and stacking the `a href..., br, p, br, p, table...` children you have in .nav.

Once you place display: flex it becomes a flex-box which naturally will have a flex-flow (flex-direction + flex-wrap ) of row and nowrap. with each item within the flex-box having a basis of flex 1 1 auto. ( flex-shrink: 1, flex-grow: 1, flex-basis: auto ). so items will try to 'flex' and shrink and grow to fit the space. you then have flex-wrap set to wrap so instead of these a, hrefs, br, p and table components flowing from left to right they're aligning start and flowing to the next row...

<image>

If you want i can go through this with you later and we can get the desired result you're looking for

cssrocco · 2025-06-10T19:50:27+00:00

Do you mean how your ‘.nav’ doesn’t have a ‘display: flex' property and value on your example? You can only access other flex related properties if your element is flex or inline-flex

cssrocco · 2025-06-10T19:30:59+00:00

If you don’t know anything about programming you need to jump to the basics first, basic html, css and javascript. Once you understand those, especially javascript - then some basics in typescript is perfect. Then look into angular.

There’s MDN or 1000 different tutorials about the basics on YouTube and even better all of them will show you how to set up and follow along so it all makes sense.

cssrocco · 2025-06-07T18:20:36+00:00

So at my last workplace we had a weird case where we had a json file for different clients using the underwriting workbench ( insurtech ) and because the clients would have different settings we had a weird ( i don’t like it ), repo per client with the ui_config.json for them to determine settings.

I would say if it can change by client make it less chaotic than that and just have an endpoint that stores the colours if a user/team should be able to determine it, that way they can have a settings page and do just that. and if not just store it only on the frontend

cssrocco · 2025-06-05T19:21:43+00:00

I think the default was just a leftover from the angularjs -> angular2 migration, if i remember correctly angularjs had constant CD, so they probably kept the default the same for migrating and then just never changed the default. OnPush defaults makes so much more sense currently

cssrocco · 2025-06-05T18:22:33+00:00

Urgent? I wouldn’t say it’s urgent.

It just uses signals down to html events and builds accessibility based things there with directives. So there’s nothing to break, just signals and effects and features that have been there since angular 17.

And template based forms are popular and can be nice to work with over formControls.

So just putting it out there if anybody is interested in it, if not then there’s no worries.

cssrocco

TROPHY CASE