u/fdimm

No really change, but I did wake up with back pain for no reason, so be warned and stay active.

UX and accessibility guidelines says no and I agree with the sentiment. Let the user press it and then point out what is wrong in a shape of banner/toast or any other feedback that fits the page.

The only exception we have at work is that we tend to disable the action when it is in-flight, such feedback is also immediate and you'll know why it got disabled, in any other scenario you have to explain.

Fortunately or not, we are not using either. Chugging along with http client and rxjs just fine.

I'm also dreading the day when I'll have to spend time refactoring our core components library (and features after) to use signals and virtually accomplish nothing from user point of view.

For one of the internal tools I'm literally zipping JSON string to make it fit in the url, worked okay for my crazy case

Dynamic import is another issue, I hope they won't drop webpack before esbuild fills this gap. Thanks for sharing chunks issues, I should investigate situation on our application.

We do the same, local build with esbuild (with few not actively developed features broken) and prod with webpack. Tree shaking behavior is also different/worse.

There is something odd with vite dev server handler in the cli, I monkey patched our installation when it could not serve a url ending with ".md".

At least in v20 they are checking mime type of request url. See html-fallback-middleware.js and debug your case.

Noy knowing the details, I don't think you have to change THAT much. Conceptually, you just have to develop the new auth part and plug it in in the same way as you do the current auth.

Think about it, in traditional setting, you exchange the username/password/otp with a session cookie. Say in oauth flow, the 1st step is different (involves redirect to third party provider and then validating received code), step 2 still involves session cookie or whatever mechanism you use to check if user is logged in.

It can get way more complex if some downstream service needs the original auth token, but it doesn't sound like your case. Hardest part is token refresh in this scenario.

My plan is to refinance as F3 and prolong the period back to max to keep the day to day economy the same

This is what we do, in internal libs, we export testing entrypoint that holds these mock components, modules even for more complex cases. A bit annoying to maintain but works okay and no need to rely on third party libs

Pre building libs makes DX pretty bad, I wonder when it will break (if ever), but I set up dual mode in tsconfig path resolution.

Compiler either takes pre built lib from dist or typescript code from public-api.ts in projects folder. This way I get best outcome. I don't know why this is not the default.

Some kind of shallow rendering for unit tests, so that only child component inputs/outputs would be verified without of us making mock components.

At the same time a flag in TestBed to fail if not all providers are mocked for the given component. This is a pita with standalone components.

Angular material is still suggesting modules use in docs, for say Buttons. So I guess/hope that they will stay for longer.

Modules still have good use cases. Like changing behavior of every component with new directives without adding each dependency explicitly in every use case...

We use pdfmake, of course it has its own document format and works pretty well IMO. It all depends on needs

I'm moving the monolith in a similar direction. Each module becomes a library in projects folder, with routes and multiple entry points to have sensible structure/packages and ensure that future is without spaghetti where files are imported left and right in source folder.

After doing the first one looooong time ago, DX felt quite horrible, having to rebuild the libs slows things down a lot. Whether manually or by nx, it doesn't really matter.

The key to this problem was to enable dual imports in ts config.

````` "paths": { "@lib/": ["./dist/lib-", "./projects/lib-*/src/public-api.ts"] }

`````

This way you can pre build the libs, or use them directly from source. Now I can just run npm start like normal and let cli figure out the most efficient way to build stuff. We have a bit more than 1000 components and our local build takes 90s for the main app. Style guide takes like 25, but only includes shared components libraries. Just finished upgrading to angular 19, nothing is standalone and webpack is still used for building.

Feel free to PM, I'm curious about your situation

19 I think will be more cumbersome because of standalone components, we have a massive project with multiple teams and long living branches - touching every component is not fun.

I hope there is a toggle in angular.json to keep on using modules.

Most of the time not, except for a few specific tests in core components where what is rendered is tested.

Mostly because I want to make sure that nothing breaks if browser behaviour changes.

Somehow I'm a sucker for Halifax, I couldn't find anything better yet

I had my screen going blank in a similar way because I didn't twist the key all the way few times lol

None. A service is all you need until you need more

You can also use DOMParser if it is a valid html to get the document and then read the textContent of the body.

Make that endpoint emit js or JSONP to expose the environment variables.

We dynamically add this script to the DOM in main.ts and run angular bootstrap when it loads (or fails to do so). We share one production build artifact in all environments.

This is not going to help, but it will be a little lesson to not be an early adopter. I'm sure support is documented (or not) in storybook. Check all valuable dependencies before upgrading or starting to use new APIs next time. This can be very costly based on the situation.

Haha, Gemini 2.0 says two. This is so silly.

’There's one in "straw" and two "r"'s in "berry," totaling two "r"'s in the entire word.’

Thanks for the laugh

None, it's not needed in angular apps unless you maybe need it to function offline.

I could have written this as well, thanks for posting. Exactly the same problems I'm dealing with in the corporate world. I'm even happy with the modules.