Vue.js SSR & мобильный Safari: неочевидная проблема со слишком умным ПО

[@aamonster]

Я правильно понял, что ваше решение ломает «кликабельность» имеющихся на страничке номеров телефонов? Или вы их делаете кликабельными самостоятельно, и «искуственный интеллект» вам не нужен?

[@HAGer2000]

Надо поэкспериментировать, пока под рукой нет подходящего девайса. Вообще, от «бизнеса» не было задачи делать телефоны кликабельными.

По идее, если ссылки сами по себе уже содержат указание на кликабельность телефона, вряд ли сафари будет в это дело вмешиваться. Другое вопрос, это, как бы, вообще не его дело, кликабельны телефоны или нет. Хочешь сделать такой функционал, решай вопрос на уровне DOM-свойств и событий, зачем подменять html?

[@aamonster]

Погодите. Как, где и зачем Safari подменяет html? Если я правильно понял, оно его просто парсит чуть иначе, чем «гидратация» — т.е. отличия именно на уровне DOM. Вроде в пределах допустимого (более того: аналогичный пример прописан в руководстве по данной вами ссылке).

Но решение vue.js, конечно, феерическое: сделать обход этой ситуации в дебаге — это додуматься надо. Всю жизнь принято делать в дебаге assert — чтобы fail fast и всё такое, а если уж делается обход для кривого случая — в релизе он 100% обязан использоваться. Дебаг может (и должен) упасть раньше релиза, но не упасть там, где релиз сломается — большой косяк.

[@HAGer2000]

т.е. отличия именно на уровне DOM

ну как… у нас есть dom-узел, у него есть свойства, которые появляются при парсинке html-разметки. То есть, в разметке мы прописываем тегу атрибуты (attributes), которые в итоге отражаются в свойства (properties) dom-узла. Если нам надо навесить обработчик события на какой-то элемент, в данном случае номер телефона, то нам надо работать именно с dom-элементом. Я об этом.

Сафари поступает иначе. Он получает html. Во вкладке Network видно, какой был ответ от сервера. Затем меняет текстовую ноду с телефоном на ссылку с href=«tel: тра-та-та» затем парсит это в dom-ноду с соответствующими свойствами. То есть, можно было бы (если я нигде не ошибся) повесить обработчик на эту ноду на уровне dom-properties не меняя состава dom-дерева. Тут, я правда, не уверен, при сравнении во время гидратации, не будет ли расхождением разные свойства этой самой ноды…

[@aamonster]

Ну так пример с tbody — ровно то же самое. Не было никакого tbody в html, но браузер его втыкает, потому что считает, что так будет лучше =).
Очень плохо иметь два независимых парсера html.

А насчёт расхождения при гидратации — возможно, и это будет ещё фееричнее: дебаг и релиз будут просто работать на разном DOM.

[@HAGer2000]

Возможно и то же самое. Но лично для меня такая подстава с номером телефона была неожиданной

[@aamonster]

Естественно, неожиданной
А теперь время для стука в дно: на десктопных браузерах есть энное количество расширений, правящих DOM. И в идеале бы с ними не конфликтовать...

[@Zavtramen]

Так телефоны надо через href=«tel:» делать вроде.

[@aamonster]

Я так понял, на сайтах очень часто такой URI не прописан, и Сафари умничает — чтобы в написанный на сайте телефон всегда можно было кликнуть.

[@a_e_tsvetkov]

А завтра они решат адреса в ссылки на карте превращать. Что тогда делать?

[@ZaEzzz]

Обязательно появится. Огорчают только несколько моментов:
1 — Head уже превращается в свалку.
2 — Обычно о таких случаях узнаешь при появлении проблемы, а не заранее.

[@a_e_tsvetkov]

Слава богу я не вебдевелопер :)

[@ZaEzzz]

Думаю, спасет.
Мы тоже недавно наткнулись на необходимость использования этого метатега — при отображении статистики некоторые цифры превращались в кликабельные телефонные номера.

UPD. Кстати, сейчас задумался. Никогда такой необходимости не возникало, но все же. А что делать, если нужно, чтобы сафари поменял запись на кликабельный номер, и при этом не упало само приложение на стадии гидратации. Сходу на ум приходит только забить на элемент и не трогать его совсем.

[@HAGer2000]

На мой взгляд, в текущей реализации этого функционала в Сафари, это вряд ли возможно. Он меняет дом, меняет атрибуты, создает новые ноды в дереве. При таком раскладе гидратация невозможна.

Ну либо эту часть сайта генерить только на клиенте, чтобы сервер вообще не знал о наличии телефонов

[@ahmpro]

А нельзя просто исключить этот кусок через no-ssr? Так ли критично, чтобы он гидрировал? :)

[@HAGer2000]

по идее, эта информация может быть полезной для индексации
по крайней мере, в нашем случае

ну а так, наверное можно так сделать
даже любопытно, что получится в результате? будет ли сафари потрошить такой, сгенерированный, код. но страница, скорее всего не обрушится

[@mayorovp]

Очевидно, в такой ситуации нужно превратить его в кликабельный номер самостоятельно.

[@k12th]

А как насчет <a href="tel:[phone]">8 (800) 111 2 333</a>?

[@Fragster]

В документации прямо так и написано:

В режиме разработки Vue будет проверять, что виртуальное дерево DOM, сгенерированное на стороне клиента, совпадает с структурой DOM созданной на сервере. При нахождении несоответствия, он будет считать гидратацию неудачной, отказываться от существующего DOM и рендерить всё с нуля. В режиме production, эта проверка отключена для достижения максимальной производительности.

Но вообще если apple так делает, то, вероятно, надо завести issue, чтобы vue изменил это поведение (не падал, а перерендерил компонент просто).

[@gli]

Зашел только чтобы поругать за «желтушность» заголовка. Давайте хабр не будет превращаться в стандартные желтые издания, которые привлекают аудиторию не значимым контекстом, а заманчивым заголовком.
«И вы не поверите, что мы увидели»
«Когда он открыл дверь, он не поверил своим глазам»
«Чтобы никогда не иметь проблем с потенцией надо всего лишь купить ...»
Тьфу, расстроился.

[@CyberAP]

То что вы описали это ошибка Vue. Гидратация должна всегда быть failsafe. Safai конечно тоже молодец что без спроса меняет DOM, но такие вещи не должны ломать всё приложение.

[@HAGer2000]

полностью согласен
правда слабо представляю себе, как это на практике починить

[@HAGer2000]

Видимо, примерно так сделано в dev-сборке. В проде они намерено отключили такую возможность

[@HAGer2000]

да