Today I Learned

Footnotes and highlights of things I learned everyday.

• 2024-08-25
  • react
  • nextjs

  In the Next.js App Router, error boundaries can be defined as files with the naming convention error.js or error.tsx. These files receive a reset prop, which allows re-rendering the component to remove the error fallback page. However, when using reset on a server component, the component won’t reset. This behavior is expected because server components do not re-render in the same way as client components. Instead, you need to use router.refresh() to reload the server component and then call reset() to re-render and remove the error boundary.

  The gotcha is that invoking these functions together won’t necessarily remove the error boundary, even though the actions are technically correct. This issue arises because router.refresh() might not have completed yet (especially if it involves data fetching from the server), causing reset() to be called on outdated data. Since router.refresh() is a synchronous operation, it doesn’t allow for await. In this case, startTransition can help by allowing React to handle the update based on when each action completes.

  function recover() {
    startTransition(() => {
      router.refresh();
      reset();
    });
  }

• 2024-07-19
  • HTTP
  • API

  I'm creating a dummy API for personal development needs using Elysia. When on localhost, everything runs smoothly. However, when it has been deployed to production, requests to the API endpoint do not embed a cookie containing a token in the request headers. Even though I have used the credentials: "include" configuration. It turned out that the problem was in the cookie configuration on the server, which forgot to provide the flag secure: true. Here is my final configuration:

  accessToken.set({
  	value: accessJWTToken,
  	httpOnly: true,
  	maxAge: ACCESS_TOKEN_EXP,
  	path: "/",
  	sameSite: "none",
  	secure: true, // should exist
  })

  For security, if a request is executed to a different origin, without secure: true, the browser will refuse to embed cookies in the request headers.

• 2024-07-15
  • JS
  • react

  Careless use of useCallback can result in memory leak in the application. In the past, if I'm not mistaken, I've read about premature optimization, which is an optimization at components that don't re-render too often or not having a heavy task. In fact, memoization requires separate memory allocation which is not worth it if used to remember simple values or functions.

  I found a good article about memoization with useCallback, coupled with closure in Javascript, can actually cause memory leaks. Read here.

• 2024-07-13
  • JS

  It turns out that let and const are hoisted by Javascript. However, both have a temporal death zone restriction, which causes ReferenceError to appear when used before a declaration, read this article for more details.

• 2024-07-02
  • JS

  At my last company, I created a swipeable carousel. At that time, I handled both touch and mouse events separately. It turns out there is a PointerEvent that handles both, and it's been around since 2015, lol.

• 2024-06-24
  • programming

  Duplication is far cheaper than the wrong abstraction.

  Switch statement or conditional is for business logic not configuration

  Both quotes above are from Sandi Metz's speech, All the little things, which discusses the importance of using small methods and warns about the careless application of DRY principles that can lead to disaster. Highly recommended to watch!

• 2024-05-02
  • react
  • nextjs

  Next js whether its client or server component is rendered on the server and send static html preview. “use client” is often easier to understand if you think of it more as “use hydrate”