Kent C. Dodds

Worth noting that in my experience it's the combination of MSW and code generated from an OpenAPI spec that really makes it special, not just MSW alone.

The other reply covers it but I want to slice it slightly differently. I see two things that are different here. One is mocking at the HTTP boundary rather than mocking, e.g., function return values or modules or whatever. That's certainly not revolutionary (I know people do it with rspec and I'm sure plenty of test frameworks do it too), and in theory you could build your mock server with any tool that lets you build a server. But people don't usually do this, and when they do they tend to do it bit by bit for each test rather than thinking about it as mocking the entire API. So for example, in my mock API, my POST creating a project actually creates a project in a mock database, and then when I list projects, I can see what I just created. So I can test the UI by doing exactly what you would do manually — create the thing and see that it shows up where it's supposed to. All of that is built independently of my test for that feature, and it works for all the tests I write — I don't have to think about mocking API bits for a particular test.

Worth a read: https://kentcdodds.com/blog/stop-mocking-fetch

The other thing that's unusual is running this mock in a Service Worker, which means it can run in the browser. That's pretty cool and pretty unique to this tool. But the Mock part is about running the same server outside of…

Seems like most of the issues here are caused by an incomplete understanding of how React rendering actually works.

That's why I wrote an incredibly extensive article on this: "A (Mostly) Complete Guide to React Rendering Behavior". I'd strongly recommend reading through that to help internalize what React is doing and how re-rendering works:

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/

In general: yes, *React re-renders recursively by default*. Also: yeah, _no_ web app will update as efficiently as a 3D game engine, because it's under completely different technical constraints. On the other hand, web apps are also a completely different _kind_ of application than a 3D game as well, and the DOM is a different display environment than rendering 3D models and executing physics logic.

Also, the article said:

> I would like to acknowledge that there should be “some” overhead from using the development build, but I wouldn’t expect turning on production mode would have a substantial impact on this example.

There _is_ actually significant difference between dev and prod build performance. By default, profiling only works against development builds, but there's two ways you can try measuring the render time of a production build:

- Alert your build setup to alias "react-dom" to the special profiling build, which is a production-like build that still has the profiling logic enabled, then use the React…

Without fail, every article from Kent C. Dodds shows what appears to be total inexperience despite claims of the contrary.

The advice is, at this point, almost meme worthy. There's an infamous post from 2021 (that he may have been roasted for here):

https://kentcdodds.com/blog/how-i-built-a-modern-website-in-2021

Almost every single piece of advice is wildly overcomplicated and ridiculous.

I do like some of the technologies proposed, but you can host this stuff on a single VM without any of the fancy frameworks, tools, or hosting options.

Kent is the only blogger that I've felt compelled to tell all my less experienced colleagues to completely ignore, and I feel entirely justified doing so whenever they bring him up.

The proliferation of his perspective has, quite literally, been a pain in my ass daily trying to re-teach misguided fundamentals. I really don't understand who the intended audience is. The expert beginner, maybe?

I'm sure he's probably a wonderful human being, however.

React is easy, once you understand why

{} !== {}

and that it uses reference equality as a proxy for value equality.

This is why the absolute simplest thing to do is to just memoize all the things (see https://attardi.org/why-we-memo-all-the-things/ for a deeper dive into this approach).

I know that the conventional wisdom (e.g. https://kentcdodds.com/blog/usememo-and-usecallback) is not to do that, but it's worth noting that Kent doesn't actually bring receipts for his claims, and also the discussion is typically limited to toy examples, not huge applications that have the potential for huge cascading renders when anything changes. In my own profiling of real world applications I have found that memoizing everything is not actually a performance regression. And then also consider the React Compiler, which of course does the same, at an even more fine-grained level than any human could be bothered to consistently do by hand.

Coverage is the best example of Goodhart's Law, never focus on it.

Integration tests are typically best bang for buck: https://kentcdodds.com/blog/write-tests

Once manual testing starts causing noticeable pain, you can start automating some of it. This may very well be beyond $10-100M in valuation.

A lot of people say unit tests give them confidence, but that's a delusion. Losing confidence in your code means you have outgrown your architecture. However, you can temporarily address it with more tests, because addressing architecture issues takes some time. The secret is to write as little tests as possible to bring confidence back to acceptable level.

Don't spend more than 10% time on tests.

Don't let junior engineers write tests.

Seconded.

There was a series of similar Twitter discussions when a popular JavaScript "influencer" published an article[0] on how they built their website. The amount of complexity that is self-inflicted in the said article was obviously enormous for proponents of MPAs.

However the JS community mostly echoed that the complexity was absolutely within norm. The cultural chasm between JS developers and people who push for simplicity was huge. And the refusal to admit the unnecessary complexity was nothing short of Stockholm Syndrome, imho.

[0] https://kentcdodds.com/blog/how-i-built-a-modern-website-in-2021

This was the HN reaction to the article:

https://news.ycombinator.com/item?id=28818829