Tworzenie konta przez nowych użytkowników i logowanie się do systemu zazwyczaj wymaga podania co najmniej adresu email i hasła. Alternatywą dla tego typu rozwiązań jest dodatnie uwierzytelniania za pomocą zewnętrznych serwisów, które poświadczą wiarygodność użytkownika. Jedną z najbardziej popularnych opcji jest <code>Sign In With Google</code> i na tej usłudze skupimy się w tym artykule.Do stworzenia prostej aplikacji wykorzystamy Next.js, Prismę i SQLite, ale będzie to o tyle uniwersalne, że spokojnie możesz wykorzystać do tego inne narzędzia.<h2>Czym jest Sign In With Google i jakie korzyści daje</h2><code>Sign In With Google</code> w skrócie, ma na celu szybsze przeprowadzenie procesu uwierzytelniania w twojej aplikacji, na co składa się zarówno tworzenie nowego konta, jak i logowanie przez już istniejącego użytkownika. Takie rozwiązanie jest niezmiernie wygodne, ponieważ użytkownik nie musi wypełniać formularzu do rejestracji lub logowania, gdyż jest to zastępowane przez jeden guzik <code>Zaloguj się przez Google</code>. &nbsp;Zamiast inputów do wpisywania hasła i adresu email wyświetlamy taki przycisk:<figure class="image image_resized" style="width:25%;"><img style="aspect-ratio:363/75;" src="https://api.folticode.pl/uploads/Screenshot_from_2024_05_17_08_23_02_2d3cfa8385.png" alt="Screenshot from 2024-05-17 08-23-02.png" width="363" height="75"></figure>W kontekście formularza rejestracji może się zdarzyć, że będziemy wymagać od użytkownika podania dodatkowych danych (np. adres lub nr telefonu), więc w tym przypadku po uwierzytelnianiu przez &nbsp;<code>Sign In With Google</code> wyświetlimy dodatkowy w formularz, na którym zbierzemy dodatkowe informacje.Główne zalety tego rozwiązania:<ul><li>otrzymujemy zaufane i bezpieczne źródło uwierzytelniania użytkowników</li><li>dostęp do danych osobistych jak email czy imię i nazwisko na etapie tworzenia konta</li><li>wygoda użytkowników, co przekłada się na większą konwersję na stronie</li></ul><h2>Jak to działa?</h2>Mechanizm działania nie jest skomplikowany i cały proces można opisać w kilku krokach:<ol><li>Użytkownik klika w guzik "Zaloguj się przez Google"</li><li>&nbsp;Wyświetlany jest ekran zgód, na którym użytkownik potwierdza chęć uwierzytelnienia i przekazania danych profilowych do naszej aplikacji</li><li>W odpowiedzi dostajemy <code>ID token</code>, który zawiera m. in. nazwę i email użytkownika</li><li>Token wysyłamy do aplikacji backendowej, gdzie będzie on weryfikowany</li><li>Po poprawnej weryfikacji dodajemy nowego użytkownika do bazy danych (jeżeli nie istnieje), tworzymy token JWT i zwracamy go do aplikacji frontendowej</li><li>&nbsp;Tak otrzymany token możemy przechowywać w Local Storage i wykorzystać do autoryzacji&nbsp;</li></ol>Punkt 5 i 6 nie musi wyglądać zawsze tak samo i zależy to od przyjętego sposobu uwierzytelniania w aplikacji (zamiast JWT mogą być sesje i cookies). W tym artykule przyjęliśmy prosty system tworzenia tokenów JWT dla zalogowanych użytkowników.<h2>Stworzenie prostej aplikacji do uwierzytelniania</h2>Do tyle jeżeli chodzi o teorię! Przejdźmy teraz do napisania aplikacji, w której zobaczymy, jak w kilku krokach zaimplementować <code>Sign In With Google</code>.<h3>Założenie konta w Google API</h3>W tym kroku stworzymy ekran zgód oraz otrzymamy unikalny klucz <code>Client ID</code>, który jest niezbędny do dodania przycisku logowania. Posłuży nam w inicjowaniu klienta na froncie oraz przy walidacji <code>ID token</code> na backendzie.<h4>Tworzenie zgód</h4><ol><li>Wchodzimy na stronę <a href="https://console.developers.google.com/apis">https://console.developers.google.com/apis</a></li><li>Przechodzimy do zakładki OAuth consent screen i ustawiamy wartości<ul><li>Name =&gt; Sign In With Google Test App</li><li>Support email &amp; Developer contact information =&gt; podajemy nasz adres email</li></ul></li><li>Wybieramy UserType =&gt; External</li><li>Klikamy Save and continue i przechodzmy cały formularz z domyślnymi wartościami</li></ol><h4>Tworzenie danych logowania</h4><ol><li>Przechodzimy do zakładki Credentials</li><li>Wybieramy Utwórz dane logowania =&gt; Identyfikator klienta OAuth</li><li>Wybieramy Application type =&gt; Web application</li><li>W sekcji Authorized JavaScript origins dodajemy dwa rekordy:<ul><li>http://localhost</li><li>http://localhost:3000</li></ul></li><li>Klikamy Create</li></ol><h3>Aplikacja w Next.js</h3>1. Zacznijmy od postawienia aplikacji (nazwijmy ją <code>sign-in-with-google-app</code>):<pre><code class="language-typescript">npx create-next-app@latest --ts</code></pre>Teraz spróbujmy ją uruchomić:<pre><code class="language-typescript">cd sign-in-with-google-app
npm run dev</code></pre>Aplikacja powinna odpalić się w przeglądarce na porcie <code>3000</code>.2. Następnym krokiem jest zainicjowanie klienta &nbsp;Sign In With Google i dodanie przycisku logowania na ekranie:<pre><code class="language-typescript">// index.tsx

