Events before Client Side Hydration

[aralroca]

Recently I detected a problem using React in SSR. Maybe is quite obvious, but all the JavaScript events that are fired before the JavaScript is loaded, are lost...

This is something normal. The JS is not there yet... Ok. However, I expect to have some utility to do some exceptions.

I'm going to try to explain my case:

I'm using an image, and in the event onError, I want to change the src to render a fallback image.

function Img(props) {
  return (
    <img {...props} onError={e => { e.target.src = fallbackSrc } } />
  )
}

Nevertheless, this code loaded from SSR, is working "sometimes"... I guess that this "sometimes" is because if the event is fired before the client side hydration. Is not catched by my JS. And the e => e.target.src = fallbackSrc is never executed. However, if the JS is loaded faster than the onError event, is catched, and is rendering the fallback image as I expected.

I want to propose some utility to do sometimes some exceptions, and render the JS inline on the first render. Perhaps, adding some extra config in ReactDOM.hydrate? I dunno...

Or maybe someone can help me providing any tip in order to fix this?

[aralroca]

Maybe a similar alternative as dangerouslySetInnerHTML but for attachIsolatedEvents...?

<img
 {...props} 
 attachIsolatedEvents={{ 
   onError: e => { e.target.src = fallbackSrc },
 }}
/>

[zjffun]

Is it helpful to use lazy load images?

[zjffun]

Check the image then set it to src.

[aralroca]

I don't have any problem with the lazy images. I'm using lazy images almost everywhere. However, in some main parts I want to load these images early as possible (in the SSR), to be rendered at the first moment.

[zjffun]

Uh... I don't know much about SRR, can the server side check the correctness of the image URL？

[aralroca]

@1010543618 I thought this as an option. But I dunno if It is possible.

[kunukn]

I believe you are right about what happens.

Nevertheless, this code loaded from SSR, is working "sometimes"... I guess that this "sometimes" is because if the event is fired before the client side hydration. Is not catched by my JS

From this issue #12641

If that content finishes loading before ReactDOM hydrates, then the native onload event fires before React has connected any listeners to the element

There seems to be a racing condition between when hydration happens and when the browser throws the error event. If the browser already has thrown the error, I am not sure how a hydration config can help. Seems complicated, but I could be wrong.

Or maybe someone can help me providing any tip in order to fix this?

You could use ReactDOM.render instead of ReactDOM.hydrate. (I am not SSR expert, I might be wrong).

Or you could avoid onError event and make your own validation

Here is a quick rough prototype, (might need adjustments, I am not a hooks expert either )

function isImageValid(src) {
  let promise = new Promise(resolve => {
    let img = document.createElement("img");
    img.onerror = () => resolve(false);
    img.onload = () => resolve(true);
    img.src = src;
  });

  return promise;
}

function Img({ src, fallbackSrc, ...rest }) {
  const imgEl = React.useRef(null);
  React.useEffect(
    () => {
      isImageValid(src).then(isValid => {
        if (!isValid) {
          imgEl.current.src = fallbackSrc;
        }
      });
    },
    [src]
  );

  return <img {...rest} ref={imgEl} src={src} />;
}

// Render usage

<Img
  alt='some image'
  src="https://dummyimage.com/600x400/000/fff"
  fallbackSrc="https://dummyimage.com/600x400/000/f00"
/>

Try removing the src property and the fallback should be applied.

[aralroca]

@kunukn thanks for your answer.

Currently I did a workaround to fix these two scenarios:

1. When the image fails after hydration (onError event). Adding the fallback image after hydration.
2. When image fails before hydration (useEffect). Adding the fallback image after hydration.

However, the second scenario for me is not ideal because is adding the fallback image after hydration, and not before. So if the image is broken, first is loading the broken status of the browser, and then the fallback image.

This is my code:

Custom hook:

export default function useFallbackImageInSSR(fallbackSrc) {
  const ref = useRef(null)

  /**
   * Error happened / catched after hydration
   */
  const onError = useCallback(
    e => { e.target.src = fallbackSrc }, [fallbackSrc],
  )

  /**
   * Error happened before hydration, but catched after hydration
   */
  useEffect(() => {
    if (ref && ref.current) {
      const { complete, naturalHeight } = ref.current
      const errorLoadingImgBeforeHydration = complete && naturalHeight === 0

      if (errorLoadingImgBeforeHydration) {
        ref.current.src = fallbackSrc
      }
    }
  }, [fallbackSrc])

  return {
    ref,
    onError,
  }
}

Usage:

const fallbackImageProps = useFallbackImageInSSR('/images/no-image.jpg')

return (
  <img 
    alt="Example"
    src="/images/non-existent-image.jpg"
    {...fallbackImageProps}
  />
)

But again. This works, but is not 100% ideal.

So I guess, that the only way to do it ideal (adding the fallback image before the hydration), is attaching the event before hydration (as exception)... Maybe I'm wrong, but is the only way that I see to fix this 😕

[kunukn]

Here's is one more approach/strategy.

When I see this code

function Img(props) {
  return (
    <img {...props} onError={e => { e.target.src = fallbackSrc } } />
  )
}

It looks like we want to render the fallback image as fast as possible. As the browser parses the server-side rendered html, downloads the img, founds out it can't be rendered, applies the onerror event and sets the src to a fallback image. I believe this is faster than parsing the JS, then apply the same logic.

.
Here is a html version example with inline script.

<img src="imagenotfound.gif" alt="Image not found" 
  onerror="this.onerror=null;this.src='imagefound.gif';" />

This is from
https://stackoverflow.com/a/9891041/815507

But you can't use the native onerror on the img element in React. The closest thing I could get to similar result, where the fallback is executed from server-side html markup is this. I used an extra div markup.

