Introduction

Okay, so this is going to be a chunky article. I will have to return to it a few times because the subject matter is more a question of standards and development models than it is about actual code. I will be providing code, and doing my best to demonstrate what your code should ideally turn out to be, but the majority of what you will be learning here is concept.

Here's the thing. Conceptual stuff? Boring as shit. I'll spice it up, but seriously. This stuff is dense and you should read a little bit at a time unless you're in the zone.

But starting with this article, I'm gonna have a callout signature. This callout signature means "Just because you can, doesn't mean you should"

<aside> 😡 Don't do this example of a shitty practice that causes a lot of problems

</aside>

If you see this, and you do this, I am pointing this out because I have paid a nasty price for fixing and debugging issues that are caused by whatever practice we are talking about.

Topics

1. Differentiating component types in your application (with actually helpful information)
2. Using state libraries to do the heavy lifting (like your business logic and extras like toasts)
3. Stop using services in your fucking components (unless you're forced to)
4. Test your visuals in your components, and your business logic in a layer beneath it