Vue.js SSR & Mobile Safari: Unobvious Problem With Too Smart Software
The other day, faced with such a problem. The server-generated code refused to be hydrated in Safari.
As a result, it turned out that our application crashes when the footer component is connected. And when they found the right line, they simply did not believe their eyes. Expect anything, just not this.
It turned out that when you delete a phone number, hydration took place without problems. When they began to dig, it turned out that after receiving the html-layout, Safari substituted the a tag next to the phone , which actually caused the dialer application.
Naturally, when hydration began, the dom of the page that came from the server and the newly built virtual did not match. The application fell without a declaration of war.
This problem was solved also quite unexpectedly. Until now, we have inserted the phone in the usual way:
The solution to the problem was the binding v-text:
I have a theory on this. If someone can confirm it or disprove it (by proposing a new one), I will be very grateful. As I understand it, after Safari got the document, Vue builds a virtual dom and compares it with this document and while he hydrates this document, Safari does his dark work and changes the phone to a link. When it comes to this field, Vue with v-text again replaces the contents of our diva with what we need. As a result, at the time of comparison, the dom match, the flight is normal.
Hydration refers to a client-side process, during which Vue takes static HTML sent by the server and turns it into a dynamic DOM that can respond to changes in data on the client side. Read more here ."Prod" just fell, and the dev version reported that there were discrepancies in the dom. And since the dev version does not crash when trying to hydrate, but only reports this to the console, the error was not obvious and quite a long time passed until we found it.
A very interesting strategy from Vue is to wait for the production and fall there!One and a half hundred components of different complexity did not simplify the task. In the end, we managed to see the problem, find the right device and make friends with the developer console.
As a result, it turned out that our application crashes when the footer component is connected. And when they found the right line, they simply did not believe their eyes. Expect anything, just not this.
It turned out that when you delete a phone number, hydration took place without problems. When they began to dig, it turned out that after receiving the html-layout, Safari substituted the a tag next to the phone , which actually caused the dialer application.
Naturally, when hydration began, the dom of the page that came from the server and the newly built virtual did not match. The application fell without a declaration of war.
This problem was solved also quite unexpectedly. Until now, we have inserted the phone in the usual way:
<div>8 (800) 111 2 333</div>The solution to the problem was the binding v-text:
<divv-text=”8 (800) 1112333”></div>I have a theory on this. If someone can confirm it or disprove it (by proposing a new one), I will be very grateful. As I understand it, after Safari got the document, Vue builds a virtual dom and compares it with this document and while he hydrates this document, Safari does his dark work and changes the phone to a link. When it comes to this field, Vue with v-text again replaces the contents of our diva with what we need. As a result, at the time of comparison, the dom match, the flight is normal.