import Script from "next/script";

export default function Home() {
 // inicjujemy klienta Sign In With Google
 const initGoogleSignIn = () =&gt; {
 google.accounts.id.initialize({
 // dodajemy wygnenerowany wcześniej Client ID z Google API
 client_id: process.env.NEXT_PUBLIC_GOOGLE_CLIENT_ID!,
 // callback wywoływany po zalogowaniu się przez użytkownika
 callback: handleCredentialResponse,
 });
 // renderujemy przycisk logowania
 google.accounts.id.renderButton(
 document.getElementById("googleSignInBtnWrapper")!,
 { type: "standard", shape: "pill" },
 );
 };

 const handleCredentialResponse = async (
 credentials: google.accounts.id.CredentialResponse,
 ) =&gt; {};

 // ładujemy skrypt i po jego wczytaniu inicjujemy klienta Sign In With Google
 return (
 &lt;&gt;
 &lt;div id="googleSignInBtnWrapper" /&gt;
 &lt;Script
 src="https://accounts.google.com/gsi/client"
 onReady={initGoogleSignIn}
 /&gt;
 &lt;/&gt;
 );
}</code></pre>Musimy jeszcze zainstalować odpowiednie typy dla <code>google.accounts</code>:<pre><code class="language-typescript">npm install --save @types/google.accounts</code></pre>3. Gdy już mamy widoczny nasz przycisk na ekranie, możemy zabrać się za stworzenie prostego API, które będzie umożliwiało zalogowanie się i przechowywanie użytkowników w bazie danych. Do tego celu wykorzystamy narzędzie Prima:<pre><code class="language-typescript">npm install prisma --save-dev
npx prisma init --datasource-provider sqlite</code></pre>4. Teraz dodajemy model <code>User</code>, który Prisma przemapuję na odpowiednią encję w bazie danych:<pre><code class="language-typescript">// prisma/schema.prisma

...

