Web Overflow 🇺🇦

WebP to PNG 🥴

У нашому проєкті виникла потреба генерувати PDF-файли. Для цього ми використовуємо бібліотеку react-pdf - інструмент для створення PDF. Працювати над таким типом завдань — це ще той квест, тому краще оминайте такі задачі.

Нам потрібно вставляти динамічні зображення (на даний момент підтримуємо лише JPG, PNG та WebP). Ми розчарувалися, коли виявилося, що PDF не підтримує формат WebP, а обробка таких зображень була надзвичайно необхідною.

Тому ми обрали, мабуть, найпростішу та найшвидшу стратегію — відмалювати WebP-зображення на canvas і отримати з нього PNG. Виглядає код приблизно так:


function toPNGUsingCavas(src: string) {
const image = new Image()

const { promise, resolve, reject } = Promise.withResolvers()

image.onload = function () {
const canvas = document.createElement('canvas')
canvas.width = image.naturalWidth
canvas.height = image.naturalHeight

const context = canvas.getContext('2d')
if (!context) {
reject(new Error('Could not get canvas context'))
} else {
context.drawImage(image, 0, 0)
resolve(canvas.toDataURL('image/png'))
}
}

image.onerror = reject

image.src = src

return promise
}


Тут, до речі, можете побачити приклад використання Promise.withResolvers, про який ми розповідали раніше.

#experience

UAParser.js 🧑‍💻

Іноді буває корисно дізнатися трохи більше про відвідувача вашого веб-сайту: який у нього браузер, операційна система чи навіть сам пристрій. Багато такої інформації міститься у User-Agent, і її можна отримати як на клієнті, так і з HTTP-заголовків запиту.

Але навряд чи ви захочете вручну розбирати щось таке:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

Бібліотека UAParser.js допоможе вам розібрати User-Agent і витягти інформацію про браузер, процесор, пристрій та операційну систему.

👉 Відкрити посилання

#library

Query Key Factory 🏭

Останнім часом у нашому проєкті активно використовуємо Tanstack Query. Загалом, багато продуктів Tanstack виглядають дуже цікаво. Але сьогодні хочемо поговорити саме про Query, а точніше — про queryKey.

Все наче доволі просто - ключ до наших даних. Ми завжди прописували його прямо в useQuery:
const usePokemon = (id: string) =>
useQuery({
queryKey: ["pokemons", id],
queryFn: () => PokemonService.getById(id),
})


Якщо ж у нас є окремий хук для оновлення, після успішного завершення можна "змусити" useQuery перевантажити дані за певним ключем:
const useUpdatePokemon = (id: string) => {
const client = useQueryClient()

return useMutation({
mutationFn: (name: string) => PokemonService.update(id, { name }),
onSuccess: () => {
client.invalidateQueries({ queryKey: ['pokemons', id] })
},
})
}


При виклику invalidateQueries потрібно передати queryKey. Якщо ми хочемо оновити конкретного покемона, потрібно вказати той самий ключ.

Схожа ситуація виникає, коли ви викликаєте prefetchQuery у серверній компоненті, щоб швидко завантажити дані для користувача.

Як це можна покращити? Одне з рішень - створювати та зберігати queryKey у певному обʼєкті. На сторінці Community Projects ми знайшли бібліотеку @lukemorales/query-key-factory. Вона містить кілька допоміжних функцій, які допоможуть організувати параметри для useQuery.

👉 Відкрити посилання

#library

#todo написати функцію на будь-якій мові програмування, яка приймає масив чисел arr та число N. Функція має повернути масив, кожен елемент якого є підмасивом розміром N. Винятком є останній підмасив, який може мати розмір [1, N]. Порядок усіх чисел має зберігатись.

Наприклад:

[1, 2, 3, 4, 5, 6, 7, 8, 9], 3 => [[1, 2, 3], [4, 5, 6], [7, 8,9]]
[1, 2, 3, 4, 5, 6, 7, 8, 9], 2 => [[1, 2], [3, 4], [5, 6], [7, 8], [9]]