Heim > Web-Frontend > js-Tutorial > Hauptteil

NgSysV.Responsive/Adaptive Design

Susan Sarandon
Freigeben: 2024-11-27 21:13:09
Original
578 Leute haben es durchsucht

NgSysV.Responsive/Adaptive Design

Diese Beitragsserie ist auf NgateSystems.com indiziert. Dort finden Sie auch eine äußerst nützliche Stichwortsuchfunktion.

Letzte Bewertung: 24. November

1. Einführung

Beitrag 4.2 ergab, dass Sie Folgendes sicherstellen müssen, wenn Sie möchten, dass Ihre Webanwendung bei Websuchen angezeigt wird:

  • Ihre Webapp funktioniert gut, wenn sie auf dem kleinen Bildschirm eines Mobiltelefons angezeigt wird und
  • Alle Inhalte, die von Suchmaschinen indiziert werden sollen, sind in der mobilen Version sichtbar.

Wenn Ihre Software hauptsächlich für Desktop-Benutzer gedacht ist, ist das ein großes Ärgernis – aber so ist das Leben. Mal sehen, wie Sie das Problem systematisch angehen können.

2. Responsives Design mit Tailwind

Responsive Design nutzt die „eingebaute“ Fähigkeit des CSS-Stils, um die Breite des Anzeigegeräts zu testen und die Formatierung entsprechend anzupassen. Dies geschieht alles automatisch im Browser – Sie müssen jedoch immer noch explizite Anweisungen dazu geben, was an jedem „Haltepunkt“ (der Bildschirmbreite, bei der ein neuer breitenspezifischer Stil angewendet werden soll) geschehen soll.

Der Standard-CSS-Stil, den Sie bisher in dieser Serie verwendet haben, erzielt diese adaptiven Effekte durch die Verwendung einer Technik namens „Medienabfragen“. Aber in diesem Beitrag werde ich Ihnen eine „offene Bibliothek“ namens Tailwind vorstellen. Dies ist maßgeschneidert für reaktionsfähiges Styling und bietet viele zusätzliche Vorteile.

Hier ist ein Beispiel für den Tailwind-Stil, der eine zentrierte Überschrift auf 95 % der Bildschirmbreite auf Bildschirmen mit einer Breite von bis zu 768 Pixeln einschränkt. Oberhalb dieser Breite ist die zentrierte Überschrift auf 60 % der Bildschirmbreite beschränkt:

<h1>



<p>Previously in this series, you've seen styles applied to HTML elements like <p> by adding>

<p>The essence of Tailwind is that it provides a system of single-purpose "utility classes", each of which applies a specific set of styles to an element. The class names are chosen judiciously to provide a meaningful and practical expression of styling intentions. The example below styles a <p> element with 4rem padding on all four sides and a  background color of light gray.<br>
</p>

<pre class="brush:php;toolbar:false"><div>



<p>Here, in bg-blue-500, bg says that this is a background style, blue sets the background colour to blue and 500 sets the colour "intensity" to a mid-value on a scale of 100 (light) to 900 (dark).</p>

<p>This is fine in its way, but the system may only become of interest to you when I tell you that you can make the tailwind utility classes responsive by simply adding a prefix to the style.</p>

<p>Tailwind recognizes the following screen-width "breakpoints":</p>

<div><table>
<thead>
<tr>
<th>Prefix</th>
<th>Screen Size</th>
<th>Minimum Width</th>
</tr>
</thead>
<tbody>
<tr>
<td>sm</td>
<td>Small devices</td>
<td>640px</td>
</tr>
<tr>
<td>md</td>
<td>Medium devices</td>
<td>768px</td>
</tr>
<tr>
<td>lg</td>
<td>Large devices</td>
<td>1024px</td>
</tr>
<tr>
<td>xl</td>
<td>Extra large devices</td>
<td>1280px</td>
</tr>
<tr>
<td>2xl</td>
<td>2x Extra large devices</td>
<td>1536px</td>
</tr>
</tbody>
</table></div>