model User {
 id Int @id @default(autoincrement())
 email String @unique
 authProviderId String @unique
}</code></pre>5. Następnie uruchamiamy migrację, która doda tabelę <code>User</code>:<pre><code class="language-typescript">npx prisma migrate dev --name init</code></pre>6. &nbsp;Pozostaje nam jeszcze dodanie endpointu do logowania użytkownika. Najpierw zainstalujemy niezbędne biblioteki:<pre><code class="language-typescript">npm i google-auth-library jsonwebtoken
npm i --save-dev @types/jsonwebtoken</code></pre>Teraz możemy dodać logikę, która będzie odpowiadać za weryfikowanie <code>ID token</code> zalogowanego użytkownika i zwracać token JWT, który później możemy wykorzystać do autoryzacji.<pre><code class="language-typescript">// pages/api/login.ts

import type { NextApiRequest, NextApiResponse } from "next";
import { PrismaClient } from "@prisma/client";
import { OAuth2Client, TokenPayload } from "google-auth-library";
import jwt from "jsonwebtoken";

// inicjujemy klienta Prismy i OAuth2
const prisma = new PrismaClient();
const authClient = new OAuth2Client();

export default async function handler(
 req: NextApiRequest,
 res: NextApiResponse,
) {
 if (req.method === "POST") {
 const { idToken } = req.body;

 try {
 // weryfikujemy czy token ID jest na pewno poprawny
 const payload = await verifyIdToken(idToken);
 const userId = payload.sub;
 const userEmail = payload.email;

 let user = await prisma.user.findFirst({
 where: {
 authProviderId: userId,
 },
 });

 // jeżeli użytkownik nie istnieje, tworzymy go
 if (!user) {
 user = await prisma.user.create({
 data: {
 email: userEmail!,
 authProviderId: userId,
 },
 });
 }

 // generujemy token JWT
 const token = jwt.sign({ userId: user.id }, process.env.JWT_SECRET!);

 res.status(200).json({ token });
 } catch (error) {
 res.status(401).json({ message: "Login failed" });
 }
 }
}

async function verifyIdToken(idToken: string): Promise&lt;TokenPayload&gt; {
 // ta walidacja jest rekomendowana przez Google dla zwiększenia bezpieczeństwa,
 // ponieważ ID token mógł zostać zmieniony po stronie klienta
 const ticket = await authClient.verifyIdToken({
 idToken: idToken,
 audience: process.env.NEXT_PUBLIC_GOOGLE_CLIENT_ID,
 });
 const payload = ticket.getPayload();

 if (!payload || !payload.sub || !payload.email) {
 throw new Error("Invalid token");
 }

 return payload;
}</code></pre>7. Na koniec pozostaje nam tylko dodanie logiki do metody <code>handleCredentialResponse</code>, która wywoła endpoint <code>/api/login</code>:<pre><code class="language-typescript">export default function Home() {
 
 ...

 const handleCredentialResponse = async (
 credentials: google.accounts.id.CredentialResponse,
 ) =&gt; {
 const response = await fetch("/api/login", {
 method: "POST",
 headers: {
 "Content-Type": "application/json",
 },
 body: JSON.stringify({ idToken: credentials.credential }),
 });
 const data = await response.json();

 console.log(data);
 };

 ...
}</code></pre><h2>Podsumowanie</h2>Sign In With Google zwiększa komfort logowania się użytkownika na naszej stronie, a implementacja tego — jak mogliśmy się przekonać — nie jest zbyt złożona. W zaledwie kilku krokach możemy dodać tę wygodną formę uwierzytelniania w naszej aplikacji.Link do kodu: <a href="https://github.com/folt3k/sign-in-with-google-test-app">https://github.com/folt3k/sign-in-with-google-test-app</a>

Frame 12 (2).png

Uwierzytelnianie z Sign In With Google

Zarządzanie datami w aplikacjach często może być źródłem kłopotów. Problemy pojawiają się w sytuacjach, gdy nasza aplikacja może być dostępna dla osób w różnych miejscach na świecie, a daty są zapisywane w niepoprawnym formacie. W tym artykule dowiemy się, dlaczego daty w systemie należy przechowywać w standardzie UTC i czym są strefy czasowe.<h2>Na czym polega problem?</h2>Wyobraźmy sobie, że w naszej aplikacji użytkownik może dodawać komentarze. Po dodaniu komentarza data jego utworzenia jest zapisywana do bazy danych zgodnie z datą systemową serwera, na którym stoi nasza aplikacja. Załóżmy, że taki serwer jest w Polsce, więc zapisuje do bazy danych jako datę dodania komentarza bieżącą datę w Polsce, czyli np.&nbsp;<code>01-01-2024 12:00</code>.Jeżeli komentarz dodał użytkownik z Polski, to w aplikacji wyświetli mu się data dodania&nbsp;<code>01-01-2024 12:00</code>. Do tego momentu jest OK. Ale co się stanie, gdy komentarz dodał użytkownik z Portugalii?Z racji tego, że aplikacja jako moment dodania komentarza bierze czas serwerowy, to do bazy danych zostanie wstawiona również data&nbsp;<code>01-01-2024 12:00</code>. &nbsp;Użytkownik z Portugalii zobaczy w przeglądarce również taką samą datę. Niestety, taka informacja może wywołać u niego zmieszanie, ponieważ w momencie dodawania komentarza w Polsce jest co prawda godzina&nbsp;12:00, to jednak ze względu na inną strefę czasową w Portugalii będzie godzina&nbsp;11:00.I to właśnie godzinę 11:00, zamiast 12:00 powinien zobaczyć pod swoim komentarzem mieszkaniec Lizbony.Nim jednak przejdziemy do rozwiązania tego problemu, najpierw musimy zrozumieć, czym są strefy czasowe i skąd wynikają różnice w czasie między krajami.<h2>Podział na strefy czasowe</h2>W XIX wieku, gdy ludzie zaczęli więcej przemieszczać się po świecie, zaczęto poszukiwać rozwiązania, które ułatwiłoby podróżowanie między krajami i mogłoby pomóc w ujednoliceniu czasu na całym globie. Wprowadzony został pomysł podziału świata na 24 strefy czasowe, w którym każda kolejna strefa ma inny czas, w zależności od swojego położenia względem strefy na południku zerowym. Południk zerowy przebiega przez&nbsp;obserwatorium Greenwich w Londynie, a czas, który panuje w tej strefie, jest&nbsp;czasem uniwersalnym&nbsp;(Greenwich Mean Time, w skrócie GMT). Ta strefa jest oznaczana jako&nbsp;<code>GMT+0</code>&nbsp;i oznacza to, że od niej jest liczony czas w pozostałym strefach czasowych: im dalej na wschód, tym więcej godzin odejmujemy, a im dalej na zachód to więcej godzin dodajemy do czasu uniwersalnego. W zależności ile wynosi różnica godzin względem czasu uniwersalnego, to strefy czasowe oznacza się na przykład jako&nbsp;<code>GMT+3</code> czy&nbsp;<code>GMT-9</code>.Dla przykładu: jeżeli w Greenwich jest godzina&nbsp;12:00, to czasem uniwersalnym jest również&nbsp;12:00. Warszawa znajduje się w strefie&nbsp;<code>GMT+1</code>, co oznacza, że doliczamy jedną godzinę względem czasu uniwersalnego i na warszawskich zegarach zobaczymy godzinę&nbsp;13:00. Analogicznie, jeżeli Nowy Jork jest w strefie <code>GMT-4</code>, to czas lokalny tam będzie wskazywał na godzinę 8:00.<figure class="image image_resized" style="width:78.28%;"><img style="aspect-ratio:1500/809;" src="https://api.folticode.pl/uploads/tz_photo_5a4ffce614.jpg" alt="tz-photo.jpg" width="1500" height="809"><figcaption>Podział świata na 24 strefy czasowe.</figcaption></figure><h2>Czas letni</h2>Podział na strefy czasowe może nieco komplikować&nbsp;czas letni (Daylight Saving Time, DST), który obowiązuje na całym świecie (głównie w większości krajów europejskim i Ameryce Północnej). Polega on na przesunięciu wskazówek zegara w ostatnią niedzielę marca o 01:00 czasu uniwersalnego o jedną godzinę do przodu (w Polsce jest to wg czasu lokalnego z 2:00 na 3:00) oraz o cofnięciu o godzinę w ostatnią niedzielę października. Główna motywacja dla tego rozwiązania to większa oszczędność energii poprzez lepsze zarządzanie światłem słonecznym. Jeżeli przestawiamy godzinę do przodu, to zyskujemy więcej światła po południu i wieczorem, gdy wracam z pracy i chcemy zająć się obowiązkami domowymi. Dzięki temu — przynajmniej w teorii — możemy oszczędzić energię, ponieważ nie musimy używać tyle oświetlenia elektrycznego. Obecnie, to rozwiązanie jest coraz częściej krytykowane ze względu na problemy, jakie powoduje m.in. w transporcie i logistyce oraz marginalny wpływ na oszczędność energii.Jeżeli przechodzimy na czas letni, to wtedy różnica między czasem lokalnym w Polsce a czasem uniwersalnym wynosi 2 godziny, co możemy oznaczyć jako&nbsp;<code>GMT+2</code>.<h2>Różnica między GMT i UTC</h2>W kontekście pracy z datami często obok skrótu GMT używany jest również skrót&nbsp;UTC&nbsp;(Coordinated Universal Time). &nbsp;Najczęściej są one traktowane jako synonimy i można je stosować wymiennie, ale warto wprowadzić tutaj rozróżnienie.GMT jest oznaczeniem wskazującym na czas słoneczny w Greenwich, a zapis&nbsp;<code>GMT+0</code> oznaczeniem tej strefy czasowej. Pozostałe strefy czasowe przyjmują oznaczenia zgodne z różnicą od czasu GMT — czyli np.&nbsp;<code>GMT-5</code> dla Nowego Jorku albo&nbsp;<code>GMT+2</code> dla czasu letniego środkowoeuropejskiego.UTC jest następcą standardu GMT stosowanym na całym świecie, który uwzględnia jego liczenie za pomocą zegarów atomowych, które są dokładniejsze. W praktyce wskazuje on na ten sam czas co GMT, czyli czas&nbsp;<code>UTC+02:00</code> oznacza czas w strefie czasowej&nbsp;<code>GMT+2</code>.GMT jest zarówno strefą czasową jak i standardem czasu, natomiast UTC jest tylko standardem czasu.<h2>Jak poprawnie zapisywać daty?</h2>Do zapisu dat używamy międzynarodowego standardu&nbsp;ISO-8601. W zależności od tego, dla jakiej strefy czasowej chcemy zapisać datę, możemy użyć dwóch formatów:<ul><li>dla czasu uniwersalnego: <code>YYYY-MM-DDThh:mm:ssZ</code></li><li>dla innych stref czasowych: <code>YYYY-MM-DDThh:mm:ss+hh:mm</code></li></ul>W obu przypadkach&nbsp;<code>T</code> oddziela datę od godziny, a dla czasu uniwersalnego&nbsp;<code>Z</code> wskazuje na czas Greenwich (Zulu time).Najlepiej pokazać to na przykładzie. W momencie pisania tego artykułu mamy w Polsce&nbsp;<code>17 marca 2024, godz. 12:00</code>. Polska jest w strefie czasowej&nbsp;<code>GMT+1</code>, co oznacza, że jest 1 godzinę za czasem uniwersalnym. Zgodnie ze standardem ISO możemy taką datę zapisać na dwa wymienione wyżej sposoby:<ul><li>dla czasu uniwersalnego: <code>2024-03-17T11:00Z</code></li><li>dla naszej strefy czasowej: <code>2024-03-17T12:00+01:00</code></li></ul>Zauważ, że dla czasu uniwersalnego podajemy czas o godzinę wstecz. Każdy z tych formatów jest właściwy, jednak w aplikacjach powinniśmy się skłaniać do używania formatu&nbsp;<code>YYYY-MM-DDThh:mm:ssZ</code>. Jest on łatwiejszy w zrozumieniu, czytelniejszy i bardziej uniwersalny. Niezależnie od tego, w jakiej strefie czasowej jesteśmy i czy mamy czas letni, data zawsze wygląda tak samo i pokazuje czas w Greenwich.W Javascripcie możemy otrzymać datę w formacie ISO używając metody <code>toISOString</code> z klasy&nbsp;Date.<pre><code class="language-typescript">new&nbsp;Date().toISOString();
// 2024-03-17T11:00:00.000Z</code></pre><h2>Podsumowanie</h2>Wracając do problemu omawianego na początku artykułu, jeżeli zapiszemy datę dodania komentarza w czasie uniwersalnym, to z łatwością będziemy mogli przekonwertować taką datę na czas lokalny, który jest na urządzeniu użytkownika. Niezależnie od tego, w którym miejscu na świecie użytkownik dodał komentarz, to data wyświetli się odpowiednio dla innych użytkowników korzystających z naszej aplikacji w innych częściach globu, zgodnie z ich czasem lokalnym.Jeżeli użytkownik z Pekinu (GMT+8) doda komentarz o godz. 20:00 czasu lokalnego w Pekinie, to zapiszemy tę godzinę jako 12:00 czasu uniwersalnego (<code>2024-03-17T12:00:00.000Z</code>). &nbsp;Użytkownik z Warszawy (GMT+1) zobaczy z kolei, że komentarz chińskiego użytkownika &nbsp;został dodany o 13:00 czasu polskiego.Zawsze należy przechowywać daty w formacie ISO ze wskazaniem na strefę czasową, nawet jeżeli zakładamy, że aplikacja będzie odwiedzana tylko przez użytkowników z Polski. Uchroni nas to przed potencjalnymi błędami związanymi z wyświetlaniem daty, które niejednokrotnie mogą być poważnymi problemami, które będą uniemożliwiały użytkownikowi interakcje z systemem.

