ervine

Watch out, Lee is gonna show up and defend this decision and not respond to any valid criticisms.

Yes.

Whether you enjoy utility classes isn't really related at all to what css supports.

Oh yeah, you have to get into branded types for this I think, which means a parsing step. Fair point.

For sure, linting is just as necessary as typescript for a sane codebase.

Oh yeah definitely, I write the types that I expect from the API - the point the original comment is making is that the state of reality is not your types, it's what the actual API returns.

But yeah if you use something like Zod you can at least say "this is what I'm pretty sure the API should return" but also define what should happen if things change / don't meet your types.

Yep, adopting strict after the fact is a different conversation, but one that has been talked about a bunch and there is even tooling to support progressive adoption.

Types that are too complex... hmmmm - I'm sure this exists in domains other than the bullshit CRUD apps I write. So yeah, I guess I don't know what I don't know here. I've written some pretty crazy types though, not sure what TypeScript is unable to represent.

Yeah, those are few and far between, generally there will be a DefinitelyTyped for anything popular, and you start choosing libs that are written in TypeScript over ones that aren't.

But for your own handwritten application code, there is no excuse to use `any`.

Not if your types represent something you don't control, like an API response.

Why is `any` allowed at all? Enable strict mode, set up your linter, don't allow any implicit or explicit `any` anywhere.

Without this, Typescript is next to useless. Not knowing if the types are good is worse than no types at all.

Just knowing wtf an API response shape the app is expecting, or what the shape of a function argument object is... I can't imagine arguing against TypeScript (or whatever thing documents the shape of your data as it moves through your app).

Are you using strict mode?

I would feel cool doing this until any sizeable DOM manipulation and then immediately remember why react was such a godsend.

You can't even become a next.js expert because it is constantly changing.

Even the devs involved don't have their heads around what they've built, considering responses in github issues.

What kind of stuff do you give up with an SPA?

Yah agreed - updating params when filtering / sorting / paginating should replace instead of push to the history stack. Easy enough to do.

Huh, I guess we have different expectations. I really don't mind a few seconds even to know I didn't totally break things in a commit.

I think it probably is saying: don't write a "useEffect runs when its dependencies change", write a "User is redirected to their accounts page after loging in", and you are testing both your own code and the framework's routing / side effects handling / state tracking, etc.

Integration tests for complex flows inadvertently tests your dependencies, which as you say is awesome for when you have to upgrade.

next.js, apollo client... so many surprises even in minor point versions.

Not for things like type / lint / formatting errors. Tests too if not too long.

I mean have them in the CI as well, but for sure have them as pre-commit hooks.

Slightly-longer commits to have never-broken commits... hmmmmmm.

One of my favorite eslint rules to enable: https://github.com/jsx-eslint/eslint-plugin-react/blob/maste...

You could use something like json-schema to define constraints, and use json-schema validator libs on the front and back end to validate the form data against the schema.

You still need to handle the "what happens next" part on each side, but at least your validation rules are shared.

I agree with your first point.

Configuration as code is actually one of the best parts of Drupal now. I think it's probably symfony as well under the hood, but you can just import / export your config with a CLI and commit as yml, makes moving configuration to higher / lower environments so pleasant.

But yes, I think with Drupal 7 there were a lot more "site builders" using Drupal, where D8 I imagine it's mostly just developers left standing.

Drupal is still a thing. It's actually really great, but it suffers from two things:

1. You need a deep knowledge of Drupal to put together something good. It's not beginner-friendly, you will build a couple clunkers before things click.

2. The mind-share is not there like it was for Drupal 7 - the devs still contributing are great, progress is being made, but if you're used to Wordpress plugins or an NPM package being available for whatever you need, Drupal can be frustrating.

Aha fully-sighted and I've never noticed this... 15 years of mac use.

Again, it's not hard - just being devil's advocate for when toasts are useful.

Less code, centralized messaging.

I didn't say it was hard, it's just very nice to not have a bunch of extra error / success code in all of your components that make async requests.

Trade offs, as usual.

Maybe bad UX, but global error / success handling of network requests is way easier than handling in every component that triggers one.

Regardless of how you may feel about the locked down Apple ecosystem, it's pretty clear (imo) what the question meant.