Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hydration not updating DOM of img-src and v-html with new client-side values #9033

Open
codeflorist opened this issue Aug 24, 2023 · 2 comments · May be fixed by #9083
Open

Hydration not updating DOM of img-src and v-html with new client-side values #9033

codeflorist opened this issue Aug 24, 2023 · 2 comments · May be fixed by #9083
Labels
🐞 bug Something isn't working scope: ssr

Comments

@codeflorist
Copy link

Vue version

3.3.4

Link to minimal reproduction

https://stackblitz.com/edit/github-vxyebj-admpj8?file=src%2FApp.vue

Steps to reproduce

i was stumbling on problems with certain stuff not getting updated to new values after hydration using pregenerated sites with Nuxt 3. (see issue with reproduction here: nuxt/nuxt#22784)

after looking at it, Daniel concluded, it was a a vue-related problem, visible in the reproduction provided in this here issue. here is the code:

<script setup>
import { ref, computed } from 'vue';
const timestamp = ref();
timestamp.value = Date.now();
const imgSrc = computed(
  () => `https://dummyimage.com/600x400/000/fff&text=${timestamp.value}`
);
</script>

<template>
  <div>
    These values should all be equal:<br />
    {{ timestamp }}
    <div v-html="timestamp" />
    <img :src="imgSrc" />
  </div>
</template>

What is expected?

That the contents of the img src attribute and v-html get updated with the new value of the timestamp ref after hydration.

What is actually happening?

The server-generated img src attribute and v-html stay the same - not getting updated to the new value.

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.20.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.2 - /usr/local/bin/npm
    pnpm: 8.6.10 - /usr/local/bin/pnpm
  npmPackages:
    vue: ^3.3.4 => 3.3.4

Any additional comments?

No response

@LinusBorg
Copy link
Member

The issue title is a bit misleading. The values don't change after hydration - rather, there's a hydration mismatch because the SSR state that's reflected in the server's HTML was different from the client-side state when hydration is being performed.

So the problem here is that during hydration, when when the mismatch is found, the render does not update the DOM with the client-side values.

@xak2000
Copy link

xak2000 commented Jan 23, 2025

I think with the introduce of data-allow-mismatch feature this problem becomes more important because data-allow-mismatch="class" "legalizes" hydration mistmatch, if it was intended.

But because of this issue it is still not possible to intentially have hydration mistmatch, if the mismatched value is happened to be an attribute. This makes data-allow-mismatch="class" not very useful feature, doesn't it?

Vue even explicitly says "The DOM will not be rectified" in the console's warning message:

  • rendered on server: class="flex-none w-16 h-16"
  • expected on client: class="flex-none w-32 h-32"
    Note: this mismatch is check-only. The DOM will not be rectified in production due to performance overhead.
    You should fix the source of the mismatch.

I think this phrase means that the DOM will be kept in the server-rendered state (so, mismatched attributes during the hydration will be ignored). Am I right or I understand this warning message incorrectly?

So, I wonder what is the purpose of data-allow-mismatch="class" if hydration process will not fix the mismatch? If this is not officially supported (and there are no plans to add it), then maybe it's worth to mention this in the description of data-allow-mismatch feature..

Context:

In my case, the mismatch happens because server doesn't know the screen size, so server can't decide what size it should set for a rendered image. Only client knows it. So, server uses the default size, but then client properly uses useBreakpoints from VueUse library to determine the desired image size.

I think this problem can be solved without introducing a hydration mistmatch (e.g. using onMounted to update the value). The layout will be jumpy, but this problem cannot be solved with hydration mistmatch anyway, so it is out of the question. But data-allow-mismatch feature would allow me to reduce the code like this:

const breakpoints = useBreakpoints(breakpointsTailwind)
const imageSize = ref<'md' | 'lg'>('md')
onMounted(() => {
  const unwatch = watchEffect(() => {
    imageSize.value = breakpoints.sm.value ? 'lg' : 'md'
  })
  onUnmounted(() => unwatch())
})

To this:

const breakpoints = useBreakpoints(breakpointsTailwind)
const imageSize = computed(() => (breakpoints.sm.value ? 'lg' : 'md'))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working scope: ssr
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants