Last Month's Reading 24/01 – January 2024
Tags: readinglist, reading, monthly
Published: 2024-02-07 01:46:44

_Last Month's Reading; a non-exhaustive list._

## Early Month

* [The True Purpose of Testing](https://www.epicweb.dev/the-true-purpose-of-testing) by [Artem Zakharchenko](https://kettanaito.com/)  
  * "A test _becomes_ useful when it fulfills its purpose."
  * "It is only when a test validates the intention that it becomes useful."
  * Argues against tests validating _how_ and for tests validating _intention_.
  * Potential counter thought: encapsulation often leads to tests validating how. These aren't inherently bad, asserting your building blocks behave as expected is good. This deserves more pondering.
  * "That's what the automated tests are for." <— Oh, so we're talking about a specific type of test.
  * I'd love to read an experienced TDD-er's take on this.
* [Beyond the login page](https://dev.to/tbroyer/beyond-the-login-page-4hjd) by [Thomas Broyer](https://blog.ltgt.net/)
  * A list of questions to think about/tackle when developing authentication.
  * I love how well this shows the complexity that often hides behind simplicity.
  * "I don't think I ever implemented **all** of the above _perfectly_. There are always tradeoffs. But these are things to think about and make choices"
  * He points out that this is _only_ authentication, not authorization. There's just _a lot_ to think about here.
* [Get the Return Type from a Promise in TypeScript](https://www.codu.co/articles/get-the-return-type-from-a-promise-in-typescript-m-eoui59) by [Niall Maher](https://www.codu.co/niall)
  * I have accessor methods responsible for direct DB access. Several of these are grabbing configured (via the DB) options that power selects for other records. When I passed them to my "select" components I was manually typing them. This felt wrong.
  * I quick bit of web sleuthing later, thanks to Niall I had what I need 👇🏻
      ```typescript
      export async function findRecordsForOptions () { /* ... */ }
      export type RecordOptions = Awaited<ReturnType<typeof findRecordsForOptions>>
      ```
  * Short, sweet, and to the point. Love it!
* [New _Client Data_ docs section](https://remix.run/docs/en/main/guides/client-data?ck_subscriber_id=2210458388) by [Remix](https://remix.run/)
    ```typescript
    export async function loader({ request }: LoaderFunctionArgs) { /* ... */ }
    
    export async function clientLoader({ request, serverLoader }: ClientLoaderFunctionArgs) { /* ... */ }
    
    export function HydrateFallback() { /* ... */ }


    export default function Component() {
      // This will always be the combined set of server + client data
      const data = useLoaderData();
      return <>...</>;
    }
    ```
  * "a bit of a sharp knife" – use wisely and cautiously
  * Opt-in functionality

## Mid – Late Month

* [Headless components in React and why I stopped using a UI library for our design system](https://medium.com/@nirbenyair/headless-components-in-react-and-why-i-stopped-using-ui-libraries-a8208197c268) by [Nir Ben-Yair](https://medium.com/@nirbenyair/about)
  * Requirements: Accessibility, Theming, Uniqueness, Browser support, Functionality, Responsiveness, and Maintainability.
  * UI Libraries are great, but also inevitably fail you when you start to get complex.
  * Short version... Headless can help by being "well tested on multiple browsers, platforms, and devices and deal[ing] with edge cases that I never could or want to deal with myself: stuff like focus management, keyboard navigation, event listeners, accessibility attributes, valid markup and screen reader support"
  * _I really like the way this seems to be abstracting away the hard details to the communal effort of Open Source but leaving "the work" to the developer's intention. Need to spend some more time digging in here._
* [The Golden Rule of Assertions](https://www.epicweb.dev/the-golden-rule-of-assertions) by [Artem Zakharchenko](https://www.epicweb.dev/authors/artem-zakharchenko)
  * Yes this is the second one from them this month. I suspect the future will bring more.
  * Don't test _how_ (implementation), test _"the intention behind the system"_.
  * Not... "has been called with". Instead try... "result is as expected".
  * There is definitely a time and a place to test implementation. Maybe they don't live in your test suite forever, but if they help you develop working software faster... write them.

## Skims and Honorable Mentions

* [Bytes #252 Your Weekly Dose of JS](https://bytes.dev/archives/252) newsletter from `tyler@ui.dev`.
* [Books That Helped Me Become a Tech Lead](https://dev.to/frosnerd/books-that-helped-me-become-a-tech-lead-3831) by [Frank Rosner](https://dev.to/frosnerd) – definitely going to have to come back to this one.
* [🔐 Session-Based vs. Token-Based Authentication: Which is better?🤔](https://dev.to/fidalmathew/session-based-vs-token-based-authentication-which-is-better-227o) by [Fidal Mathew](https://fidal-portfolio.vercel.app/) – Skimming and perusing the comments led me to _Beyond the login page_ mentioned above.
* [dev.to Meme Monday](https://dev.to/ben/meme-monday-5h8i) – ah programming humor.
* [Bytes #258 Better off Zed](https://bytes.dev/archives/258) – Open source, faster than VS Code from the creators of Atom? I'm listening...