denniskats.dev
Web Engineer at Deckers Brands. Previously at Meta, Blueport Commerce, and Carbonite.
I like to share things that stimulate my brain cells. He/Him.
denniskats.dev
29 posts
63 followers
182 following
Active Commenter
comment in response to
post
I think it works with plain JS too, but regardless it requires an IDE with TS integration. No clue if it works in other flavors of JS though, so having it as a feature of the language would still be nice
comment in response to
post
Far from a perfect solution, but you can exclude modules from auto-importing via JS/TS preferences. Then “friends” are just modules where you manually import the “internal” modules. www.typescriptlang.org/docs/handboo...
comment in response to
post
It basically works how it would as a switch statement, but in a declarative and "lazy" way to support SSR.
comment in response to
post
Device width isn't fluid, but we wanted to support going between orientations or resizing the browser window without losing state or jarring the user. The idiomatic fix is to "lift shared state up" (and occasionally we still have to), but it's nice that sometimes we don't.
comment in response to
post
For us, it’s not so much that the mobile and desktop UIs look substantially different, but that the data and props passed to subcomponents may differ. Below is an example of the API. We wanted it so that switching between mobile and desktop did not remount the “Card” or “NeedHelp” components.
comment in response to
post
I’m unable to send you a DM for some reason, but I’m potentially interested. Could you DM me more about the role?
comment in response to
post
Same energy
comment in response to
post
I once had to implement a “Breakpoints” component which would render different UI trees for different screen sizes. Supporting RSC and SSR was already a hassle, but tricking the reconciler to preserve state across screen sizes required just about every piece of forbidden React knowledge I have.
comment in response to
post
I think if prop.wrap changes between renders, then children will be rendered in a different in spot in the virtual DOM, which will cause the reconciler to remount them all and reset their state?
comment in response to
post
Not sure if it’s a prevalent myth, but that server functions can’t be used to fetch data. I guess the caveat is that it should only be done in a user initiated action. bsky.app/profile/denn...
comment in response to
post
I really liked "Functional HTML" because I felt that it tied all the previous RSC articles together. After reading it, I felt like I had seen the whole picture for the first time. So I don't mind the repetition; often it takes the right phrasing or example for something to resonate.
comment in response to
post
It would be interesting to read about which tradeoffs React considered and why it ultimately chose the ones it did. I feel like useTransition and useDeferredValue still aren’t well understood by the community, but maybe some background would help
comment in response to
post
I have been thinking about this a lot since I’ve started encountering this attitude at work. Though the way I usually hear it manifest is “why has React become so complicated”. I think once people just reach a certain point in their careers, they’re less inclined to learn new things
comment in response to
post
But fetching data without mutation can be valid too, right? I had a use case where I wanted to stream the result of additional products in a grid after a user clicks “load more”. I don’t think Next route handlers support RSC, so I chose to fetch and return an array of promises in a server function
comment in response to
post
I think he’s talking about this
nextjs.org/docs/app/api...
comment in response to
post
I got my ternary and conditional type syntax confused 😆
comment in response to
post
I did mean `instanceof` 😅
comment in response to
post
I believe so!
comment in response to
post
It's gotten particularly useful in React 19 for making a component compatible with both upfront data and streaming.
comment in response to
post
One of my go-to type definitions in a project is `type MaybePromise<T> = T | Promise<T>`. This fact ensures that `await maybePromiseValue` always returns a `T`.
comment in response to
post
It doesn't entirely ignore the await. JavaScript will implicitly wrap the value in a fulfilled Promise and pause execution until the next tick.
comment in response to
post
Darn. I was hoping they would be more dynamic than nth child selectors and mirror “visual siblings”. But I guess that’s probably not a super common need
comment in response to
post
Will these functions have a special behavior for `display: contents` and `display: none`? I feel like they should count descendant boxes if the element doesn't generate one.
comment in response to
post
But strictly speaking, there's still probably a hydration error occurring if it ends up correcting itself.
comment in response to
post
It logs a hydration error in React 19 with Next 15.1.4, but not in React 18 with Next 14.2.23. So my next best guess is that it's an oversight in an older version of one of those, where something about wrapping it in Suspense swallows the error.
comment in response to
post
My guess is that this component is a server component (i.e. it doesn't contain "use client" and it's not imported by another client component), and so React will only serve its raw HTML and skip hydrating it entirely
comment in response to
post
Fun fact: lazy values can form a monad if you also add `map()` and `flatMap()` methods, which are convenient if you have complex conditional logic for how a lazy value is used. There's a great article on it by Mark Seemann: blog.ploeh.dk/2022/05/30/t...
comment in response to
post
While overwriting the property removes the overhead of a getter, I suspect there is an engine-level de-optimization when modifying the shape of an object in this way. I have found that using a class with a backing field is more performant across all browsers: jsbm.dev/J283rl8OR9Fem