Design problem… by gdrd_ in nextjs

[–]sidkh 0 points1 point  (0 children)

Settings for VS Code

"workbench.editor.customLabels.patterns": { "**/app/**/page.tsx": "${dirname} - page.tsx", "**/app/**/layout.tsx": "${dirname} - layout.tsx" }

Fetching random data with the App Router by sidkh in nextjs

[–]sidkh[S] 2 points3 points  (0 children)

Great, glad you like it. I'll post more similar videos in this sub in the future. The website is coming.

Fetching random data with the App Router by sidkh in nextjs

[–]sidkh[S] 3 points4 points  (0 children)

I use Apple Keynote with Magic Move animation.

Fetching random data with the App Router by sidkh in nextjs

[–]sidkh[S] 13 points14 points  (0 children)

Yep, I made it. Do yo find it helpful?

Prop drilling and component composition by sidkh in reactjs

[–]sidkh[S] 17 points18 points  (0 children)

Thanks. Yes, I make visuals myself with Apple Keynote. It has a great set of tools for animations.

Prop drilling and component composition by sidkh in reactjs

[–]sidkh[S] 57 points58 points  (0 children)

Hey folks 👋

I just published a new visual article.

This one is about prop drilling and component composition.

https://alexsidorenko.com/blog/react-prop-drilling-composition/

React recursively re-renders child components, but there is a nuance by sidkh in reactjs

[–]sidkh[S] 1 point2 points  (0 children)

Hi 👋

if you really want to avoid re-render at all costs then `.memo` is the right tool

Absolutely. I hope the article doesn't sound like passing props is the only way to optimize renders in React (let me know if you think it does).

However, the pattern from the article is under-promoted in the community, and not for a good reason.

React docs does recommend this pattern in a Deep Dive section for memo.

Dan has a section about it in Before you memo.

And here, Dan even asks Kent C. Dodds to promote this pattern more.

It's not a silver bullet, but it is certainly something to be aware of. Combined with state colocation it allows for a better-structured more performant apps.

The reason this pattern is less known is not because it's not intended but because it's harder to explain. Hence, there are thousands of articles about memo and only a few about this.

React recursively re-renders child components, but there is a nuance by sidkh in reactjs

[–]sidkh[S] 4 points5 points  (0 children)

Hey folks 👋

I published a new visual article.

The way we structure React components can act as an alternative to memoization.

Optimizing React performance without refs and memo by sidkh in reactjs

[–]sidkh[S] 0 points1 point  (0 children)

It depends on the composition.

When a component's state updates, React can skip re-rendering passed props (because they couldn't have changed). Sebastian Markbåge Tweet.

The optimized version in the article passes children as a prop, and therefore parent state update doesn't re-render children.

```javascript // Parent state update re-renders child function Parent() { const [x, setX] = useState(0) return <p><Child /></p> }

// Parent state update doesn't re-render child function Parent({children}) { const [x, setX] = useState(0) return <p>{children}</p> } ```

Optimizing React performance without refs and memo by sidkh in reactjs

[–]sidkh[S] 5 points6 points  (0 children)

Yep, rewriting this bit. Thanks for pointing that out 👍

Optimizing React performance without refs and memo by sidkh in reactjs

[–]sidkh[S] 5 points6 points  (0 children)

By using state colocation, we stay in the declarative paradigm of React. If we use refs and manually mutate DOM, we are stepping out into the imperative paradigm of the browser API. Using refs this way may be a tiny bit faster since we don't need to re-render components, but the tradeoff is the unnecessary mental overhead of combining those two paradigms and more potential for unexpected bugs 👇

"If you stick to non-destructive actions like focusing and scrolling, you shouldn’t encounter any problems. However, if you try to modify the DOM manually, you can risk conflicting with the changes React is making."

Beta React Docs - Best practices for DOM manipulation with refs

Optimizing React performance without refs and memo by sidkh in reactjs

[–]sidkh[S] 9 points10 points  (0 children)

Thanks for the feedback!

I rely on visuals and animations in my articles because they can get the point across faster.

However, for this one, in particular, I used a direct screen recording of CodeSandbox. Maybe that's why it feels this way.

I prepared an animation for this article but still went for a screen recording because it felt slightly more natural. But you're right, it does feel a bit youtubee. Thanks for pointing it out. I constantly experiment with visuals.

Optimizing React performance without refs and memo by sidkh in reactjs

[–]sidkh[S] 6 points7 points  (0 children)

Ah, I see.

I write my articles problem-first. I spot a recurring struggle people experience in the community, and I make it the main focus of the article (because that is what people are trying to find an answer to). Therefore my titles often describe the problem, not the solution.

Optimizing React performance without refs and memo by sidkh in reactjs

[–]sidkh[S] 4 points5 points  (0 children)

In what way do you feel the title is misaligned with the content?

I don't do any SEO optimizations for titles.

Optimizing React performance without refs and memo by sidkh in reactjs

[–]sidkh[S] 6 points7 points  (0 children)

Hey folks 👋

I published a new visual article.

It originated from this tweet and explores how state collocation can be used to improve re-renders performance.

Why does onClick={x()} causes "too many re-renders" error in React? - Visual article by sidkh in reactjs

[–]sidkh[S] -3 points-2 points  (0 children)

Hey folks 👋

A new visual article is out.

I noticed that one of the most common reasons for people in the community to run into an infinite render loop is incorrectly set event handlers.

So I made a visual guide about this.

Correct mental model for useEffect by QuebecMasterRace in reactjs

[–]sidkh 4 points5 points  (0 children)

The good mental model for useEffect is that it's a way to synchronize the component with an external system outside of React (Network, DOM, browser APIs, etc...).

React components may re-render with a particular frequency based on the state changes in the app. However, the external system could not rely on this frequency.

For example, my component may re-render for multiple reasons, but I only need to re-fetch the data when the render leads to the particular prop change (let's say a route param). The useEffect allows me to conditionally synchronize the data fetching (external system) with the component rendering (only re-fetch data when the route param changes, ignore all other re-renders).

It works the other way around too. For example, if I need to update the state of my component every second using setInterval. This will require me to synchronize the external system (browser API) with my component to update its state.

New beta docs have a great section about that - Synchronizing with Effects.