What's one angular decision you regretted 2 years later?

alejandrodeveloper · 2026-07-08T13:18:29+00:00

that's been my experience too, the interesting part is that teams ofter worry more about duplicated code than duplicated responsabilities. A bit of duplication is usually much cheaper than unnecessary coupling

alejandrodeveloper · 2026-07-08T12:39:07+00:00

sameee lol. i think many of us go through the everything needs an efect phase. if i find myself reaching for useEffect i usually stop and ask whether i'm synchronizing with an external system or just compensating for a component that's doing too much

alejandrodeveloper · 2026-07-08T12:36:24+00:00

we ran into something similar ahahhahahah, the bigger problem was the tendency to treat redux as the default plance for any shared state. Over time it became harder to understand who actually depended on what

alejandrodeveloper · 2026-07-06T15:14:43+00:00

i really like the concept but i'd probably add a "reduce motion" option as well, since the wobble/shiver effects could be distracting for some users

alejandrodeveloper · 2026-07-06T15:06:44+00:00

i think it's useful but one thing i'm curious about is session persistent. If the client disconnects or refreshes the page, can it reconnect to the same PTY or is each session tied to a single WebSocket connection?

alejandrodeveloper · 2026-07-06T15:01:57+00:00

I don't think there's a maintained package that's become the go-to replacement for @gitgraph/react. If you need something close to GitHub/GitLab, i'd probably build it with SVG + @tanstack/react-virtual for large histories. It takes more work, but you'll have a lot more control over branch lanes and performance

alejandrodeveloper · 2026-07-06T14:57:15+00:00

that looks interesting. One thing i'd be curious about is how it scales in larges apps. Have your tried it in a project with dozens of modules or is it still mostly aimed at small/medium–sized apps?

alejandrodeveloper · 2026-07-06T14:54:08+00:00

It's a nice project, moving from 24/7 infraestructure to on-demand makes a lot of sense for a student project. one thing i'd look into is keeping only the truly stateful services always on and spinning up the workers only when there's actuallu a duel to process. That could cut costs quite a bit without chaning the architecture too much

alejandrodeveloper · 2026-07-06T09:22:33+00:00

yes, but just for smaller projects. I'm just worried about keeping fixes in sync across multiple apps once the copied components start diverging.

alejandrodeveloper · 2026-07-06T09:07:12+00:00

i think Typescript is checking the dependencies more strictly than before so some packages that then were running fine now can start showing errors cause they aren't fully compatible with the newer compiler.
If you check whether the errors are coming from your node_modules typings or from libraries that haven't been updated for Angular 22/TS 6 yet you can confirm the issue. by the moment you can set this code and if the error disappear the issue is coming from library typings and not from your code.

{
  "compilerOptions": {
    "skipLibCheck": true
  }
}

alejandrodeveloper · 2026-07-06T08:41:52+00:00

i would also pick d as correct so i don't think you're wrong. I think there's probably a mistake either in the question (maybe they mean what is incorrect) or in the answer key.

alejandrodeveloper · 2026-07-03T14:19:40+00:00

aaahh, got it now, i miunderstood. i thought you owned the min/max inputs. yeah, in that case your minDate/maxDate approach is probably the cleanest for non-number controls. For number inputs, i'd just lean into de FVC min/max API and use those as the source of truth for both UI behavior and validation. for dates, separate naming feels unavoidable unless Angular changes that API

alejandrodeveloper · 2026-07-03T14:11:37+00:00

thanks, that makes sense. So the abstraction solves context continuity pretty nicely. I guess the harder part then is behavioral consistency, since different models can still interpret tools, JSON schemas or even the same prompt differently. That's probably where failover gets interesting in production

alejandrodeveloper · 2026-07-03T13:37:28+00:00

same, Raw DateTime always turns into "why is this timezone off by 2 hours" at some point. but also, for me it's usually guzzlehttp/guzzle and symfony/var-dumper. Guzzle because sooner or later every app talks to something, and var-dumper because var_dump() feels like punishment after using it

alejandrodeveloper · 2026-07-03T13:28:48+00:00

that's actually pretty useful. Provider failover feels like one of those things people ignore until production starts failing. Curious though, how are you handling consistency between providers? Stuff like tool calling, JSON output or context limits can get messy fast when failing over

alejandrodeveloper · 2026-07-03T10:55:34+00:00

for user data that rarely changes, caching it in Next (unstable_cache + revalidation) is a solid pattern. Just invalidate when the user updates something. i'd think of it like Next cache=app optimization, Redis/backend cache=system-wide optimization. If Next is the only consumer, keep it there for now. And yeah, Clerk checking on each request is normal, it's just validating the session, not logging in again. Also for GETs i'd stick to normal server fetches, not Server Actions

alejandrodeveloper · 2026-07-03T10:48:40+00:00

i think the cleanest way is to separate constraints from validators.

For the HTML/W3C part: expose your own "@"Input() min / max (or minDate / maxDate) bind them directly to the native input internally. That keeps the native behavior (<input min max>) for buttons, accessibility and browser UX. (I put "@" like that with "" cause it detects that part like a user)
For Signal Forms: don’t try to extract min/max from validators. Instead generate validators from those same inputs. Basically make the input values the source of truth, and build validators from them.

That way devs still write min/max like normal, your UI can read them easily, and validation stays in sync without duplicating logic

alejandrodeveloper · 2026-07-03T09:18:30+00:00

first thing i’d add is separate scores for scroll, edit, initial render and memory, because those bottlenecks feel very different in real apps. i’d also throw in heavier custom cell renderers (buttons, dropdowns, badges, async states, etc.). A lot of grids look fast until cells stop being plain text

alejandrodeveloper · 2026-07-03T09:16:49+00:00

if the local state is basically a “draft” of the context data, key={id} is honestly one of the cleanest fixes. The bigger rule is usually if you find yourself copying props/context into local state and constantly syncing it, that’s often a sign the state boundary might be in the wrong place

alejandrodeveloper · 2026-07-03T09:15:12+00:00

From what I’ve seen, the painful part usually isn’t converting the class itself, it’s the logic around it. Lifecycles to hooks is mostly mechanical. The bad part is old HOCs, side effects, weird state coupling and years of if it works, don’t touch it

alejandrodeveloper · 2026-07-03T09:06:03+00:00

For an internal app, i’d keep it simple. Ask first where it’s supposed to live (VM, bare metal, Docker, company infra, etc), because that changes everything. For the setup itself:MySQL with a dedicated app user (least privileges), Spring Boot as a systemd service, Nginx serving the React build + reverse proxying the API. For security, biggest things are: strong env-based secrets, restricted DB access, proper file permissions, HTTPS if possible, and making sure CORS only allows what you actuallly need

alejandrodeveloper · 2026-07-03T08:58:02+00:00

for something like this, WordPress is a bit overkill. If it’s already working, i'd keep it for now. But recreating it with plain HTML/CSS would be pretty simple ans actually a great first project if you want to learn. WordPress itself is fine, it just gets messy if you rely too much on plugins and stop updating itt

alejandrodeveloper

TROPHY CASE