<p>A style class such as "bg-gray-200" might thus be made to apply only to screens larger than 640px by specifying it as "sm:bg-gray-200".</p>

<p>The "This div has padding on all sides." example above could thus be made to display its paragraph with a blue background on screens with a maximum width of 640px and green on screens larger than this by styling it as follows:<br>
</p>

<pre class="brush:php;toolbar:false"><p>



<p>Because classes to the right take precedence, this makes the default background blue and overrides this with green when the screen is large enough. </p>

<p>For a fuller account of the Tailwind system and instructions on how to istall this in your project please see the Tailwind Website.</p>

<h3>
  
  
  3. Adaptive design for Server-side rendered webapps
</h3>

<p>Responsive design won't help you achieve more drastic effects where the desktop and mobile versions of a webapp are seriously different. Whereas a <strong>responsive design</strong> adjusts a standard pattern"fluidly" to accommodate different screen sizes, an <strong>adaptive</strong> design is prepared to give screen widths tailor-made solutions. </p>

<p>Expanding on the "tailoring" theme, you might think of responsive design as creating a single suit made of stretchable fabric that fits anyone. By contrast, adaptive design is like creating multiple tailored suits for different body types.</p>

<p>So if, for example, you felt that the mobile customers for your webapp were completely different from your desktop fans, you might want to give each community a tailor-made design (while delivering both under the same URL). </p>

<p>Conceptually, the obvious way to express this arrangement would be a displayIsMobile boolean guiding the display of MobileLayout and DesktopLayout components, as follows:<br>
</p>

