<p>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.</p><p>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.</p><h2>Czym jest Sign In With Google i jakie korzyści daje</h2><p><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:</p><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><p>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.</p><p><strong>Główne zalety tego rozwiązania:</strong></p><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><p>Mechanizm działania nie jest skomplikowany i cały proces można opisać w kilku krokach:</p><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><p>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.</p><h2>Stworzenie prostej aplikacji do uwierzytelniania</h2><p>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>.</p><h3>Założenie konta w Google API</h3><p>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.</p><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 <strong>OAuth consent screen</strong><i> </i>i ustawiamy wartości<ul><li><strong>Name =&gt; Sign In With Google Test App</strong></li><li><strong>Support email &amp; Developer contact information =&gt; </strong>podajemy nasz adres email</li></ul></li><li>Wybieramy<i> </i><strong>UserType</strong><i><strong> </strong></i><strong>=&gt; External</strong></li><li>Klikamy <strong>Save and continue</strong> i przechodzmy cały formularz z domyślnymi wartościami</li></ol><h4>Tworzenie danych logowania</h4><ol><li>Przechodzimy do zakładki <strong>Credentials</strong></li><li>Wybieramy <strong>Utwórz dane logowania =&gt; Identyfikator klienta OAuth</strong></li><li>Wybieramy<i> </i><strong>Application type =&gt; Web application</strong></li><li>W sekcji <strong>Authorized JavaScript origins</strong> dodajemy dwa rekordy:<ul><li>http://localhost</li><li>http://localhost:3000</li></ul></li><li>Klikamy <strong>Create</strong></li></ol><h3>Aplikacja w Next.js</h3><p><strong>1.</strong> Zacznijmy od postawienia aplikacji (nazwijmy ją <code>sign-in-with-google-app</code>):</p><pre><code class="language-typescript">npx create-next-app@latest --ts</code></pre><p>Teraz spróbujmy ją uruchomić:</p><pre><code class="language-typescript">cd sign-in-with-google-app
npm run dev</code></pre><p>Aplikacja powinna odpalić się w przeglądarce na porcie <code>3000</code>.</p><p><strong>2.</strong> Następnym krokiem jest zainicjowanie klienta &nbsp;Sign In With Google i dodanie przycisku logowania na ekranie:</p><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><p>Musimy jeszcze zainstalować odpowiednie typy dla <code>google.accounts</code>:</p><pre><code class="language-typescript">npm install --save @types/google.accounts</code></pre><p><strong>3.</strong> 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:</p><pre><code class="language-typescript">npm install prisma --save-dev
npx prisma init --datasource-provider sqlite</code></pre><p><strong>4. </strong>Teraz dodajemy model <code>User</code>, który Prisma przemapuję na odpowiednią encję w bazie danych:</p><pre><code class="language-typescript">// prisma/schema.prisma

...

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  authProviderId String @unique
}</code></pre><p><strong>5. </strong>Następnie uruchamiamy migrację, która doda tabelę <code>User</code>:</p><pre><code class="language-typescript">npx prisma migrate dev --name init</code></pre><p><strong>6.</strong> &nbsp;Pozostaje nam jeszcze dodanie endpointu do logowania użytkownika. Najpierw zainstalujemy niezbędne biblioteki:</p><pre><code class="language-typescript">npm i google-auth-library jsonwebtoken
npm i --save-dev @types/jsonwebtoken</code></pre><p>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.</p><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><p><strong>7.</strong> Na koniec pozostaje nam tylko dodanie logiki do metody <code>handleCredentialResponse</code>, która wywoła endpoint <code>/api/login</code>:</p><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><p>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.</p><p>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></p>

Frame 12 (2).png

Uwierzytelnianie z Sign In With Google

