ervine

6 ms·

31.
by ervine 2y ago
Whether you enjoy utility classes isn't really related at all to what css supports.
32.
by ervine 2y ago
Oh yeah, you have to get into branded types for this I think, which means a parsing step. Fair point.
33.
by ervine 2y ago
For sure, linting is just as necessary as typescript for a sane codebase.
34.
by ervine 2y ago
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 ca
35.
by ervine 2y ago
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 domain
36.
by ervine 2y ago
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
37.
by ervine 2y ago
Not if your types represent something you don't control, like an API response.
38.
by ervine 2y ago
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.
39.
by ervine 2y ago
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
40.
by ervine 2y ago
Are you using strict mode?
41.
by ervine 2y ago
I would feel cool doing this until any sizeable DOM manipulation and then immediately remember why react was such a godsend.
42.
by ervine 2y ago
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.
43.
by ervine 2y ago
What kind of stuff do you give up with an SPA?
44.
by ervine 2y ago
Yah agreed - updating params when filtering / sorting / paginating should replace instead of push to the history stack. Easy enough to do.
45.
by ervine 2y ago
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.
46.
by ervine 2y ago
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 framewo
47.
by ervine 2y ago
next.js, apollo client... so many surprises even in minor point versions.
48.
by ervine 2y ago
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.
49.
by ervine 2y ago
Slightly-longer commits to have never-broken commits... hmmmmmm.
50.
by ervine 2y ago
One of my favorite eslint rules to enable: https://github.com/jsx-eslint/eslint-plugin-react/blob/maste...
51.
by ervine 2y ago
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 ea
52.
by ervine 2y ago
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,
53.
by ervine 2y ago
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
54.
by ervine 2y ago
Aha fully-sighted and I've never noticed this... 15 years of mac use.
55.
by ervine 2y ago
Again, it's not hard - just being devil's advocate for when toasts are useful. Less code, centralized messaging.
56.
by ervine 2y ago
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.
57.
by ervine 2y ago
Maybe bad UX, but global error / success handling of network requests is way easier than handling in every component that triggers one.
58.
by ervine 2y ago
Regardless of how you may feel about the locked down Apple ecosystem, it's pretty clear (imo) what the question meant.
59.
by ervine 2y ago
Well done.
60.
by ervine 2y ago
Lemme be an absolute pedant and say that's destructuring, not spreading. And correct me if I'm wrong, nothing worse than an incorrect pedant.

More ›