Frame 13.png

Jak poprawanie zarządzać czasem w aplikacjach?

Współczesne strony internetowe muszą odpowiednio wyświetlać się na różnych urządzeniach mobilnych, od tabletów po smartfony. Aby osiągnąć taki efekt, powinniśmy zamieścić na naszej stronie meta tag <code>viewport</code>, który będzie informował silniki przeglądarek mobilnych o tym jak poprawnie wyświetlać treść. &nbsp;Bez tej informacji, teksty i elementy interfejsu na urządzeniach mobilnych będą dla użytkownika zbyt małe, co znacznie utrudni mu korzystanie z naszej strony.<h2>Czym właściwie jest viewport?&nbsp;</h2>W kontekście tworzenia stron internetowych <code>viewport</code> odnosi się do obszaru na ekranie przeglądarki internetowej, w którym wyświetlane są treści. Przestrzeń ta nie jest tożsama z rozmiarem strony, ponieważ <code>viewport</code> nie uwzględnia scrollbarów, które dodaje domyślnie przeglądarka, gdy treść przekracza rozmiar viewportu.W artykule jako przykład będzie nam służył iPhone 12 Pro, którego viewport wynosi <code>390px × 844px</code>. Oznacza to, że jeśli dodamy na stronie element, którego szerokość będzie wynosiła <code>500px</code>, to strona nam się rozjedzie i treść wyjdzie poza obszar viewportu.<img class="image_resized" style="aspect-ratio:680/698;width:40.5%;" src="https://api.folticode.pl/uploads/viewport_d6fef81302.svg" alt="viewport.svg" width="680" height="698"><h2>Rozmiar viewportu a rozdzielczość ekranu</h2>W tym momencie może pojawić się pytanie: jeżeli rozdzielczość iPhona 12 Pro to <code>1170px × 2532px</code>, to dlaczego rozmiar viewportu nie jest taki sam?&nbsp;Problem wynika stąd, &nbsp;że nowe smartfony coraz częściej posiadają wysokie rozdzielczości (nawet do 1920px × 1080px), co sprawia, że na małym ekranie smartfona jest duże zagęszczenie pikseli. To z kolei będzie powodować, że elementy strony w przeglądarce będą zbyt małe. Z pomocą przychodzi <code>CSS pixel ratio</code>, który określa stosunek między liczbą pikseli na ekranie urządzenia (piksele fizyczne) a liczbą pikseli CSS (piksele logiczne), które są zdefiniowane przez przeglądarkę. Innymi słowy, jeżeli <code>pixel ratio</code> wynosi 3, to oznacza to, że jednemu pikselowi CSS odpowiadają trzy piksele fizyczne na ekranie urządzenia. W praktyce znaczy to tyle, że jeżeli mamy element z szerokością <code>100px</code>, to na ekranie urządzenia zajmie on rzeczywistą przestrzeń <code>300px</code>.&nbsp;W przypadku iPhona 12 Pro <code>pixel ratio</code> wynosi <code>3</code>, co oznacza, że ekran o wymiarach <code>1170px × 2532px</code> zostanie przeskalowany do viewportu o wymiarach <code>390px × 844px</code>:<pre><code class="language-typescript">1170 / 3 = 390
2532 / 3 = 844</code></pre>W rezultacie rozmiar tekstu i elementów UI będzie zbliżony do tych na urządzeniach o mniejszych rozdzielczościach, ale będą one bardziej szczegółowe i wyraziste, z powodu większego zagęszczenia pikseli.&nbsp;<h2>Jak przeglądarki mobilne wyświetlają strony?</h2>Przeglądarki mobilne używają do renderowania stron <code>virtual viewport</code>, który zazwyczaj przyjmuje szerokość <code>980px</code>. Jak to działa w praktyce? Najpierw przeglądarka wyrenderuje stronę na szerokości <code>980px</code>, a potem skurczy ją w taki sposób, aby dopasowała się do szerokości viewportu (<code>380px</code> w naszym przypadku). Efekt będzie taki, że tekst i elementy UI będą bardzo małe. Oczywiście będzie to wyglądać źle, ale dzięki temu mamy zapewnioną chociaż minimalną skalowalność interfejsu.&nbsp;Nie jest to oczywiście wystarczające rozwiązanie. Aby strona była w pełni responsywna, musimy skorzystać ze wspomnianego znacznika meta, który umieszczamy w sekcji <code>head</code> dokumentu HTML.<pre><code class="language-html">&lt;meta name="viewport" content="width=device-width, initial-scale=1" /&gt;</code></pre>Atrybut <code>content</code> może przyjmować dodatkowe parametry, ale nas interesują tutaj dwa podstawowe:<ul><li><code>width=device-width</code> - ustawienie szerokości viewportu na 100% szerokości viewportu urządzenia</li><li><code>initial-scale=1</code> - początkowa wartość powiększenia strony, gdzie wartość <code>1</code> gwarantuje optymalne powiększenie</li></ul>Tak będzie wyglądał efekt z zastosowaniem meta tagu <code>viewport</code>:<img class="image_resized" style="aspect-ratio:1007/698;width:56.64%;" src="https://api.folticode.pl/uploads/roznice_viewport_0915c11836.svg" alt="roznice viewport.svg" width="1007" height="698">Tekst i grafiki są teraz odpowiednio dostosowane pod względem rozmiaru do ekranu urządzania mobilnego, dzięki czemu użytkownik nie musi ich ręcznie powiększać.<h2>Podsumowanie</h2>Smartfony i tablety pomimo swoich małym rozmiarów są wyposażone w coraz to większe rozdzielczości ekranów. Zastosowanie znacznika <code>meta viewport</code> w połączeniu ze skalowaniem <code>pixel ratio</code> sprawia, że możemy widzieć na ekranach urządzeń mobilnych treści w odpowiednim rozmiarze dla naszego oka. Stosowanie tego rozwiązania jest absolutnym standardem w tworzeniu współczesnych stron internetowych, i myślę, że warto zapoznać się z jego działaniem.

Blog

Uwierzytelnianie z Sign In With Google

Jak poprawanie zarządzać czasem w aplikacjach?

Dlaczego potrzebujemy na stronie meta tagu viewport?