<p>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.</p><h2>Na czym polega problem?</h2><p>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>.</p><p>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?</p><p>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.</p><p>I to właśnie godzinę 11:00, zamiast 12:00 powinien zobaczyć pod swoim komentarzem mieszkaniec Lizbony.</p><p>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.</p><h2>Podział na strefy czasowe</h2><p>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;<strong>obserwatorium Greenwich w Londynie</strong>, a czas, który panuje w tej strefie, jest&nbsp;<strong>czasem uniwersalnym</strong>&nbsp;(<i>Greenwich Mean Time</i>, 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>.</p><p>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.</p><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><p>Podział na strefy czasowe może nieco komplikować&nbsp;<strong>czas letni</strong> (<i>Daylight Saving Time</i>, 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.</p><p>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>.</p><h2>Różnica między GMT i UTC</h2><p>W kontekście pracy z datami często obok skrótu GMT używany jest również skrót&nbsp;<strong>UTC</strong>&nbsp;(<i>Coordinated Universal Time</i>). &nbsp;Najczęściej są one traktowane jako synonimy i można je stosować wymiennie, ale warto wprowadzić tutaj rozróżnienie.</p><p>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.</p><p>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>.</p><p>GMT jest zarówno strefą czasową jak i standardem czasu, natomiast UTC jest tylko standardem czasu.</p><h2>Jak poprawnie zapisywać daty?</h2><p>Do zapisu dat używamy międzynarodowego standardu&nbsp;<strong>ISO-8601</strong>. W zależności od tego, dla jakiej strefy czasowej chcemy zapisać datę, możemy użyć dwóch formatów:</p><ul><li>dla czasu uniwersalnego:<br><code>YYYY-MM-DDThh:mm:ssZ</code></li><li>dla innych stref czasowych:<br><code>YYYY-MM-DDThh:mm:ss+hh:mm</code></li></ul><p>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).</p><p>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:</p><ul><li>dla czasu uniwersalnego:<br><code>2024-03-17T11:00Z</code></li><li>dla naszej strefy czasowej:<br><code>2024-03-17T12:00+01:00</code></li></ul><p>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.</p><p>W Javascripcie możemy otrzymać datę w formacie ISO używając metody <code>toISOString</code> z klasy&nbsp;Date.</p><pre><code class="language-typescript">new&nbsp;Date().toISOString();
// 2024-03-17T11:00:00.000Z</code></pre><h2>Podsumowanie</h2><p>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.</p><p>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.</p><p><strong>Zawsze należy przechowywać daty w formacie ISO ze wskazaniem na strefę czasową</strong>, 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.</p>

Frame 13.png

Jak poprawanie zarządzać czasem w aplikacjach?

<p>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.</p><h2>Czym właściwie jest viewport?&nbsp;</h2><p>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.</p><p>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.</p><p style="text-align:center;"><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"></p><h2>Rozmiar viewportu a rozdzielczość ekranu</h2><p>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;</p><p>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;</p><p>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>:</p><pre><code class="language-typescript">1170 / 3 = 390
2532 / 3 = 844</code></pre><p>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;</p><h2>Jak przeglądarki mobilne wyświetlają strony?</h2><p>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 <strong>skurczy ją</strong> 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;</p><p>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.</p><pre><code class="language-html">&lt;meta name="viewport" content="width=device-width, initial-scale=1" /&gt;</code></pre><p>Atrybut <code>content</code> może przyjmować dodatkowe parametry, ale nas interesują tutaj dwa podstawowe:</p><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><p>Tak będzie wyglądał efekt z zastosowaniem meta tagu <code>viewport</code>:</p><p style="text-align:center;"><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"></p><p>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ć.</p><h2>Podsumowanie</h2><p>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.</p>

Frame 16.png

Dlaczego potrzebujemy na stronie meta tagu viewport?

<p>Nasz cel polegał na stworzeniu eleganckiego i minimalistycznego portfolio dla osoby świadczącej usługi fotograficzne.&nbsp;</p><h3>Estetyczny design</h3><p>Głównym celem było zaprojektowanie <strong>unikalnego designu</strong>, który będzie wyróżniał się subtelnym wyglądem i minimalistycznym układem, w którym dominującym elementem będą zdjęcia autorki.&nbsp;</p><p>Zamierzony efekt udało nam się uzyskać poprzez zastosowanie pastelowych barw oraz szeryfowej czcionki, która dodaje stronie elegancji.&nbsp;</p><p>Zadbaliśmy również o wygodne przeglądanie zdjęć poprzez możliwość ich szybkiego filtrowania oraz dynamicznego wczytywania podczas przewijania ekranu.</p><h3>Wykorzystane narzędzia</h3><p>Aby zapewnić szybkie działanie witryny, wykorzystaliśmy <strong>Next.js</strong> do wydajnego ładowania podstron oraz platformę <strong>Cloudinary</strong> do wygodnego wgrywania nowych zdjęć i ich pobierania w różnych rozdzielczościach.</p>

large_Frame 32.png

medium_Frame 32.png

small_Frame 32.png

thumbnail_Frame 32.png

Natalia Jasionek Photography

Node.js

Next.js

Cloudinary CDN

<p>Naszym zadaniem było zaprojektowanie i stworzenie sklepu internetowego dla firmy z Wysp Kanaryjskich, która zajmuje się sprzedażą odzieży surferskiej, artykułów rękodzielniczych oraz innych akcesoriów na rynku polskim i europejskim.&nbsp;</p><h3>UX/UI</h3><p>Podczas tworzenia designów strony chcieliśmy jak najlepiej oddać surferski charakter strony. Poprzez zastosowanie odpowiednich kolorów i ilustracji udało nam się podkreślić oceaniczny klimat, z którym kojarzą się produkty w sklepie. Aby zachować minimalistyczny wygląd strony, zdecydowaliśmy się na prosty podział na 5 głównych kategorii produktów.&nbsp;</p><p>Strona jest w pełni <strong>responsywna</strong> i gwarantuję wygodne zakupy na urządzeniach mobilnych. Zależało nam na tym, by interfejs był przygotowany tak, aby zapewnić jak najlepsze korzystanie z niego przez użytkowników.&nbsp;</p><h3>Rozwiązania techniczne</h3><p>Aby przeglądanie produktów było szybkie i przekładało się na wyższą konwersję, zdecydowaliśmy się na wykorzystanie <strong>Next.js</strong>, który jest świetnym narzędziem do ładowania dynamicznych stron.</p><p>Wymogiem przy tworzeniu sklepu była obsługa dwóch wersji językowych — polskiej i angielskiej — aby umożliwić zakupy użytkownikom z całej Europy. CMS został wyposażony w możliwość łatwego dodawania produktów w obu wariantach językowych.</p><h3>Dynamiczne płatności</h3><p>Aby obsłużyć płatności zarówno od klientów z Polski jak i zagranicy, zdecydowali się na wykorzystanie narzędzia <strong>Stripe</strong>, które oferuje znakomitą integrację z różnymi systemami płatności.</p>

Tworzymy strony i aplikacje w nowoczesnych technologiach

Projesjonalne i innowacyjne rozwiązania dla Twojej firmy.

Co możemy dla Ciebie zrobić?

Strony internetowe

Sklepy internetowe

Aplikacje webowe

Nasze ostatnie realizacje

Natalia Jasionek Photography

Bajahmade

Jak przebiega współpraca z nami?

Poznanie się i wycena

Projekt graficzny

Programowanie

Wdrożenie

Nasza strefa wiedzy

Uwierzytelnianie z Sign In With Google

Jak poprawanie zarządzać czasem w aplikacjach?

Dlaczego potrzebujemy na stronie meta tagu viewport?

Najczęściej zadawane pytania

Chcesz porozmawiać
o Twoim projekcie?

Tworzymy strony i aplikacje w nowoczesnych technologiach

Projesjonalne i innowacyjne rozwiązania dla Twojej firmy.

Co możemy dla Ciebie zrobić?

Strony internetowe

Sklepy internetowe

Aplikacje webowe

Nasze ostatnie realizacje

Natalia Jasionek Photography

Bajahmade

Jak przebiega współpraca z nami?

Poznanie się i wycena

Projekt graficzny

Programowanie

Wdrożenie

Nasza strefa wiedzy

Uwierzytelnianie z Sign In With Google

Jak poprawanie zarządzać czasem w aplikacjach?

Dlaczego potrzebujemy na stronie meta tagu viewport?

Najczęściej zadawane pytania

Jakie usługi oferujecie?

Jak przebiega proces tworzenia strony internetowej lub aplikacji?

Jak długo trwa realizacja strony?

Czy moja aplikacja będzie miała unikalny wygląd?

Jakich technologii używacie przy tworzeniu stron internetowych i aplikacji?

Czy oferujecie wsparcie po zakończeniu projektu?

Chcesz porozmawiać o Twoim projekcie?

Chcesz porozmawiać
o Twoim projekcie?