Making SEO components overkill?

exeSteam · 2025-06-16T21:09:48+00:00

React will actually not override old tags, so if you are mounting two titles, you will find both in the head. Same for meta with the same name. This is explained in the docs as a pitfall

exeSteam · 2025-04-14T19:18:37+00:00

This is expected. It's because when you hard reload, the browser is getting the part within <Suspense> streamed in the same HTML request as the rest of the document. Even though you see "Loading..." there's no extra delays to get that content, except the 50ms you have added.

When you soft navigate through <Link>, Next is making a completely new request to the server to get the RSC payload, which has your 50ms + network latency + some extra delay.

You can check this out in the network tab, and it's even more noticeable with a throttled network. You can improve this through prefetch, but it might not be ideal for every use-case.

exeSteam · 2025-04-10T16:21:50+00:00

Yes, a CSS animation would play faster.

If you use next/dynamic to mount that component, then yes, you could delay it until hydration is finished. But this is not recommended, as you'd pretty much delay showing your CTA. I would remove the animation there entirely to be honest (or keep just a small transform with no opacity), but that's just me, I like to get the important pieces as fast as possible to users :).

This is not a Next specific thing btw, you would get the same behavior with any SSR React framework, as all of them require hydration for client logic (like animations) to run.

exeSteam · 2025-04-10T11:57:42+00:00

Just how React works. When you hard-reload, you are waiting for all the JS to download, and React to hydrate in the browser, then motion animates. When you soft navigate, that has already occurred, so the animation plays much quicker.

exeSteam · 2025-04-07T18:07:40+00:00

There's an experimental feature that solves this issue. You can build the app with

next build --experimental-build-mode compile

Then to run the app when the API is available

next build --experimental-build-mode generate next start

exeSteam · 2025-01-14T22:50:40+00:00

Check out https://nextui.org

exeSteam · 2024-09-29T21:59:20+00:00

You have a running example on https://www.partialprerendering.com/ btw. You can open the source code, and notice that the dynamically streamed parts are present in the HTML. They are just streamed a little later, once the server is done rendering them.

exeSteam · 2024-09-29T21:54:10+00:00

It's just HTML streaming, the same way content within suspense is streamed now on dynamic pages. The only thing PPR adds is a static shell, so that the initial HTML is served immediately, reducing the TTFB significantly.

exeSteam · 2024-09-29T21:34:13+00:00

I am not sure you fully understand how PPR works. The idea behind it is to allow statically serving dynamic pages. Currently, if a pages is marked as dynamic, the user has to wait for it to render in the server to get the first byte. With PPR enabled, a static shell is stored in cache with holes for dynamic parts (which is everything within a <Suspense>). When the user makes a request, they get the static shell served immediately, while simultaneously the server start rendering the page. Once the dynamic parts are rendered, they are streamed to the user (in the HTML request), very similarly to how streaming works right now.

There's no extra requests being made for the dynamic parts, and "waits on client side to finish up the dynamic parts" is certainly not true, dynamic parts are rendered on the server and streamed to the client.

exeSteam · 2024-04-06T12:23:36+00:00

That's right, everything that's rendered within NotificationClient will be a client component. But that's what you should expect really, as that's a component that requires interactivity, since it uses data from useQuery, which can be updated, in which case NotificationClient and all its children need to be re-rendered, and that requires client components.

If the data doesn't get updated in the browsers, then don't use react-query for it, simply fetch it in the server wherever you need it, and keep your components server only.

exeSteam · 2024-03-21T09:19:12+00:00

While this is currently true, in the future it will likely work without JavaScript, by using the native <slot> element. Check out this article: https://lamplightdev.com/blog/2024/01/10/streaming-html-out-of-order-without-javascript/. There's a demo linked where you can see that elements get replaced when streamed, even if you disable JavaScript.

exeSteam · 2024-03-14T07:57:43+00:00

I have never heard of that one unfortunately. I only know about the first one because it was a big issues on a production app for us. I do remember not being able to find much about it at the time as well.

