DEV Community

piratematt
piratematt

Posted on

Last Month's Reading 24/01 – January 2024

Last Month's Reading; a non-exhaustive list.

Early Month

  • The True Purpose of Testing by Artem Zakharchenko
    • "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 by Thomas Broyer
    • 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 by Niall Maher

    • 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 👇🏻
      export async function findRecordsForOptions () { /* ... */ }
      export type RecordOptions = Awaited<ReturnType<typeof findRecordsForOptions>>
    
    • Short, sweet, and to the point. Love it!
  • New Client Data docs section by Remix

    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 by Nir Ben-Yair
    • 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 by 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

Top comments (0)