tablelandnetwork / studio

Discover, design, deploy, and manage data driven web3 apps on Tableland.
https://studio.tableland.xyz
4 stars 1 forks source link

Joe/web fix 822 #226

Closed joewagner closed 6 months ago

joewagner commented 6 months ago

fixes: https://linear.app/tableland/issue/ENG-822/rendering-time-in-a-use-client-component-results-in-the-rendered fixes: https://linear.app/tableland/issue/ENG-832/i-should-be-able-to-go-to-deployments-page-from-blueprint-page-even-if

linear[bot] commented 6 months ago

ENG-822 Rendering time in a "use client" component results in the rendered content differing between the client and server.

railway-app[bot] commented 6 months ago

This PR was not deployed automatically as @joewagner does not have access to the Railway project.

In order to get automatic PR deploys, please add @joewagner to your team on Railway.

joewagner commented 6 months ago

I'm not sure about this. My understanding of the import server-only and import client-only is that they provide build time errors if you import a server-only component into a "use client"; component and vice versa. So according to that logic, this PR should have build problems because you're importing a client-only component into many server components now. This is documented at https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment.

I read these docs, and the section that inspired what I have in this PR is here: (screen shot since I can't link to the specific part) Screen Shot 2024-03-19 at 3 13 04 PM

I simply combined the "use client" and "client-only" directives into a single file, where the docs don't show you the component code.

I would have imagined the right tool for this is dynamic (https://nextjs.org/docs/pages/building-your-application/optimizing/lazy-loading).

The dynamic approach, a.k.a lazy loading, sounds good at first glance. I couldn't figure out if it being dynamic meant it was always rendered on the client only, or if it was simply only rendered when needed.
For example, if you look at the network tab while using the site you'll see occasional requests for chunked up js. Next doesn't really let you see what these requests are. I assume they some how split up to optimize the perceived site performance, but I couldn't find a way to test and I wasn't sure after reading the docs

Definitely a lot of unknowns here on my end, so let's keep discussing this.

I'm also not super confident about the client-only part of this. The bug in question is rare, and at worst it just falls back to rendering on the client. Which is slow, but still works.

linear[bot] commented 6 months ago

ENG-832 I should be able to go to deployments page from blueprint page even if there are not any deployments yet.

asutula commented 6 months ago

@joewagner I watched a great video last night that touches on the client hydration error thing: https://www.youtube.com/watch?v=iA8JR8GgTKs.

The big take away from that video is to understand that "use client" components are rendered initially on the server, but then are hydrated on the client with javascript to make them interactive. It is that server rendered html and client rendered html that have to match.

Sounds like a fix that makes a lot of sense is to use useEffect to set/display the time string. This assures that the time string won't be rendered on the server.

vercel[bot] commented 6 months ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Mar 29, 2024 11:35pm