Görütülemlerden dolayı ekran görüntülerini hata ayıklamaktan bıktım, bu yüzden bir Laravel PDF paketi geliştirdim.

Her HTML’den PDF’e dönüştürme sistemi aynı duvara çarpar.

Chrome çok erken yakalıyor.

Bu, Chrome bozuk olduğu için değil.
PDF kütüphanesi kötü olduğu için de değil.

Çünkü render süreci tahmin yapıyor.

Bazen grafik hala animasyon halindedir.
Bazen font henüz yüklenmemiştir.
Bazen asenkron veriler yavaş bir kuyruk işleyicisinde 200ms daha geç gelir.

Ve sonunda birisi şu şekilde rapor verir:

“3 gün önceki fatura yanlış görünüyordu.”

Artık gönderilmiş bir render ile ilgili hata ayıklıyorsunuz.

Hiçbir log yok.
Hiçbir ekran görüntüsü yok.
Hiçbir DOM durumu yok.
Chrome’un aslında ne gördüğü hakkında hiçbir fikriniz yok.

Bu sorunla yıllardır çeşitli yığınlar ve projelerde mücadele ettim.

Yaygın çözümler her zaman şu şekilde görünüyordu:

waitUntilNetworkIdle
delay(2000)
// dua et

Bu işe yarıyor.
Ta ki işe yaramayana kadar.

Temel sorun oldukça basit:

Renderer, uygulamanızın ne zaman hazır olduğunu gerçekten bilmiyor.

Bu yalnızca sizin uygulamanızın bilmesi gereken bir şey.

Bu yüzden Canio’yu geliştirdim.

Hazırlık Sözleşmesi

Zamanlama tahminlerine güvenmek yerine, sayfa açıkça hazırlık durumunu sinyal veriyor:

window.__CANIO_READY__ = true;

Bu sinyal, şu durumları bekledikten sonra gelebilir:

• fontlar yüklendiğinde
• grafikler animasyonu tamamladığında
• asenkron istekler tamamlandığında
• Vue hidrasyonu tamamlandığında
• belgeniz için “tamam” ne anlama geliyorsa

Renderer tahmin yapmayı bırakıyor.

Uygulamanız ne zaman yakalanacağını belirliyor.

Bu tek inverte, tüm render modelini değiştiriyor.

Gerçek Özellik Hazırlık Değil

Asıl umursadığım kısım şudur:

Her render kanıt bırakabilir.

Canio şunları kalıcı hale getirebilir:

• HTML kaynağı
• DOM anlık görüntüsü
• yakalama anında ekran görüntüsü
• konsol logları
• network logları

Bu nedenle birisi şöyle derse:

“Bu PDF geçen Salı bozuk görünüyordu.”

Yarış durumunu yeniden üretmeye çalışmazsınız.

Artifact ekran görüntüsünü açar ve Chromium’un tam olarak ne gördüğünü görürsünüz.

Bu, PDF hata ayıklamayı arkeolojiden muayene etmeye dönüştürür.

Neden Önemlidir

En çoğu HTML’den PDF’e aracılar, render etmeyi:

HTML in
PDF out 

Ama render anlık değildir.

Modern sayfalar zamansal sistemlerdir.

Fontlar daha sonra yüklenir.
Animasyonlar daha sonra tamamlanır.
Hidratasyon daha sonra biter.
Veri daha sonra gelir.

Renderer hareket eden bir hedefi örnekliyor.

Canio, render etmeyi zaman aşımı yerine senkronizasyon sorunu olarak ele alır.

Motorun İçinde

Canio, Stagehand adlı bir Go çalışma zamanı kullanmaktadır.

Stagehand, gerçek Chromium ile CDP üzerinden doğrudan iletişim kurar.

Neden Go, Node yerine?

Genellikle dağıtım ergonomisi nedeniyle.

Ben istedim ki:

• tek bir statik ikili dosya
• tahmin edilebilir bellek kullanımı
• üretimde node_modules yok
• izole edilmiş render altyapısı
• daha basit kapsülleme

Canio şunları destekler:

• gömülü çalışma zamanı
• uzaktan CDP çalışma zamanı
• mevcut yerel Chrome

Ayrıca, otomatik olarak bir Test yapısı için sabitlenmiş bir Chrome kurulumunu da sağlar.

Browsershot Hala Harika

Bunu açıkça söylemek önemli:

Browsershot harikadır.

Ben hala onu kullanıyorum.

Canio, basit render işlemleri için Browsershot’ın yerini almak istemiyor.

Canio, aşağıdaki durumlar için vardır:

• render zamanlaması önem arz ettiğinde
• deterministik yakalama önem arz ettiğinde
• üretim hata ayıklama önem arz ettiğinde

Bu alan budur.

Deneyin

composer require oxhq/canio
php artisan canio:install

Repo:
https://github.com/oxhq/canio

Geri bildirim ve eleştiriler samimiyetle hoş karşılanır.
Özellikle üretimde HTML’den PDF’e render sorunu ile mücadele edenlerden.