Doug Parker 🕸️ / is on Nostr

Overly opinionated software developer on the Angular team at Google. Web development is hard, so I build tooling that makes it easier. I love forcing web tools to do things they were never supposed to do.

Blog: https://blog.dwac.dev/
GitHub: https://github.com/dgp1130/
Bluesky: https://bsky.app/profile/develwithoutacause.bsky.social

Last Notes

2024-08-10 21:26:20

I found myself on the #IRS website searching for non-profit charities today, and this has to be the worst possible experience for two easily fixable reasons:
1. There's apparently no keyword search? You have to search by location and then just go through the list trying to find the organization you're looking for. It's at least alphabetical, but if it's in a large city like New York you're gonna be pretty screwed.
2. Once you find what you're looking for, there's no deep link! You're still on the base search route. AFAICT, there is no way to share a link to a particular organization! Even a refresh puts you back on the main search.
These aren't even nuanced #a11y issues, it's just basic functionality. I don't know how you screw up *this* badly!
https://apps.irs.gov/app/eos/

2024-08-01 01:46:42

I always hear people state that #SSR is needed for #SEO, but I'm not convinced that's true in 2024.
#Vercel just did an investigation into this and seems to confirm my suspicions: #Google renders #CSR / #SPA apps and indexes their content just fine.
https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process
There are a few caveats for sure, and I'd love to see similar data on other search engines, but this is probably a good baseline.

2024-06-20 19:38:56

The more I think about the way whitespace rendering works in #HTML, the more convinced I am it is utterly broken.
Might be a good opportunity for a blog post? "Why your link underscores are wrong." Could describe exactly how HTML works, the ambiguity between developer-focused whitespace and user-significant whitespace, how it could have worked to avoid these problems, and what to do now that it works the way it does.

2024-06-20 18:52:28

- reply

TypeScript does not enforce the types of "return only generics" so it accepts whatever you give it. Like you mention, that's effectively a cast whether the developer knows it or not.
A recommended style I've seen is to avoid return only generics and just return `unknown` in such situations, forcing the developer to explicitly cast the result unambiguously.
The tricky part here is `| undefined` which you'd still want to enforce and would be subsumed by the `unknown`. I think you could do something like `{} | undefined` (not sure `{}` is the right type). But as soon as you require a cast you're losing the `undefined` constraint too.
```
const foo = getData('test', {noThrow: true}) as string;
// ^ Didn't handle `undefined`.
```
I think the best approach would be to return a `Result` type or discriminated union of some kind so it forces you to "unbox" the inner `unknown` by checking existence. I don't see a better way here.

2024-06-18 21:54:23

Proof by Lack of Complaint:
X is known to be true, when X being false would imply an effect sufficiently bad that someone definitely would have complained about it such that I'd know X was false.

2024-06-13 21:50:39

I'm getting real sick and tired of APIs that do nothing when things go wrong.
When you encounter an error, TELL ME!

2024-06-12 19:15:58

- reply

If the element is rendered client side, then yes I agree it should be render blocking. `<some-comp></some-comp>` isn't meaningful to the user until it is rendered.
However from a strictly progressive enhancement perspective, I'd argue that the element should either:
1. Be server-side rendered such that it doesn't need to block on the CE definition.
2. Not be added to the page until the resources to render it have been loaded (you're breaking rendering for other things on the page).
You could do 2. with a `<script async>` which adds the element after defining it though this can be unergonomic.
Maybe improving the tooling and capabilities on that side might be more in line with PE ideals and avoid render blocking resources?

2024-06-10 17:49:10

If a `computed` dependency updates and no `effect` is subscribed to it, does it `new Audio('tree-falling.wav').play()`?
#Signals #Web #Angular

2024-06-09 17:07:12

The terms "source" and "sink" are clear about their intention when describing data flows, but every so slightly incorrect in plumbing terms. We should prefer "faucet" and "drain" to maximize overlap between software development and plumbing.
In this essay, I will...

2024-06-09 05:23:19

I had been hoping to spend some time this weekend on #HydroActive, but #Akuma is just too much fun right now.
#StreetFighter #StreetFighter6

2024-06-08 15:49:14

- reply

True, but I don't see a whole lot of concurrency in tests. And if the initialization can be parallelized, most likely the clean up can too.

2024-06-08 01:25:18

#JavaScript #Testing #Idea: Instead of manually managing `beforeEach` and `afterEach` in #Jest / #Jasmine / etc., what if we had a way to register a "run this on test cleanup" callback at any time? Kind of like how `defer` in #Go will automatically clean up a resource at the end of a function.
```javascript
it('does a thing', () => {
const thing = createAThing();
useTheThing(thing);
});
function createAThing() {
const thing = makeThing();
jasmine.afterThisTest(() => thing.cleanup());
return thing;
}
```
This feels much more ergonomic and allows you to create resources without messing up your scoping with `beforeEach` / `afterEach`.
Has anyone tried this? I don't think I've seen this pattern in a JS testing context.