function ImageSSR({ src, fallbackSrc, alt }) {
  return (
    <div
      className="image"
      dangerouslySetInnerHTML={{
        __html: `
<img alt=${alt} src="${src}"
data-fallback=${fallbackSrc} 
onerror="this.onerror=null;this.src=this.dataset.fallback;" 
/>
  `
      }}
    />
  );
}

// Render

<ImageSSR
  src="https://dummyimage.com/200x100/000/fff&amptext=SSR"
  fallbackSrc="https://dummyimage.com/200x100/000/f00&text=fallback"
  alt="dummy image"
/>

If the src is invalid, then the fallbackSrc should kick in.
I tested this with Chrome, Safari and Firefox and it worked for those.

Here's the codesandbox demo
https://codesandbox.io/s/54xr4k8w4

I tried this with NextJS and confirmed the server-side rendered result.

<div class="image">
  <img alt=dummy image src="https://dummyimage.com/200x100/000/fff&text=SSR"
  data-fallback=https://dummyimage.com/200x100/000/f00&text=fallback
  onerror="this.onerror=null;this.src=this.dataset.fallback;"
  />
</div>

[aralroca]

@kunukn Thanks again for your answer.

Definitely I'm going to change my current workaround for your proposal. At least the fallback image is going to work as expected 🙂

Nevertheless, I miss a cleaner way to manage this. With your solution, it's hard to manage new props of ImageSSR Component, adding some extra complexity for each one. It also adds an extra div node on top.

As a workaround to fix my problem, it works for me. However, I want to propose an improvement. I think a nice solution would be something like:

<img 
 {...props}
 data-fallback={fallbackSrc}
 attachHTMLProps={{
   onerror: 'this.onerror=null;this.src=this.dataset.fallback;'
 }}
/>

My particular problem is related to the onerror event of image, but with the feature attachHTMLProps it's also going to be possible to fix similar problems without adding a node wrapper and with less complexity.

What do you think about this?

[jurajkocan]

that would be relly nice solution

[michaelyuen]

Hi @kunukn and @aralroca, we have encountered the same initial issue at my job. The discussion here is quite helpful, but I have a few clarifying questions:

1. The demo found here: https://codesandbox.io/s/54xr4k8w4

Question: Is the demo intended to exemplify a solution where two components (ImageSSR and ImageClientSide) would need to be used?
I feel I'm lacking some context regarding the demo's context - either just demoing what a SSR vs Client Side component may look like, or, implying both are part of a final solution.

---

Our solution: (and question)
For clarity, this solution uses one component rendered server-side and client-side.

return (
  <div dangerouslySetInnerHTML={{__html: `
    <img
      alt="${alt}"
      src="${src}"
      srcset="${srcSet}"
      onerror="this.onerror=null;this.src='${fallback}';this.srcset='${fallback}';"
    />
  `}} />
);

An aside: the notable difference is the addition of srcset, and resetting srcset in the onerror. This is necessary because of the behavior when both src and srcset are present. In our case, srcset defines a 1x so that takes precedence.
Reference: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-src

The server renders to a markup like this:

<img
  alt="Description of image"
  src="https://example.com/expected-image.png"
  srcset="[long srcset here]"
  onerror="this.onerror=null;this.src='https://example.com/fallback-image.png';this.srcset='https://example.com/fallback-image.png';"
  
/>

Great! Now the fallback is executed from server-side html markup. But there's one more thing...

When the fallback occurs, this code results in a console warning:

Warning: Prop dangerouslySetInnerHTML did not match. Server: [server markup] Client: [client markup]

This tripped me up, but after analysis I believe it is expected due to the scenario and can be safely ignored. The reason this warning occurs (I believe) is because the server-rendered markup's onerror is invoked before hydration (client calling hydrate), so once hydrate is invoked, the now-mutated markup (due to fallback) doesn't match the original server-rendered markup that the hydrate thinks it should expect. Thus, the warning indicates the server is different than the client, and not the other way around.
Again, our conclusion is to ignore the warning, but still...
Question(s):

1. Does anyone else have the same occur? If so, how have you handled it?
2. Does the reasoning and conclusion make sense, or is something amiss?

[kunukn]

Does the reasoning and conclusion make sense, or is something amiss?

Sounds correct to me.

---

This is the warning I saw when fiddling with NextJS. Something like this.

const fallback = 'https://source.unsplash.com/random';
const src = '';
const srcSet = '';

index.js:1 Warning: Prop dangerouslySetInnerHTML did not match.

Server:
<img alt="random" src="https://source.unsplash.com/random\" srcset="https://source.unsplash.com/random\"
onerror="this.onerror=null;this.src="https://source.unsplash.com/random&quot;;this.srcset=&quot;https://source.unsplash.com/random&quot;;\">

Client:
<img alt="random" src="" srcset=""
onerror="this.onerror=null;this.src="https://source.unsplash.com/random&quot;;this.srcset=&quot;https://source.unsplash.com/random&quot;;\">

The markup generation (HTML view source) was this:

<img
  alt='random'
  src=''
  srcset=''
  onerror='this.onerror=null;this.src="https://source.unsplash.com/random";this.srcset="https://source.unsplash.com/random";'
/>

To get around the warning, I tried to add setTimeout 100ms and the warning went away. This is probably happening because the hydration steps in before the DOM is mutated.

// Not to be used.
<div dangerouslySetInnerHTML={{
        __html: `
      <img
        alt='random'
        src='${src}'
        srcset='${srcSet}'
        onerror='this.onerror=null;setTimeout((function(){this.src="${fallback}";this.srcset="${fallback}"}).bind(this),100);'
      />
    `}} />

I would ignore the warning.