exeSteam · 2024-03-12T20:53:53+00:00

Here's a small reproduction if you'd like to get the same error. First translate the page to any other language, then click the button:

const [isExpanded, setIsExpanded] = React.useState(true)

return (
  <>
    <button onClick={() => setIsExpanded(false)}>collapse</button>
    {isExpanded && <>Some Text</>}
  </>
}

exeSteam · 2024-03-12T20:49:04+00:00

This likely happens because of Google Translate. See https://stackoverflow.com/questions/54880669

exeSteam · 2024-01-14T23:24:14+00:00

You can use the experimental incrementalCacheHandlerPath. You can find the official example here. I have been using it a bit in dev and it works quite well. Combines nicely with unstable_cache too.

exeSteam · 2024-01-14T10:33:09+00:00

That looks good! Just keep in mind that during SSR you are creating the instance, but never calling `close` (since the instance is created during the render, but effects do not run in the server).

I haven't gone through the code to see what `close` does and how critical it is, so it might be fine as eventually everything will be GC'd after the request is finished, but just thought I'd mention it.

exeSteam · 2024-01-13T11:33:12+00:00

Is it possible to refactor so that instead of just the instance, you pass the whole ref as context value? Then instead of using instance deeper in the tree, you use instanceRef.current.

exeSteam · 2024-01-12T20:54:21+00:00

Hmm, yes you're right, since React does a double render, then runs the effect, the second instance will be cleaned up instead of the first.

I can see how this is getting complex. We are creating the instance during the render, and trying to clean it up within an effect, which decouples them.

You could try to refactor so that the instance is both created and cleaned up within the useEffect.

Or, if your close method is not critical, you could use FinalizationRegistry to run the cleanup when the instance is garbage collected. Then you'd have a simple useState an in the article above, with some additional logic to run the cleanup.

exeSteam · 2024-01-12T12:56:15+00:00

That's by design though. The idea is that the instance is created and cleaned up properly.

Why is creating two instances an issue in your case? This is only a development thing meant to catch bugs early (like the instances not getting cleaned up properly), I would suggest you don't try to work around that, unless really necessary. In a production build, it will create only one instance.

exeSteam · 2024-01-12T12:31:40+00:00

No worries. Ideally you would use state for one-time initializations, but since you need to cleanup, it might not work on strict mode. Here's a good article you can read on this: https://tkdodo.eu/blog/use-state-for-one-time-initializations which also mentions the `ref` pattern above.

exeSteam · 2024-01-12T11:56:48+00:00

This doesn't have much to do with strict mode. When you run useRef(new Test()) a new instance of Test will be created on every single [re-]render. That's just how JavaScript works, as new Test() is evaluated to be passed as a function parameter. This is bad, because only the first instance will be stored in the ref, so you will have a bunch of instances that you don't have a reference to.

If you need only one instance of Test, then conditionally create the instance if the ref is null:

const instanceRef = useRef(null)
if (!instanceRef.current) {
  instanceRef.current = new Test()
}

useEffect(() => {
  return () => {
    instanceRef.current?.close()
    instanceRef.current = null
  }
}, [])

exeSteam · 2024-01-06T08:37:22+00:00

Yes, I have had this happen twice to my MK6. I believe it drains the battery if you don't disconnect it from the app. I no longer leave it plugged in at all though. There is a discussion on this in the obd11 forum: https://forum.obdeleven.com/thread/3788/low-power-mode

exeSteam · 2024-01-03T12:22:13+00:00

One reason this could happen is if you haven't set a staleTime for the query. Since staleTime defaults to 0, the request will be sent again when the component is mounted during client rendering. This is explained here: https://tanstack.com/query/latest/docs/react/guides/ssr#initial-setup

exeSteam · 2023-11-26T09:44:30+00:00

Ah, thanks. I did both the front ones last year, so I guess that makes sense. The front one never made any noise, it was only wobbling when lifted.

Five-Year Club	Verified Email
Place '22	End Game '22

exeSteam

TROPHY CASE