<pre class="brush:php;toolbar:false">{#if displayIsMobile}
  <MobileLayout />
{:else}
  <DesktopLayout />
{/if}
Nach dem Login kopieren
Nach dem Login kopieren
Nach dem Login kopieren

Aber Sie werden sich jetzt fragen: „Wie soll dieser displayIsMobile-Boolesche Wert initialisiert werden?“

Wenn ein Server eine Browser-Anfrage für myURL/myPage empfängt, wird normalerweise als Erstes eine Load()-Funktion in einer page.server.js-Datei ausgeführt, die serverseitig ausgeführt wird, um die Anfangsdaten bereitzustellen für die Seite. Wenn page.svelte für myPage – auch serverseitig ausgeführt – diese Daten empfängt, möchte es eine erste Darstellung seines „Vorlagen“-Abschnitts durchführen und einen HTML-Block an den Browser zurücksenden. Dazu ist jedoch ein Wert für displayIsMobile erforderlich.

Wenn Sie „clientseitig“ ausführen würden, wäre die Antwort einfach: Verwenden Sie das „window“-Objekt, um window.width zu überprüfen und displayIsMobile entsprechend festzulegen. Aber in diesem Fall können weder die Datei „page.server.js“ noch die Datei „page.svelte“, die serverseitig ausgeführt wird, den Client direkt abfragen.

Eine Möglichkeit könnte darin bestehen, einen geeigneten Standardwert für displayIsMobile auszuwählen und eine Standardanzeige zurückzugeben. Sie könnten dann eine onMount()-Funktion auf dem Client verwenden, um dessen Fenstereigenschaften zu überprüfen und die Standardanzeige angemessener neu zu rendern. Es würden jedoch zwei Konsequenzen folgen:

  • Das erneute Rendern der ursprünglichen Anzeige würde einen unangenehmen „Flacker“-Effekt auf dem Client-Gerät erzeugen, wenn jede Seite gestartet und dann erneut gerendert wird.
  • SEO würde wahrscheinlich ernsthaft beschädigt werden, da Webcrawler (die möglicherweise nicht immer JavaScript ausführen) möglicherweise nicht den richtigen Inhalt sehen.

Wenn Sie das also richtig machen wollen, müssen Sie müssen eine Möglichkeit finden, displayisMobile auf dem Server entsprechend einzustellen. Auf diese Weise senden Sie so schnell wie möglich eine vollständig gerenderte Seite an den Kunden und optimieren so sowohl Leistung als auch SEO.

Wenn Sie Beitrag 3.5 gelesen haben, werden Sie sich daran erinnern, dass die „Header“, die einer Serveranfrage beiliegen, zur Übermittlung hilfreicher Informationen verwendet werden können. Könnten die Header für die Anfrage eines Browsers für die Seite myURL/myPage etwas Nützliches sagen?

Zum Glück lautet die Antwort „Ja – das tun sie“. Beispielsweise enthält der User-Agent-Header „browser-requests“ eine „Engine and Browser“-Komponente, die verwendet werden kann, um Ihnen mitzuteilen, dass die Anfrage von einem mobilen Browser und nicht von einem Desktop-Browser kommt. Aber der User-Agent-Request-Header hat seine Wurzeln in der düstersten Vergangenheit der Computerbranche und seine Funktionalität hat Schwierigkeiten, mehrere konkurrierende Interessen auszugleichen.

Das Hauptproblem hierbei war die Sorge, dass eine zu genaue Beschreibung der Benutzerumgebung (die Kopfzeile enthält auch Details zum Browser des Benutzers, zum Typ und der Version des Betriebssystems usw.) dazu verwendet werden könnte, Benutzer beim Navigieren in der Umgebung zu identifizieren und zu verfolgen Web. Dieses Problem bleibt ungelöst.

Hier ist ein Beispiel für einen „Benutzeragenten“:

<h1>



<p>Previously in this series, you've seen styles applied to HTML elements like <p> by adding>

<p>The essence of Tailwind is that it provides a system of single-purpose "utility classes", each of which applies a specific set of styles to an element. The class names are chosen judiciously to provide a meaningful and practical expression of styling intentions. The example below styles a <p> element with 4rem padding on all four sides and a  background color of light gray.<br>
</p>

<pre class="brush:php;toolbar:false"><div>



<p>Here, in bg-blue-500, bg says that this is a background style, blue sets the background colour to blue and 500 sets the colour "intensity" to a mid-value on a scale of 100 (light) to 900 (dark).</p>

<p>This is fine in its way, but the system may only become of interest to you when I tell you that you can make the tailwind utility classes responsive by simply adding a prefix to the style.</p>

<p>Tailwind recognizes the following screen-width "breakpoints":</p>

<div><table>
<thead>
<tr>
<th>Prefix</th>
<th>Screen Size</th>
<th>Minimum Width</th>
</tr>
</thead>
<tbody>
<tr>
<td>sm</td>
<td>Small devices</td>
<td>640px</td>
</tr>
<tr>
<td>md</td>
<td>Medium devices</td>
<td>768px</td>
</tr>
<tr>
<td>lg</td>
<td>Large devices</td>
<td>1024px</td>
</tr>
<tr>
<td>xl</td>
<td>Extra large devices</td>
<td>1280px</td>
</tr>
<tr>
<td>2xl</td>
<td>2x Extra large devices</td>
<td>1536px</td>
</tr>
</tbody>
</table></div>

<p>A style class such as "bg-gray-200" might thus be made to apply only to screens larger than 640px by specifying it as "sm:bg-gray-200".</p>

<p>The "This div has padding on all sides." example above could thus be made to display its paragraph with a blue background on screens with a maximum width of 640px and green on screens larger than this by styling it as follows:<br>
</p>

<pre class="brush:php;toolbar:false"><p>



<p>Because classes to the right take precedence, this makes the default background blue and overrides this with green when the screen is large enough. </p>

<p>For a fuller account of the Tailwind system and instructions on how to istall this in your project please see the Tailwind Website.</p>

<h3>
  
  
  3. Adaptive design for Server-side rendered webapps
</h3>

<p>Responsive design won't help you achieve more drastic effects where the desktop and mobile versions of a webapp are seriously different. Whereas a <strong>responsive design</strong> adjusts a standard pattern"fluidly" to accommodate different screen sizes, an <strong>adaptive</strong> design is prepared to give screen widths tailor-made solutions. </p>

<p>Expanding on the "tailoring" theme, you might think of responsive design as creating a single suit made of stretchable fabric that fits anyone. By contrast, adaptive design is like creating multiple tailored suits for different body types.</p>

<p>So if, for example, you felt that the mobile customers for your webapp were completely different from your desktop fans, you might want to give each community a tailor-made design (while delivering both under the same URL). </p>

<p>Conceptually, the obvious way to express this arrangement would be a displayIsMobile boolean guiding the display of MobileLayout and DesktopLayout components, as follows:<br>
</p>

<pre class="brush:php;toolbar:false">{#if displayIsMobile}
  <MobileLayout />
{:else}
  <DesktopLayout />
{/if}
Nach dem Login kopieren
Nach dem Login kopieren
Nach dem Login kopieren

Ich denke, es ist leicht genug, die Probleme zu erkennen, die bei der Analyse dieses Durcheinanders auftreten würden!

Aber es gibt auch andere Möglichkeiten. Eine aktuelle Initiative von Google schlug vor, dass Browser einen neuen, viel einfacheren Header namens sec-ch-ua-mobile bereitstellen sollten. Diese enthält eine einfache Zeichenfolge, die Ihnen sagt, ob der Browser eine mobile Antwort erwartet (siehe Sec-CH-UA-Mobile für Details).

Der sec-ch-ua-mobile-Header ist zwar jetzt in Chrome und Edge verfügbar, andere Browser unterstützen die Initiative jedoch nicht unbedingt. Auf jeden Fall liefert Ihnen der sec-ch-ua-mobile-Header nicht genügend Details, um Ihre Antwort zu verfeinern und beispielsweise eine explizite „Tablet“-Version bereitzustellen.

Das ist alles sehr mühsam, aber es kann für Sie ausreichen, zu dem Schluss zu kommen, dass Sie mit sec-ch-ua-mobile als erster Anlaufstelle und dem User-Agent als Ausweichlösung zufrieden sind. In diesem Fall finden Sie hier Code, um einer page.svelte-Datei eine displayIsMobile-Variable zuzuweisen.

Verwirrenderweise beginnt es mit einem neuen Typ einer Svelte-Datei namens „hooks.server.js“-Datei.

Während Sie möglicherweise den Code zum Festlegen von displayIsMobile für eine page.svelte-Datei in eine Load()-Funktion einfügen, verfügt nicht jede page.svelte-Seite über einen dieser Codes. Und selbst wenn dies der Fall wäre (und Sie können natürlich immer einen erstellen), müssten Sie den displayIsMobile-Code in allen Load()-Funktionen duplizieren.

Im Gegensatz dazu ist die Datei „hooks.server.js“ eine Art „Super“-Load()-Funktion, die Svelte für jede an den Server gesendete Anfrage startet. Es wird ausgeführt, bevor eine andere Aktivität ausgeführt wird. Dies macht es zum perfekten Ort, um den sec-ch-ua-mobile-Header zu überprüfen und einen Wert für displayIsMobile zu erstellen.

Der folgende Code zeigt, wie displayIsMobile durch eine Hooks.server.js-Datei erstellt werden könnte. Es zeigt auch, wie dieser Wert an die erwartete page.svelte-Datei zurückübermittelt werden könnte.

<h1>



<p>Previously in this series, you've seen styles applied to HTML elements like <p> by adding>

<p>The essence of Tailwind is that it provides a system of single-purpose "utility classes", each of which applies a specific set of styles to an element. The class names are chosen judiciously to provide a meaningful and practical expression of styling intentions. The example below styles a <p> element with 4rem padding on all four sides and a  background color of light gray.<br>
</p>

<pre class="brush:php;toolbar:false"><div>



<p>Here, in bg-blue-500, bg says that this is a background style, blue sets the background colour to blue and 500 sets the colour "intensity" to a mid-value on a scale of 100 (light) to 900 (dark).</p>

<p>This is fine in its way, but the system may only become of interest to you when I tell you that you can make the tailwind utility classes responsive by simply adding a prefix to the style.</p>

<p>Tailwind recognizes the following screen-width "breakpoints":</p>

<div><table>
<thead>
<tr>
<th>Prefix</th>
<th>Screen Size</th>
<th>Minimum Width</th>
</tr>
</thead>
<tbody>
<tr>
<td>sm</td>
<td>Small devices</td>
<td>640px</td>
</tr>
<tr>
<td>md</td>
<td>Medium devices</td>
<td>768px</td>
</tr>
<tr>
<td>lg</td>
<td>Large devices</td>
<td>1024px</td>
</tr>
<tr>
<td>xl</td>
<td>Extra large devices</td>
<td>1280px</td>
</tr>
<tr>
<td>2xl</td>
<td>2x Extra large devices</td>
<td>1536px</td>
</tr>
</tbody>
</table></div>

<p>A style class such as "bg-gray-200" might thus be made to apply only to screens larger than 640px by specifying it as "sm:bg-gray-200".</p>

<p>The "This div has padding on all sides." example above could thus be made to display its paragraph with a blue background on screens with a maximum width of 640px and green on screens larger than this by styling it as follows:<br>
</p>

<pre class="brush:php;toolbar:false"><p>



<p>Because classes to the right take precedence, this makes the default background blue and overrides this with green when the screen is large enough. </p>

<p>For a fuller account of the Tailwind system and instructions on how to istall this in your project please see the Tailwind Website.</p>

<h3>
  
  
  3. Adaptive design for Server-side rendered webapps
</h3>

<p>Responsive design won't help you achieve more drastic effects where the desktop and mobile versions of a webapp are seriously different. Whereas a <strong>responsive design</strong> adjusts a standard pattern"fluidly" to accommodate different screen sizes, an <strong>adaptive</strong> design is prepared to give screen widths tailor-made solutions. </p>

<p>Expanding on the "tailoring" theme, you might think of responsive design as creating a single suit made of stretchable fabric that fits anyone. By contrast, adaptive design is like creating multiple tailored suits for different body types.</p>

<p>So if, for example, you felt that the mobile customers for your webapp were completely different from your desktop fans, you might want to give each community a tailor-made design (while delivering both under the same URL). </p>

<p>Conceptually, the obvious way to express this arrangement would be a displayIsMobile boolean guiding the display of MobileLayout and DesktopLayout components, as follows:<br>
</p>

<pre class="brush:php;toolbar:false">{#if displayIsMobile}
  <MobileLayout />
{:else}
  <DesktopLayout />
{/if}
Nach dem Login kopieren
Nach dem Login kopieren
Nach dem Login kopieren

DisplayIsMobile befindet sich jetzt im Ereignisobjekt für die Browseranforderung. Dieses Ereignis ist ein komplexes Objekt, das von SvelteKit erstellt wurde, um die aktuelle Anforderung darzustellen. Es enthält Eigenschaften wie:

  • event.request: Dies ist das ursprüngliche Request-Objekt, das Details wie die HTTP-Methode (GET, POST usw.), Header, URL und Text enthält.
  • event.locals: Ein Ort, an dem diese Daten während des gesamten nachfolgenden Lebenszyklus der Anfrage verfügbar gemacht werden.

Wie Sie sich vorstellen können, ist event.locals genau das, was Sie brauchen, um displayIsMobile ein Zuhause zu bieten, da die Veranstaltung nun überall dort verfügbar ist, wo sie benötigt wird.

Die Form des Arguments {event, Response} für handle() kann Sie verwirren. Dies ist ein Beispiel für die „Destrukturierung“ der Syntax. Dadurch können Sie bestimmte Eigenschaften direkt aus einem Objekt extrahieren, ohne auf das Objekt selbst zu verweisen. Stellen Sie sich vor, es gibt ein Superobjekt args, das Ereignis und Antwort als Eigenschaften enthält. Dann anstatt das Konventionelle zu verwenden

User-Agent: Mozilla/4.9 Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Nach dem Login kopieren

„destrukturierende Syntax“ ermöglicht es Ihnen, dies zu schreiben als

// src/hooks.server.js
export async function handle({ event, resolve }) {

    let displayIsMobile;
    console.log("event.request.headers['sec-ch-ua-mobile']: ", event.request.headers.get('sec-ch-ua-mobile'));
    // First, try to get the mobile flag from the 'sec-ch-ua-mobile' header. This is a string header
    // and its value is '?1' if the user agent is a mobile device, otherwise it is '?0'.
    if (event.request.headers.get('sec-ch-ua-mobile') !== undefined) {
        displayIsMobile = event.request.headers.get('sec-ch-ua-mobile') === '?1' ? true : false;
    } else {
        // Otherwise, try the 'user-agent' header. For robust mobile detection, you might consider using
        // the ua-parser-js library. It provides consistent results across various edge cases.
        if (event.request.headers.get('user-agent') !== undefined) {
            displayIsMobile = event.request.headers.get('user-agent').toLowerCase().includes('mobile');
        } else {
            displayIsMobile = false
        }
    }

    // Put displayIsMobile into event.locals. This is an object provided by SvelteKit that is specific to a
    // particular browser request and which is acessible in every page and layout. In brief, event.locals lets
    // you pass data throughout the lifecycle of a request in SvelteKit. It provides a convenient way to share
    // computed values or state without needing to repeat logic or fetch data multiple times.
    event.locals.displayIsMobile = displayIsMobile;

    // Proceed with the request. In SvelteKit, resolve(event) is crucial for handling the request lifecycle.
    // It processes the current request and generates the final response that will be sent back to the client.
    const response = await resolve(event);
    return response;
}
Nach dem Login kopieren

Im Wesentlichen ist dies eine Möglichkeit, auf Eigenschaften (args.event usw.) eines Objektarguments zu verweisen, ohne den Namen des übergeordneten Objekts (args) zu kennen. Dies führt zu einem strafferen, widerstandsfähigeren Code.

Wie auch immer, nachdem displayIsMobile jetzt im Ereignisobjekt für die Browseranforderung sitzt, ist es naheliegend, eine Load()-Funktion in einer page.server.js-Datei zu verwenden, um es auszugraben und zurückzugeben es zu page.svelte.

function handle(args) {
    const event = args.event;
    const resolve = args.resolve;
    // ... (code referencing variables "event" and "resolve")
}
Nach dem Login kopieren

Hier ist also endlich die sehr einfache page.svelte-Datei zum Bereitstellen einer adaptiven Seite

function handle({ event, resolve }) {
    // ...(code referencing variables "event" and "resolve")
}
Nach dem Login kopieren

Ich hoffe, es hat dir gefallen!

Zusammenfassend lautet die vollständige Sequenz:

  1. Der Sveltekit-Server übermittelt die myURL/myPage-Anfrage des Browsers und startet die Datei „hooks.server.js“ des Projekts. Hier werden die Anforderungsheader abgerufen, ein geeigneter displayIsMobile-Wert ermittelt und das Ergebnis im Sveltekit-Ereignisobjekt versteckt.
  2. Die Funktion „load()“ in der Datei „page.server.j“ für die Route „myPage“ ruft displayIsMobile aus dem Ereignis ab und gibt es an page.svelte zurück
  3. Die Datei page.svelte ruft den data.displayIsMobile-Wert ab und verwendet ihn in ihrem Vorlagenabschnitt, um entsprechenden HTML-Code zu generieren.
  4. Sveltekit erstellt Skripte für den Browser, um interaktives Verhalten hinzuzufügen. Tailwind-Referenzen werden bereits während der Seitenerstellung in CSS-Medienabfragen umgewandelt.
  5. Der Browser empfängt diesen HTML-Code, „hydratisiert“ ihn mit den Sveltekit-Skripten und rendert ihn auf dem Clientgerät gemäß den Anweisungen der Medienabfragen.

Sobald die Seite mit Feuchtigkeit versorgt ist, ist die Reaktivität ein rein kundenseitiges Problem. Ein SvelteKit {#if popupIsVisible im Vorlagenabschnitt Ihres Codes wird zu einer kompilierten Funktion, die DOM-Elemente basierend auf popupIsVisible.

umschaltet

Das obige ist der detaillierte Inhalt vonNgSysV.Responsive/Adaptive Design. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Quelle:dev.to
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Neueste Artikel des Autors
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage