|
|
| (66 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| {{TBD|Anpassung an Teil 4 des Tutoriums.}}
| |
| {{HTML5-Tutorium:JavaScript:HelloWorld:Menü}} | | {{HTML5-Tutorium:JavaScript:HelloWorld:Menü}} |
| '''Musterlösung''': [https://glossar.hs-augsburg.de/beispiel/tutorium/es5/hello_world/WK_HelloWorld05/index.html <code>index.html</code>]
| |
| ([https://glossar.hs-augsburg.de/beispiel/tutorium/es5/hello_world/WK_HelloWorld05/ SVN-Repository]; nach Download: <code>npm update</code>)
| |
| ==Anwendungsfälle (Use Cases)==
| |
| Gegenüber dem [[HTML5-Tutorium:_JavaScript:_Hello_World_03|dritten]] und
| |
| [[HTML5-Tutorium:_JavaScript:_Hello_World_04|vierten Teil des Tutoriums]]
| |
| ändern sich die Anwendungsfälle nicht. Die Anwendung leistet also genau dasselbe wie zuvor.
| |
|
| |
|
| In diesem Teil des Tutoriums geht es darum, die Anwendung zu verbessern, so dass sie schneller ausgeliefert werden kann.
| | '''Musterlösung'''<br/> |
| Außerdem wird die Entwicklungsarbeit mit Hilfe von Automatisierungstools erleichtert.
| | v01: [https://glossar.hs-augsburg.de/beispiel/tutorium/2024/wk_hello_world/wk_hello_world_06/web_v01/index.html <code>index.html</code>] ([https://validator.nu/?doc=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2024%2Fwk_hello_world%2Fwk_hello_world_06%2Fweb_v01%2Findex.html HTML validate])<br/> |
| | v02: [https://glossar.hs-augsburg.de/beispiel/tutorium/2024/wk_hello_world/wk_hello_world_06/web_v02/index.html <code>index.html</code>] ([https://validator.nu/?doc=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2024%2Fwk_hello_world%2Fwk_hello_world_06%2Fweb_v02%2Findex.html HTML validate]; Modularisierung analog zu [[HTML5-Tutorium: JavaScript: Hello World 04|Hello World 04]] v02)<br/> |
| | v03: [https://glossar.hs-augsburg.de/beispiel/tutorium/2024/wk_hello_world/wk_hello_world_06/web_v03/index.html <code>index.html</code>] ([https://validator.nu/?doc=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2024%2Fwk_hello_world%2Fwk_hello_world_06%2Fweb_v03%2Findex.html HTML validate]; Konfiguration mittels JSON analog zu [[HTML5-Tutorium: JavaScript: Hello World 04|Hello World 04]] v03)<br/> |
| | [{{Git-Server}}/kowa/wk_hello_world_06.git Git-Repository] |
|
| |
|
| ==Erstellen eines neuen Projektes== | | ==Anwendungsfälle (Use Cases)== |
| | | Gegenüber dem [[HTML5-Tutorium:_JavaScript:_Hello_World_05|dritten, vierten und fünften Teil des Tutoriums]] |
| Erstellen Sie ein neues Projekt „<code>HelloWorld05</code>“ und legen Sie dieses in Ihrem Repository ab.
| | ändern sich die die Anwendungsfälle nicht. Die Anwendung leistet also genau dasselbe wie zuvor. |
| Kopieren Sie anschließend alle Dateien aus dem vierten Teil des Tutoriums und passen Sie den Titel in der HTML-Datei an
| |
| | |
| Fügen Sie ins Wurzelverzeichnis Ihres Porjektes einen neuen Ordner namens „<code>src</code>“ ein und verschieben
| |
| Sie die Ordner „<code>web/css</code>“ und „<code>web/js</code>“ in diesen Ordner. Der <code>src</code>-Ordner enthält
| |
| künftig die von Ihnen erstellten JavaScript- und CSS-Sourcen. Mit Hilfe von Node.js-Tools werden im <code>web</code>-Ordner
| |
| komprimierte Versionen dieses Dateien erstellt.
| |
| | |
| Zu guter Letzt committen Sie abermals.
| |
| | |
| ===Node.js===
| |
|
| |
|
| Dieses Tutorium befasst sich zwar nicht mit der Erstellung von Node.js-Server-Anwendungen, aber trotzdem benötigen wir
| | In diesem Teil des Tutoriums geht es darum, CSS durch SCSS zu ersetzen, um den CSS-Code „[[DRY]] zu machen“. |
| [[Node.js]], da für die Komprimierung von Dateien und das automatische Erstellen von JavaScript-Dokumentationen | |
| Tools zum Einsatz kommen, die mit Hilfe von Node entwicklet wurden.
| |
|
| |
|
| Installieren Sie zunächst Node.js: <code>https://nodejs.org/en/</code>, Version 6.x. Diverse Versionen finden Sie unter https://nodejs.org/en/download/.
| | == Erstellen eines neuen Projekts == |
| Achten Sie darauf, dass die Option „<code>Add to PATH</code>“ ausgewählt wurde.
| |
|
| |
|
| Starten Sie WebStorm neu und öffnen Sie das Terminal, um zu testen, ob <code>node</code> funktioniert:
| | Erstellen Sie ein neues Projekt <code>hello_world_06</code> als Fork von <code>hello_world_05</code>. |
|
| |
|
| * Klick auf Icon in der linken unteren Ecke → <code>Terminal</code>
| | ==SCSS== |
| * Geben Sie Folgendes ins Terminal ein: <code>node --version</code>
| |
|
| |
|
| Wenn Node.js korrekt installiert und der Pfad mit den <code>node</code>-Binaries in die Systemvariable <code>PATH</code> eingetragen wurde,
| | Anstelle von CSS-Dateien verwenden Sie künftig SCSS-Dateien. Das ist zunächst einmal nicht weiter schwer, |
| sollte die Versionsnummer von <code>node</code> ausgegeben werden.
| | das jede CSS-Datei automatisch auch eine SCSS-Datei ist. Bei der Verwendung von CSS können Sie |
| | allerdings das Prinzip „[[Don't repeat yourself]]“ (DRY) nicht beachten. Sie müssen für verschiedene Elemente |
| | ständig Informationen wiederholen (gewünschter Font, Hintergrundfarbe, Größenangaben etc.). Deshalb |
| | gibt es mehrere Projekte wie {{zB}} [[LESS]], [[Sass]]/SCSS, [[Stylus]], die den CSS-Standard erweitern, um dieses Problem |
| | zu vermeiden. Sass verwendet allerdings eine ganz andere Syntax als CSS. Allerdings |
| | unterstützt das Sass-Projekt auch die Sprache SCSS, die CSS einfach um weitere syntaktische Elemente ergänzt. |
| | Zum Beispiel kann man in SCSS Konstanten definieren: |
|
| |
|
| Sie werden feststellen, das Node.js zum Großteil über Terminal-Befehle gesteuert wird.
| | <source lang="CSS"> |
| Zu Beginn mag das für eingefleischte [[Klickibunti]]-Fans ungewohnt sein, aber Sie werden sich schnell daran gewöhnen.
| | $font-family-serif: "Times New Roman", Times, serif; |
| | |
| '''Tipp'''<br/>
| |
| Profis verwenden unter Windows lieber ein Terminal, das eine [[Unix]]-[[Shell]] simuliert.
| |
| (Unter Linux und Mac OS X ist das nicht notwendig. Dort läuft sowieso schon eine UNIX-Shell.)
| |
| | |
| Installieren Sie „Git for Windows“ (https://git-for-windows.github.io/). In diesem Paket ist die „Git BASH“ enthalten.
| |
| Das ist eine Terminal-Anwendung, die eine Linux-Bash emuliert und zahlreiche nützliche Befehle wie „<code>which</code>“, „<code>[[vi]]</code>“ ( :-) ) etc. zur
| |
| Verfügung stellt.
| |
| | |
| Öffnen Sie nun ein beliebiges Terminal (WebStorm-Terminal, Git Bash, Mac-OS-X-Terminal ...)
| |
| und geben Sie folgenden Befehl ein (npm = node package manager, https://www.npmjs.com/)
| |
| | |
| <source lang="bash"> | |
| npm install -g bower grunt-cli jsdoc yuglify mincss coffee-script jshint
| |
| </source> | | </source> |
|
| |
|
| Damit werden die wichtigsten Node.js-Pakete ''global'' (Option „<code>-g</code>“) installiert, die wir im Folgenden noch benötigen.
| | Und nun kann man in eine SCSS-Datei anstelle von <code>"Times New Roman", Times, serif</code> stets <code>$font-family-serif</code> |
| Die globale Installation hat zur Folge, dass jedes Projekt auf diese Pakete zugreifen kann, Pakete also nicht mehrfach installiert werden müssen.
| | schreiben, um den Font von bestimmten Elementen zu definieren. |
|
| |
|
| Als nächstes initialisieren Sie den Node-Paket-Manager „<code>npm</code>“ (https://docs.npmjs.com/) sowie Grunt (http://gruntjs.com/) .
| | <source lang="CSS"> |
| Grunt ist '''der''' “JavaScript Task Runner”, also ein Programm, das Aufgaben (''tasks'') wie {{zB}} das Komprimieren von Programmdateien
| | p |
| durchführt.
| | { font-family: $font-family-serif; } |
|
| |
|
| Die Initialisierung erfolgt durch die Bereitstellung von zwei Dateien „<code>package.json</code>“
| | label |
| und „<code>gruntfile.json</code>“ im Root-Verzeichnis der Web-Anwendung. Eine initiale Version der <code>package.json</code> könnten Sie theoretisch mit
| | { font-family: $font-family-serif; } |
| <code>npm init</code> erstellen. Einfacher ist es jedoch, wenn Sie die beiden Dateien von Hand erstellen und folgenden Code einfügen:
| |
| | |
| '''<code>package.json</code>''' (https://docs.npmjs.com/files/package.json)
| |
| <source lang="bash">
| |
| {
| |
| "name": "hello_world_04",
| |
| "version": "1.0.0",
| |
| "description": "Hello World tutorial",
| |
| "main": "gruntfile.js",
| |
| "directories": {
| |
| "doc": "./doc"
| |
| },
| |
| "dependencies": {},
| |
| "devDependencies": {
| |
| },
| |
| "scripts": {
| |
| "test": "echo \"Error: no test specified\" && exit 1"
| |
| },
| |
| "repository": {
| |
| "type": "svn",
| |
| "url": "https://glossar.hs-augsburg.de/kowa/tutorium/es5/hello_world/WK_HelloWorld05"
| |
| },
| |
| "author": "Wolfgang Kowarschick",
| |
| "license": "CC-BY-NC-SA-4.0"
| |
| } | |
| </source> | | </source> |
|
| |
|
| Anmerkung: Diese Datei wird durch <code>npm</code> automatisch erstellt und geändert. Daher ist das Layout (welches mir nicht gefällt) vorgegeben.
| | Wenn man nun diesen Font ändern will, |
| | muss das nicht mehr bei allen Elementen einzeln passieren. Es reicht, die Konstantendefinition abzuändern. |
| | Der SCSS-Code ist nun DRY. |
|
| |
|
| Hier sollten Sie natürlich nicht meinen Repositorypfad und meinen Namen einfügen, sondern jeweils Ihren. Sie können außerdem die
| | ==== Weiterentwicklung von CSS ==== |
| Lizenz, unter die Sie Ihre Software stellen, anpassen (https://spdx.org/licenses/), wenn Sie das möchten.
| |
|
| |
|
| Die meisten Attribute sind selbsterklärend. Wichtig sind für uns vor allem zwei Attribute: „<code>main</code>“ und
| | CSS entwickelt sich stetig weiter. Seit einiger Zeit werden auch hier Variablen unterstützt: |
| „<code>devDependencies</code>“. Das erste enthält den Namen der Konfigurationsdatei von Grunt. Diese fehlt noch. Also: Legen Sie sie an:
| |
|
| |
|
| '''<code>gruntfile.js</code>'''
| | <source lang="CSS"> |
| <source lang="javascript"> | | :root |
| module.exports = function(grunt)
| | { --font-family-serif: "Times New Roman", Times, serif; } |
| {
| |
| // Project configuration.
| |
| grunt.initConfig
| |
| ({
| |
| pkg: grunt.file.readJSON('package.json'),
| |
| });
| |
|
| |
|
| // Load the plugin that provides the "uglify" task.
| | p |
| | { font-family: var(--font-family-serif); } |
|
| |
|
| // Default task(s).
| | label |
| }; | | { font-family: var(--font-family-serif); } |
| </source> | | </source> |
|
| |
|
| Diese Datei ist noch ziemlich leer, aber das wird sich ändern.
| | Auch die Möglichkeit, Werte zu berechnen, gibt es in der Zwischenzeit (SCSS: <code>math</code>, CSS: <code>calc</code>). |
| | Das heißt, die Bedeutung von SCSS, Less etc. schwindet. Aber zurzeit bieten sie immer noch genügend mächtige Erweiterungen gegenüber CSS, |
| | wie {{zB}} die Möglichkeit, CSS-Elemente zu verschachteln, sodass sich der Einsatz von SCSS noch lohnt. |
|
| |
|
| Vorausschauend sollten Sie eine überflüssige WebStorm-Fehlerprüfung deaktivieren, da anderenfalls künftige Versionen
| | ==== Transformation von SCSS in CSS ==== |
| Versionen der Datei „<code>gruntfile.js</code>“ jedes Mal eine Fehlermeldung zur Folge haben, wenn die
| |
| Datei ins SVN-Repository geschrieben werden soll:
| |
|
| |
|
| * <code>File</code> bzw. <code>WebStorm</code> → <code>Settings</code> bzw. <code>Preferences</code> → <code>Editor</code> → <code>Inspections</code>
| | Leider unterstützt kein Browser SCSS direkt (im Gegensatz zu CSS). Aber für was gibt es Transpiler, die eine SCSS-Datei |
| * <code>JavaScript</code> aufklappen → <code>General</code> aufklappen → <code>Unsued JavaScript / ActionScript global symbol</code> deselektieren
| | automatisch in eine CSS-Datei übersetzen können. Vite unterstützt CSS-Transpiler von Haus aus. Man muss den gewünschten Transpiler lediglich installieren: |
| * <code>OK</code>
| |
| | |
| Spannender ist in der Datei „<code>package.json</code>“ das Attribut „<code>devDependencies</code>“ (dev = developer).
| |
| Diese enthält eine Liste von von NodeJS-Paketen, die für die Entwicklung der Web-Anwendung benötigt werden.
| |
| Fügen wir einmal das Paket „<code>ink-docstrap</code>“ in diese Liste ein.
| |
| (Diese Pakte wird nachfolgend für die Erstellung der JavaScript-Dokumentation mittels JSDoc verwendet.
| |
| Es enthält ein Theme, welches deutlich schöner ist als das Standard-JSDoc-Theme.)
| |
| | |
| Führen Sie folgenden Befehl im WebStorm-Terminal (oder mittels eine beliebigen anderen Shell im Wurzelverzeichnis Ihrer Web-Anwendung) aus:
| |
|
| |
|
| <source lang="bash"> | | <source lang="bash"> |
| npm install ink-docstrap --save-dev | | npm i -D sass |
| </source> | | </source> |
|
| |
|
| Dies bewirkt zweierlei:
| | Benennen Sie die Datei <code>src/css/body.css</code> in <code>src/css/body.scss</code> um. Ersetzen Sie außerdem |
| | in der Datei <code>src/js/main.js</code> den Import-Befehl |
|
| |
|
| # Das Node.js-Paket „<code> ink-docstrap</code>“ sowie diverse weitere Node.js-Pakete, die diese Paket benötigt, werden einem Projektordner namens „<code>node_modules</code>“ abgelegt.
| | <source lang="javascript"> |
| # Das Name und die Versionsnummer des Paketes werden in das Attribut „<code>devDependencies</code>“ in der Datei „<code>package.json</code>“ eingefügt (wegen der Option „<code>--save-dev</code>“).
| | import '/css/body.css'; |
| | |
| Nun steht Ihnen der Befehl
| |
| <source lang="bash"> | |
| npm update
| |
| </source> | | </source> |
| zur Verfügung. Mit diesem können Sie die lokal gespeicherte Versionen der im Attribut „<code>devDependencies</code>“ aufgeführte Node.js-Pakete
| |
| jederzeit auf die neueste Version aktualisieren. Sie können ein Paket auch löschen und dann mittels <code>npm update</code> (https://docs.npmjs.com/cli/update) wieder herstellen.
| |
| Versuchen Sie es:
| |
|
| |
|
| <source lang="bash">
| | durch |
| npm remove ink-docstrap
| |
| npm list
| |
| </source>
| |
|
| |
|
| Jetzt ist der Ordner „<code>node_modules</code>“ wieder leer.
| | <source lang="javascript"> |
| | | import '/css/body.scss'; |
| <source lang="bash"> | |
| npm update
| |
| npm list
| |
| </source> | | </source> |
|
| |
|
| Und jetzt enthält der wieder „<code>ink-docstrap</code>“ sowie andere dafür notwendige Pakete.
| | Wenn Sie Ihren Code nun mittels <code>npm run dev</code> laufen lassen oder mittels <code>npm run build</code> übersetzen, |
| | sollte die Anwendung noch funktionieren, da der SASS-Loader die neue SCCS-Datei in geeigneten CSS-Code übersetzt. |
|
| |
|
| Sie können auch überprüfen, ob Sie in Ihrem Projekt irgendwelche veralteten Pakete benutzen (https://docs.npmjs.com/cli/outdated):
| | Schwieriger ist der direkte Import von <code>head.scss</code> in der Datei <code>index.html</code>, |
| <source lang="bash"> | | da diese SCSS-Datei von Vite nicht in CSS transformiert wird. Ein Workaround für dieses Problem wird später vorgestellt. |
| npm outdated
| |
| </source> | |
|
| |
|
| Kein Ergebnis ist hier ein gutes Ergebnis!
| | ===Vite-Konfiguration=== |
|
| |
|
| Und natürlich funktioniert das Ganze auch für global gespeicherte Pakete:
| | Fügen Sie <code>"config"</code> als Abkürzung für <code>"./src/css/_config.scss"</code> in die Datei <code>vite.config.js</code> ein. |
| | |
| <source lang="bash"> | |
| npm -g outdated
| |
| npm -g list
| |
| </source> | |
| | |
| Allerdings muss man veraltete globale Pakete erneut installieren. Zum Beispiel muss <code>npm</code>
| |
| relativ häufig aktualisiert werden (sobald „<code>npm -g outdated</code>“ das Paket als veraltet meldet):
| |
| | |
| <source lang="bash">
| |
| npm install -g npm
| |
| </source>
| |
| | |
| ==Ausschließen diverser Dateien von automatischer Speicherung und/oder Überprüfung==
| |
| | |
| Sie sollten unbedingt verhindern das Node.js-Modulateien ins Repository geschrieben werden. Da sit, wie Se zuvor gesehen haben,
| |
| überflüssig und nimmt '''sehr viel''' Zeit in Anspruch, da es sich um Hunderte von Dateien handelt:
| |
| | |
| * Rechtsklick im Dateibaum auf <code>node_modules</code> → <code>Subversion</code> → <code>Ignore</code> → <code>node_modules</code>
| |
| * Sollte der vorangegangene Schritt schief gegangen sein (WebStorms Subversion-Tools sind in dieser Hinsicht ziemlich schlecht), müssen Sie den letzten Schritt gegebenenfalls mit einem anderen Tool bewerkstelligen. Unter Windows ist Tortoise dafür recht gut geeignet.
| |
| | |
| Außerdem sollten Sie die automatische Überprüfung auf Fehler für alle Ordner ausschalten, die nicht von Ihnen stammen:
| |
| | |
| * Rechtsklick im Dateibaum auf „<code>node_modules</code>“ → <code>Mark Directory as</code> → <code>excluded</code>
| |
| * Rechtsklick im Dateibaum auf „<code>doc</code>“ → <code>Mark Directory as</code> → <code>excluded</code>
| |
| | |
| Beide Ordner enthalten Dateien, die nicht von Ihnen stammen. Diese Dateien können Fehler und Hinweise enthalten,
| |
| veraltete (“deprecated”) Schnittstellen verwenden etc. (Oh ja, auch andere Programmierer machen Fehler. :-) )
| |
| Und wenn Sie diese beiden Ordner nicht als „<code>excluded markieren</code>“, prüft WebStorm bei jedem Commit die
| |
| darin enthaltenen Dateien und weist Sie auf jedes Problem hin. Das können so viele Probleme sein, dass Sie die
| |
| Probleme in Ihren eigenen Dateien vollkommen übersehen.
| |
| | |
| ==Automatische Generierung der Schnittstellenbeschreibung==
| |
| | |
| Installieren Sie zunächst JSDoc:
| |
| | |
| * Öffnen Sie das WebStorm-Terminal.
| |
| * <code>npm install -g jsdoc</code> (installiert JSDoc als Node.js-Anwendung; das haben Sie eigentlich schon gemacht, aber das macht nix :-) )
| |
| * <code>npm install ink-docstrap</code> (installiert ein JSDoc-Theme namens „<code>docstrap</code>“ ([https://docstrap.github.io/docstrap/]); das haben Sie auch schon gemacht, aber das macht auch nix.)
| |
| | |
| Übrigens: Es gibt auch noch andere Themes für JSDoc.
| |
| | |
| Erstellen Sie im Projektordner „<code>conf</code>“ eine JSON-Datei namens „<code>jsdoc.json</code>“.
| |
| Fügen Sie in diese Datei folgenden Code ein:
| |
|
| |
|
| <source lang="javascript"> | | <source lang="javascript"> |
| {
| | ... |
| "tags": | | resolve: |
| { | | { alias: |
| "allowUnknownTags": true | | { ... |
| },
| | 'config': fileURLToPath(new URL('./src/css/_config.scss', import.meta.url)), |
| "source":
| | ... |
| {
| | } |
| "include": ["./src/js"],
| |
| "includePattern": ".+\\.js$",
| |
| "excludePattern": "doc"
| |
| },
| |
| "plugins":
| |
| [],
| |
| "templates":
| |
| {
| |
| "systemName": "WK_HelloWorld04",
| |
| "footer": "",
| |
| "copyright": "Copyright © 2016 by Wolfgang Kowarschick, License <a href=\"https://creativecommons.org/licenses/by-nc-sa/4.0/\">CC-BY-NC-SA-4.0</a>",
| |
| "navType": "vertical",
| |
| "theme": "cerulean",
| |
| "linenums": true,
| |
| "cleverLinks": false, | |
| "monospaceLinks": true,
| |
| "collapseSymbols": true,
| |
| "inverseNav": false
| |
| },
| |
| "opts":
| |
| {
| |
| "template": "node_modules/ink-docstrap/template",
| |
| "encoding": "utf8",
| |
| "destination": "doc/jsdoc",
| |
| "recurse": true,
| |
| "private": true
| |
| } | | } |
| }
| | ... |
| </source>
| |
| | |
| Ersetzen Sie im Attribut „<code>copyright</code>“ meinen Namen durch Ihren, denn es ist Ihr Projekt, nicht meines. :-)
| |
| | |
| In dieser Datei wird festgelegt, wie die HTML-Dokumentation des Codes, die JSDoc erstellt, aussehen soll.
| |
| Insbesondere ist das Template angegeben, das zur Erstellung dieser HTML-Dokumente verwendet werden soll.
| |
| Es handelt sich um „<code>docstrap</code>“, welches wir zuvor heruntergeladen haben. Von der
| |
| Projektroot aus gesehen, befinden sich die Template-Dateien im Ordner
| |
| „<code>node_modules/ink-docstrap/template</code>“.
| |
| | |
| Weitere Konfigurationsparameter werden unter http://usejsdoc.org/about-configuring-jsdoc.html beschrieben.
| |
| | |
| Sie können nun eine Dokumentation für Ihr Projekt erstellen:
| |
| | |
| * Öffnen Sie das WebStorm-Terminal.
| |
| * <code>jsdoc -c conf/jsdoc.json</code>
| |
| | |
| Nach kurzer Zeit sollte der Ordner „<code>doc/jsdoc</code>“ erstellt und mit Inhalten gefüllt worden sein.
| |
| Sehen Sie sich die Datei „<code>doc/jsdoc/index.html</code>“ im Browser an. Diese enthält nicht viel,
| |
| außer einem Drop-Down-Menü „<code>global</code>“, in dem die drei von Ihnen erstellen globalen Funktionen
| |
| „<code>sayHello</code>“, „<code>sayHelloOnEnter</code>“ und „<code>init</code>“ enthalten sind.
| |
| Klicken Sie auf eine dieser Funktionen.
| |
| | |
| ===Vermeidung globaler Funktionen===
| |
| | |
| Die Verwendung von globalen Variablen oder Funktionen in JavaScript ist extrem gefährlich.
| |
| Wenn man eine JavaScript-Datei verwendet, in der
| |
| globale Funktionen enthalten sind, die zufälligerweise genauso heißen, wie
| |
| globale Funktionen in der eigenen JavaScript-Datei, kann man nicht beide
| |
| Dateien laden, da globale Funktionen, die in der ersten Datei enthalten sind,
| |
| durch globale Funktionen der zweiten Datei überschrieben werden.
| |
| | |
| Daher ist es besser, Funktionen wie „<code>sayHello</code>“, „<code>sayHelloOnEnter</code>“ und „<code>init</code>“
| |
| in ein JavaScript-Objekt einzufügen. In unseren Fall könnte man beispielsweise ein
| |
| JavaScript-Objekt „<code>main</code>“ erzeugen, dass diese drei Funktionen enthält.
| |
| Damit hat man nur noch eine globale Variable (<code>main</code>) und die Gefahr
| |
| einer zufälligen Namenskollision bei Verwendung mehrerer JavaScript-Dateien ist geringer.
| |
| | |
| Am besten ist es natürlich, auf globale Größen ganz zu verzichten. Dazu braucht man aber ein
| |
| Modul-System. Dieses ist für [[EcmaScript 6]] geplant ([https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/import
| |
| <code>import</code>] und [https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/export <code>export</code>]), wird
| |
| aber derzeit nur von wenigen Browsern unterstützt.
| |
| | |
| Erserten Sie den Code in Ihrer Datei „<code>main.js</code>“ durch folgenden Code:
| |
| | |
| <source lang="javascript">
| |
| /** @namespace main */
| |
| var
| |
| main =
| |
| {
| |
| /**
| |
| * Welcomes the user of the web app by displaying a welcome message
| |
| * that includes his name. The name is fetched from a text input field.
| |
| */
| |
| sayHello:
| |
| function()
| |
| {
| |
| document.getElementById('text_hello').innerHTML =
| |
| 'Hello, ' + document.getElementById("input_name").value + '!';
| |
| document.getElementById('section_form').classList.add('hidden');
| |
| document.getElementById('section_welcome').classList.remove('hidden');
| |
| },
| |
| | |
| /**
| |
| * An keyboard event observer. It tests whether the enter key has been pressed.
| |
| * If so, the sayHello method is activated. Default reactions of the browser are
| |
| * disabled.
| |
| * @param {KeyboardEvent} p_event - A standard JavaScript keyboard event object
| |
| * (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent)
| |
| */
| |
| sayHelloOnEnter:
| |
| function(p_event)
| |
| {
| |
| if (p_event.code === 'Enter' || p_event.keyCode === 13)
| |
| {
| |
| p_event.preventDefault();
| |
| p_event.stopPropagation();
| |
| main.sayHello();
| |
| }
| |
| },
| |
| | |
| /**
| |
| * Initializes the web app.
| |
| * Is to be called when the web app has been loaded completely.
| |
| */
| |
| init:
| |
| function()
| |
| {
| |
| document.getElementById('button_submit')
| |
| .addEventListener('click', main.sayHello);
| |
| | |
| window.addEventListener('keydown', main.sayHelloOnEnter);
| |
| }
| |
| };
| |
| | |
| // Call main.init, when you are ready with loading.
| |
| window.addEventListener('load', main.init);
| |
| </source>
| |
| | |
| Mit dem JSDoc-Kommentar „<code>@namespace main</code>“
| |
| wird angezeigt, dass die globale Variable „<code>main</code>“
| |
| als „[[Namensraum]]“ fungiert. Das heißt, <code>main</code>
| |
| enthält diverse Funktionen und evtl. andere Elemente, die irgendeinen inneren
| |
| Zusammenhang haben.
| |
| | |
| Wen Sie jetzt JSDoc erneut ausführen, beschreibt Ihre Dokumentation keine globale
| |
| Funktionen mehr, sondern einen Namensraum „<code>main</code>“, der die
| |
| Funktionen „<code>sayHello</code>“, „<code>sayHelloOnEnter</code>“ und „<code>init</code>“
| |
| enthält. Auf diese Funktionen kann mittels „<code>main.sayHello</code>“, „<code>main.sayHelloOnEnter</code>“
| |
| und „<code>main.init</code>“ zugegriffen werden.
| |
| | |
| ===Erstellung der JSDoc-Dokumentation mittels Klickibunti===
| |
| | |
| Falls Sie die Dokumentation nicht immer über das Terminal erstellen möchten, können Sie
| |
| in WebStorm einen neuen Menüeintrag erstellen, über den Sie die Erzeugung der HTML-Dokumentation starten können.
| |
| | |
| Sie müssen dazu den Pfad ermitteln, unter dem Ihre <code>jsdoc</code>-Datei zu finden ist.
| |
| Unter Unix (Mac OS X, Linux, FreeBSD ...) lautet der Befehl, den Sie in ein Terminal eingeben müssen:
| |
| <source lang="bash">
| |
| which jsdoc
| |
| </source>
| |
| Unter '''Windows''' funktioniert dieser Befehl nur in der '''Git BASH'''.
| |
| Außerdem müssen Sie unter Windows den Bash-Pfad modifizieren, damit auch Windows etwas damit anfangen kann.
| |
| Bei mir gibt dieser Befehl Folgendes aus:
| |
| <source lang="bash">
| |
| /c/Users/kowa/AppData/Roaming/npm/jsdoc
| |
| </source> | | </source> |
| Um <code>jsdoc</code> in WebStorm aufrufen zu können, müssen Sie in diesem Pfad „<code>/c</code>“ durch
| |
| „<code>c:</code>“ und „<code>jsdoc</code>“ durch „<code>jsdoc.cmd</code>“ ersetzen.
| |
| (Mac-User brauchen nichts zu ändern. :-) )
| |
|
| |
| Erstellen Sie nun den neuen WebStorm-Menü-Eintrag:
| |
|
| |
| * <code>File</code> → <code>Settings</code> → <code>Tools</code> → <code>External Tools</code>
| |
| * Klick auf das Plus-Icon
| |
| ** <code>Name</code>: <code>JSDoc</code>
| |
| ** <code>Group</code>: <code>Documentation</code>
| |
| ** <code>Description</code>: <code>Generates JavaScript documentation</code>
| |
| ** Hacken bei allen Optionen (<code>Options</code>)
| |
| ** Hacken bei allen Show-in-Optionen (<code>Show i</code>) mit Ausnahme von „<code>Search results</code>“
| |
| * <code>Program</code>: <code>c:/Users/kowa/AppData/Roaming/npm/jsdoc.cmd</code> (hier kommt Ihr zuvor ermittelter Pfad hinein)
| |
| * <code>Parameters</code>: <code>-c $ProjectFileDir$/conf/jsdoc.json</code>
| |
| * <code>Working directory</code>: <code>$ProjectFileDir$</code>
| |
| * <code>OK</code>
| |
| * <code>OK</code>
| |
|
| |
| Nun finden Sie an mehreren Stellen in WebStorm einen neuens Menüpunkt <code>Documentation</code> mit einem Unterpunkt <code>JSDoc</code>:
| |
|
| |
| * Hauptmenü : <code>Tools</code> → <code>Documentation</code> → <code>JSDoc</code>
| |
| * Rechtsklick auf Datei im Projekt-Dateibaum → <code>Documentation</code> → <code>JSDoc</code>
| |
| * Rechtsklick auf Datei im Editor-Tab-Menü → <code>Documentation</code> → <code>JSDoc</code>
| |
|
| |
| Wenn Sie auf einen dieser Unterpunkte „<code>JSDoc</code>“ klicken, erhalten Sie entweder eine Fehlermeldung ( :-( ) oder es wird eine neue Dokumentation erstellt
| |
| ({{dh}}, Sie haben alles richtig gemacht :-) ).
| |
|
| |
|
| Um sicher zu gehen und um nicht mehr verwendete Dokumentationsdateien wie „<code>doc/jsdoc/global.html</code>“ zu entfernen, sollten Sie den Ordner „<code>doc/jsdoc</code>“ gemeinsam mit seinem gesamten Inhalt löschen und <code>JSDoc</code> nochmals aufrufen.
| | ===SCSS-Konfiguration=== |
|
| |
|
| ===Sicherung im Repository===
| | In der Datei <code>_config.scss</code> werden alle von den anderen SCSS-Dateien benötigten Konstanten definiert. |
| | Das heißt, das DRY-Prinzip „Konstanten gehören nicht in den Code, sondern in Konfigurationsdateien“ wird ab sofort beachtet. |
| | Wenn man künftig am Layout einen Zeichensatz, eine Farbe, einen Hintergrund oder Ähnliches ändern will, |
| | reicht es, die entsprechenden Konstanten anzupassen und schon erzeugt Vite automatisch aktualisiere |
| | CSS-Dateien. |
|
| |
|
| Bevor Sie weitermachen: Haben Sie Ihre aktuelle Version von <code>Hello World 04</code> schon im Repository gesichert?
| | Der Underscore <code>_</code> am Beginn des Dateinamens deutet an, dass diese SCSS-Datei nur von anderen SCSS-Dateien |
| | | aber nicht von HTML- oder JavaScript-Dateien importiert werden. Durch SCSS-Import-Befehle ist es möglich, auch SCSS-Dateien |
| Bevor Sie die Projekt-Dateien per ''Commit'' ins Repository übertragen, sollten Sie überprüfen,
| | zu modularisieren. |
| dass der Ordner „<code>node_modules</code>“ auf der sogenannten „Ignore List“ steht (und damit nicht | |
| ins Repository eingespielt wird):
| |
| | |
| * <code>Files</code> bzw. <code>WebStorm</code> → <code>Settings</code> bzw. <code>Preferences</code> → <code>Ignored Files</code>
| |
| * Wenn in dieser Liste der Ordner „<code>node_modules</code>“ nicht aufgeführt wird, fügen Sie ihn mittels des Plus-Icons ein.
| |
| | |
| Sie sollten allerdings den Ordner „<code>doc</code>“ zu Ihrem
| |
| Repository hinzufügen:
| |
| | |
| * Klick auf „<code>doc</code>“ im Dateibaum → <code>Subversion</code> → <code>Add to VCS</code>
| |
| | |
| Nun können Sie Ihr Projekt committen.
| |
| | |
| ==Automatische Komprimierung von CSS- und Javascript-Dateien==
| |
| | |
| Nun folgt die letzte Optimierung der Anwendung. Die von Ihnen erstellten CSS- und Javascript-Dateien
| |
| enthalten viele Leerzeichen, Kommentare, „sprechende“ anstelle von kurzen Variablenbezeichnern etc.
| |
| Das ist für Sie und alle anderen Entwickler von Vorteil. Für die Übertragung der Daten zu einem
| |
| Client (Browser) bedeutet das nur unnötiges Datenvolumen. Gerade für mobile Tarife mit Volumenbegrenzung
| |
| sollten so wenig Daten wie möglich übertragen werden.
| |
| | |
| Glücklicherweise gibt es Tools, die bestehende CSS- oder Javascript-Dateien komprimieren (meist sogar so, dass
| |
| sich die [[Semantik]] der Dateien nicht ändert; aber wie gesagt: Auch andere Programmierer machen hin und wieder Fehler).
| |
| | |
| Wir verwenden die Node.js-Tools „<code>cssmin</code>“ für CSS-Dateien (https://www.npmjs.com/package/cssmin) und
| |
| „<code>UglifyJS2</code>“ für JavaScript-Dateien (https://github.com/mishoo/UglifyJS2). Gesteuert werden diese “minimizer”
| |
| oder “minifier” mittels dem bereits installierten ''JavaScript Task Runner'' <code>grunt</code>“.
| |
| | |
| Die für das Minimieren mittels Grunt notwendige Pakete wurden ebenfalls bereits installiert:
| |
| | |
| <source lang="bash">
| |
| npm install grunt grunt-contrib-watch grunt-contrib-cssmin grunt-contrib-uglify --save-dev
| |
| </source>
| |
|
| |
|
| Nun müssen die Aufgaben zu Komprimieren der JavaScript- und CSS-Dateien in die Konfigurationsdatei
| | '''<code>src/css/_config.scss</code>''' |
| eingefügt werden (vgl. http://gruntjs.com/getting-started):
| | <source lang="CSS"> |
| | @use 'sass:math'; |
|
| |
|
| '''<code>gruntfile.js</code>'''
| | $background-color: #C5EFFC; |
| <source lang="javascript">
| |
| module.exports = function(grunt)
| |
| {
| |
| // Project configuration.
| |
| grunt.initConfig
| |
| ({
| |
| pkg: grunt.file.readJSON('package.json'),
| |
|
| |
|
| cssmin:
| | $font-family-sans: Verdana, Helvetica, sans-serif; |
| { options: /* https://github.com/jakubpawlowicz/clean-css */
| | $font-family-serif: "Times New Roman", Times, serif; |
| { roundingPrecision: -1,
| |
| keepSpecialComments: 1
| |
| },
| |
| minimize:
| |
| { files:
| |
| { 'web/css/main.css': ['src/css/terminal.css', 'src/css/main.css']
| |
| }
| |
| }
| |
| },
| |
|
| |
|
| uglify:
| | $font-size-base: 3vw; |
| { options: /* https://github.com/gruntjs/grunt-contrib-uglify */
| | $font-size-factor: 1.25; /* cmp. https://type-scale.com/ */ |
| { mangle: true,
| | |
| preserveComments: function(p_node, p_comment)
| | $font-size-h5: math.pow($font-size-factor,1)*$font-size-base; |
| { return /@license/.test(p_comment.value); }
| | $font-size-h4: math.pow($font-size-factor,2)*$font-size-base; |
| },
| | $font-size-h3: math.pow($font-size-factor,3)*$font-size-base; |
| minimize:
| | $font-size-h2: math.pow($font-size-factor,4)*$font-size-base; |
| { files: { 'web/js/main.js': ['src/js/terminal.js', 'src/js/main.js']
| | $font-size-h1: math.pow($font-size-factor,5)*$font-size-base; |
| }
| |
| }
| |
| }
| |
| });
| |
|
| |
|
| // Load the plugin that provides the "uglify" task.
| | $font-size-p: math.pow($font-size-factor,0)*$font-size-base; |
| grunt.loadNpmTasks('grunt-contrib-uglify');
| | $font-size-p-large: math.pow($font-size-factor,2)*$font-size-base; |
| grunt.loadNpmTasks('grunt-contrib-cssmin');
| |
|
| |
|
| // Default task(s). | | $font-size-small: math.pow($font-size-factor,-1)*$font-size-base; |
| grunt.registerTask('default', ['uglify', 'cssmin']);
| |
| };
| |
| </source> | | </source> |
| | In dieser SCSS-Datei werden folgende SCSS-Erweiterungen verwendet: |
|
| |
|
| Die Funktion „<code>grunt.initConfig</code>“ aufgerufen und es wird ihr ein [[JavaScript-Objekt]] übergeben.
| | * Mathematische Berechnungen: <code>@use 'sass:math';</code> |
| Im Attribut „<code>pkg</code>“ wird grund der Inhalt der Datei „<code>package.json</code>“ übergeben, damit Grunt ermitteln kann, welche Pakete verfügbar sind.
| | * Definition von Konstanten (die teilweise per Berechnung ermittelt werden) |
| Die beiden anderen Attribute „<code>cssmin</code>“ und „<code>uglify</code>“ (deren Namen frei wählbar sind), werden die beiden Minifier konfiguriert.
| | * Fonts sollten aus designerischen Gründen besser lokal gespeichert und per CSS eingebunden werden. |
|
| |
|
| In beiden Fällen können Optionen angegeben werden, wie {{zB}}, dass CSS-Maß-Angaben nicht gerundet werden sollen (es gibt Designer, die bestehen | | Konstanten starten in SCSS mit einem Dollarzeichen. Sobald eine Konstante definiert wurde, |
| beim Pixelmaß auf vier Nachkommastellen) oder dass geeignete JavaScript-Variablen-Namen „durch die Mangel gedreht“ (''mangle''), also durch kürze Namen ersetzt werden sollen.
| | kann sie in allen weiteren SCSS-Konstrukten verwendet werden. In SCSS stehen einen Operatoren zur Verfügung wie |
| Wichtiger ist jedoch die Angabe, welche Dateien überhaupt erstellt werden und was für Sourcedaten dafür verwendet werden solle.
| | <code>+</code>, <code>-</code>, <code>*</code> und <code>/</code>, um Maße zu berechnen. Es gibt |
| | weitere Operatoren zum Vergleichen von Zahlen und Maßen sowie zur Berechnung von Strings und booleschen Werten: |
| | https://sass-lang.com/documentation/operators.<ref>https://sass-lang.com/documentation/operators</ref> |
|
| |
|
| Zu jeder Datei, die erstellt wird, kann man eine ganze Liste von Sourcedateien angeben. Das hat zur Folge, dass alle diese Sourcedateien nacheinander
| | Die Datei <code>_config.scss</code> kann nun mit Hilfe des SCSS-Befehls <code>@import 'config';</code> (ohne Underscore und ohne Endung, wegen der zuvor eingeführten Vite-Aliase) |
| komprimiert und dann in die Zieldatei eingefügt werden. Auch das ist eine Optimierung, um das Laden einer Web-Anwendung zu beschleunigen.
| | in die anderen beiden SCSS-Dateien eingefügt werden. Das Sass-Package |
| Eine große Datei wird per HTTP schneller übertragen als viele kleine. Künftig werden wir daher möglichst wenige komprimierte Dateien verwenden
| | kennt diesen Befehl und führt ihn beim Erstellen der zugehörigen CSS-Dateien auch aus. |
| und möglichst viele nicht-komprimierte JavaScript-Dateien in komprimierter Form nacheinander in nur eine einzige JavaScript-Datei einfügen. | |
|
| |
|
| Nach der Initialisierungsfunktion werden noch zwei weitere Funktionen aufgerufen. Mit <code>grunt.loadNpmTasks</code>
| | Der Import-Befehl hat erst dann einen Effekt, wenn in den anderen Dateien auf diese Konstanten zugegriffen wird. |
| werden die Grunt-Plugins geladen, die die eigentliche Komprimierung vornehmen. Und mittels <code>grunt.loadNpmTasks</code>
| | Aber er schadet auch nicht, wenn auf keine der dort definierten Konstanten zugegriffen wird. Der Import-Befehl selbst |
| wird festgelegt, welche Aufgaben standardmäßig ausgeführt werden, sobald der Befehl „<code>grunt</code>“ ausgeführt wird.
| | taucht ebenso wenig in den generierten CSS-Dateien auf, wie die Konstantendefinitionen. Der Transpiler ersetzt Konstanten |
| | in CSS-Definitionen durch ihren jeweiligen Wert. |
|
| |
|
| So, nun sollte alles funktionieren. Öffnen Sie das Web-Storm-Terminal und tippen Sie nacheinander folgende Befehle ein:
| | Sie können nun beispielsweise in der Datei <code>head.scss</code> die Konstante <code>$background-color</code> |
| | | verwenden. In der daraus erzeugten CSS-Datei steht weiterhin der Farbwert <code>#C5EFFC</code>; |
| <source lang="bash"> | |
| grunt cssmin
| |
| grunt uglify
| |
| grunt
| |
| </source> | |
|
| |
|
| Sie werden feststellen, das jedes mal bestimmte Dateien in den Ordnern „<code>web/css</code>“ oder/und „<code>web/js</code>“
| | '''<code>src/css/head.scss</code>''' |
| erstellt werden, die mit dem Namensbestandteil „<code>min</code>“ beginnen. Sehen Sie sich die erzeugten Dateien an.
| | <source lang="CSS"> |
| Sie enthalten denselben Code wie die Original-Dateien, nur in komprimierter (und daher für den Menschen schwer lesbarer) Form.
| | @import 'config'; |
|
| |
|
| Als nächstes muss die Datei „<code>index.html</code>“ angepasst werden. Diese lädt noch die unkomprimierten Dateien aus dem
| | body |
| Sourceverzeichnis. Künftig soll sie die komprimierten Dateien aus dem eigentlichen Web-Ordner laden:
| | { background-color: $background-color; } |
|
| |
|
| <source lang="html5">
| | .hidden |
| ...
| | { display: none; } |
| <link rel="stylesheet" type="text/css" href="css/main.css"/>
| |
| ...
| |
| <script type="text/javascript" src="js/main.js"></script>
| |
| </source> | | </source> |
|
| |
|
| Ab sofort werden nicht mehr die Sourcedateien geladen, sondern die komprimierten, durch die Minifier erstellten Dateien.
| | Die Datei <code>body.scss</code> ist deutlich umfangreicher. Daher wird der zugehörige CSS-Code |
| Das heißt aber für uns, dass wir bei jeder Änderung an den Sourcedateien den Befehl „<code>grunt</code>“
| | ja auch erst dynamisch gemeinsam mit der Datei <code>web/js/main.js</code> geladen. |
| ausführen müssen, um die Aktualisierungen in die komprimierten Versionen der JavaScript bzw. CSS-Dateien zu übertragen.
| |
|
| |
|
| Das ist lästig und geht besser.
| | '''<code>src/css/body.scss</code>''' |
| | <source lang="CSS"> |
| | @import 'config'; |
|
| |
|
| ==Automatische Aktualisierung der komprimierten Dateien==
| | html |
| | { height: 100%; |
| | width: 100%; |
| | display: table; |
| | } |
|
| |
|
| Mit Hilfe des Node.js-Paketes „<code>grunt-contrib-watch</code>“ kann man beliebige Dateibäume überwachen,
| | body |
| ob sich darin bestimmte Dateien ändern. In einem derartigen Fall kann man automatisch andere Grunt Tasks ausführen lassen.
| | { display: table-cell; |
| Das lässt sich ausnutzen, um nach Änderungen einer CSS-Datei oder einer JavaScript-Datei die zugehörige komprimierte
| | text-align: center; |
| Datei automatisch neu zu erstellen.
| | vertical-align: middle; |
| | background-color: $background-color; |
| | font-size: $font-size-base !important; |
| | font-family: $font-family-sans; |
| | } |
|
| |
|
| Öffnen Sie das WebStorm-Terminal und laden Sie das besagte Paket:
| | h1 |
| | { padding: 0; |
| | margin: 0; |
| | font-size: $font-size-h1; |
| | } |
|
| |
|
| <source lang="bash">
| | p, label |
| npm install grunt-contrib-watch --save-dev
| | { font-family: $font-family-serif; |
| </source>
| | font-size: $font-size-p !important; |
| | } |
|
| |
|
| Erweitern Sie nun die Datei „<code>gruntfile.js</code>“ um einen Watch-Task:
| | label, input, button |
| | { width: 10em; |
| | font-size: 100%; |
| | display: inline-block; |
| | box-sizing: border-box; |
| | margin: 0.5ex; |
| | } |
|
| |
|
| <source lang="javascript">
| | label |
| watch:
| | { text-align: right; |
| { css:
| |
| { files: ['src/css/**/*.css'],
| |
| tasks: ['cssmin']
| |
| },
| |
| js:
| |
| { files: ['src/js/**/*.js'],
| |
| tasks: ['uglify']
| |
| },
| |
| web:
| |
| { files: ['web/**/*'],
| |
| options: { livereload: true,
| |
| spawn: false
| |
| }
| |
| }
| |
| } | | } |
| </source>
| |
|
| |
|
| Vergessen Sie nicht, das Plugin zu laden:
| | #section_form |
| <source lang="javascript">
| | { text-align: center; |
| grunt.loadNpmTasks('grunt-contrib-watch');
| | margin-left: auto; |
| </source>
| | margin-right: auto; |
|
| |
|
| Der Watch-Task überwacht drei verschiedene Ordner:
| | h1 |
| | | { margin-bottom: 0.5ex; } |
| * Wann immer sich eine CSS-Datei im Ordner „<code>src/css</code>“ oder einem darin enthaltenen Unterordner ändert, wird der Task „<code>cssmin</code>“ ausgeführt.
| | } |
| * Wann immer sich eine JavaScript-Datei im Ordner „<code>src/js</code>“ oder einem darin enthaltenen Unterordner ändert, wird der Task „<code>uglify</code>“ ausgeführt.
| |
| * Wann immer sich irgendeine Datei im Web-Ordner ändert, wird eine <code>livereload</code>-Nachricht (http://livereload.com/) an einen lokalen Node-Server mit der Portnummer 35729 geschickt. (Keine Angst: Sie brauchen diesen Server nicht zu starten oder zu stoppen.)
| |
| | |
| Damit kann man Browser anweisen, die HTML-Dateien neu zu laden, wann immer sich etwas ändert.
| |
| Dies erfolgt entweder mit speziellen Browser-Plugins (http://livereload.com/extensions/) oder mit einem kleinen JavaScript-Hack:
| |
| Fügen Sie ans Ende der Datei „<code>main.js</code>“ folgenden Code ein:
| |
|
| |
|
| <source lang="javascript">
| | #section_hello |
| // Enable live reloading for the WebStorm web server.
| | { p |
| if (location.port === '63342') // WebStorm server port
| | { font-size: $font-size-p-large !important; } |
| { | |
| var l_script = document.createElement('script'); | |
| l_script.src = 'http://'+(location.host||'localhost').split(':')[0]+':35729/livereload.js';
| |
| document.body.appendChild(l_script);
| |
| } | | } |
| </source>
| |
|
| |
| Dieser Code sorgt dafür, dass in eine HTML-Datei, die die Datei „<code>main.js</code>“ einbindet,
| |
| ein zusätzliches <code>script</code>-Element
| |
| <source lang="html5">
| |
| <script src="http://localhost:35729/livereload.js></script>
| |
| </source> | | </source> |
| erstellt und in jede HTML-Datei eingefügt wird, die von einem WebStorm-Test-Server ausgeliefert wird.
| |
| (Der URI kann anstelle des Servernamens „<code>localhost</code>“ auf den echten Namen des Entwicklungsrechners enthalten, sofern
| |
| der Entwicklungsrechner einen derartigen Namen hat.)
| |
|
| |
|
| Unter Port 35729 wird auf dem Entwicklungsrechner von <code>grunt-contrib-watch</code> der bereits erwähnte Livereload-Server gestartet und
| | In dieser SCSS-Datei werden folgende SCSS-Erweiterungen verwendet: |
| die JavaScript-Datei „<code>livereload.js</code>“ zur Verfügung gestellt. Wenn man diese Datei in seine HTML-Datei einbindet,
| |
| aktualisiert sich die HTML-Datei fortan automatisch, sobald <code>grunt-contrib-watch</code> eine Änderung, wie {{zB}}
| |
| die Aktualisierung einer CSS-Datei, einer JavaScript-Datei, der HTML-Datei selbst oder einer anderen Datei, die von der HTML-Datei eingebunden wird,
| |
| meldet.
| |
| | |
| Allerdings wäre es falsch, <code>livereload.js</code> auf einem Live-Server ohne Testumgebung einzubinden. Dort läuft der Livereload-Server überhaupt nicht.
| |
| Daher wird zunächst ermittelt, über welchen Port die aktuelle HTML-Datei von Server ausgeliefert wurde.
| |
| Üblicherweise ist dies 80, 443, 8080, 8888 oder 8443. Andere Ports werden selten verwendet.
| |
| Der Port 63342 wird mit fast absoluter Sicherheit nicht von irgendeinem realen Server verwendet. Daher verwendet ihn WebStorm.
| |
| Und daher kann mit dem Test <code>if (location.port == 63342)</code> ermittelt werden, ob die aktuelle HTML-Datei von einem WebStorm-Server
| |
| ausgeliefert wurde oder von einem anderen Server. (Die globale JavaScript-Variable „<code>location</code>“ enthält den URI, über den die HTML-Datei
| |
| vom Browser geladen wurde.)
| |
| | |
| Nun ist es an der Zeit, den <code>grunt-contrib-watch</code> zu testen. Öffnen Sie „<code>index.html</code>“ im Browser
| |
| (Rechtsklick auf <code>index.html</code> → <code>Run 'index.html'</code>) und tippen Sie dann
| |
| <source lang="bash">
| |
| grunt watch
| |
| </source>
| |
| ins WebStorm-Terminal.
| |
| Ändern Sie nun einen Eintrag in der Datei „<code>main.css</code>“ ({{zB}} <code>font-family: "Comic Sans MS";</code> :-) ).
| |
| Wenn Sie diese Änderungen speichern (Strg-S, Apfel-S), sollten Sie zweierlei Reaktionen bemerken.
| |
| Zum einem wird ins Terminal die Meldung
| |
| <source lang="bash">
| |
| >> File "web/css/main.css" changed.
| |
| </source>
| |
| geschrieben und zum anderen ändert sich das Layout der HTML-Datei im Browser, da die aktualisierte CSS-Datei
| |
| automatisch vom Browser nachgeladen wurde.
| |
|
| |
|
| Wenn Sie die Designsünde „Comic Sans MS“ rückgängig machen, ändert sich die Datei kurz darauf auch im Browser wieder.
| | * Import-Befehl: <code>@import 'config';</code> |
| | * Konstanten: <code>$font-family-sans</code>, <code>$font-size-base</code> etc. (Es sind noch viele weitere konstante Werte in <code>body.scss</code> enthalten, für die in <code>_config.scss</code> Konstanten definiert werden sollten) |
| | * Verschachtelte Anweisungen: {{zB}} <code>h1</code> innerhalb von <code>#section_form</code> |
|
| |
|
| Das ist schon ziemlich „cool“, hat aber noch einen Schönheitsfehler: Das WebStorm-Terminal kann nicht anderweitig genutzt werden, solange
| | Die verschachtelten Anweisungen strukturieren den CSS-Code deutlich besser. Es ist nicht mehr |
| der Grunt-Watcher läuft. Um dieses Problem zu beheben, wird ein WebStorm-Startup-Task definiert, der den Watcher bei jedem
| | notwendig, einen Selektor wie <code>#section_form</code> mehrfach zu verwenden. |
| Programmstart von WebStorm automatisch in einem eigenständigen [[Task]] startet. Der Watcher läuft dann, solange WebStorm geöffnet ist.
| |
| Für seine Ausgaben steht im ein eigenes Ausgabefenster zur Verfügung. Was will man mehr?
| |
|
| |
|
| * <code>File</code> → <code>Settings</code> → <code>Tools</code> → <code>Startup Tasks</code> → <code></code>
| | Sehen Sie sich den Unterschied an. In der Datei <code>src/css/body.css</code> der Musterlösungen vom dritten Teil des Tutoriums hatte ich |
| * Klick auf grünes Plus-Icon → <code>Add New Configuration</code> → <code>Grunt.js</code>
| | Folgendes geschrieben: |
| ** Name: <code>Watch</code>
| |
| ** Gruntfile: <code>.../HelloWorld04/gruntfile.js</code> (sollte bereits korrekt eingetragen sein)
| |
| ** Tasks: <code>watch</code>
| |
| ** Der Node-Interpreter und das Node.js-Paket <code>grunt-cli</code> sollten ebenfalls bereits korrekt eingetragen sein.
| |
| * <code>OK</code> (Unter „<code>Run configuration</code>“ sollte jetzt „<code>Watch</code>“ stehen.)
| |
| * <code>OK</code>
| |
|
| |
|
| Wenn Sie nun WebStorm neu starten, sollte und der Menüzeile am unteren Fensterrand ein Tabulator mit dem Namen „<code>Run</code>“ vorhanden sein.
| | <source lang="CSS"> |
| Wenn Sie das zugehörige Fenster öffnen sollte dort Folgendes stehen:
| | #section_form |
| | { text-align: center; |
| | margin-left: auto; |
| | margin-right: auto; |
| | } |
|
| |
|
| <source lang="bash">
| | #section_form > h1 |
| grunt watch
| | { margin-bottom: 0.5ex; } |
| Running "watch" task
| |
| Waiting...
| |
| </source> | | </source> |
|
| |
|
| Sobald Sie irgendeine Änderung an eine <code>web</code>- oder <code>src</code>-Datei der Web-App vornehmen, werden alle im Watcher definierten Aktionen
| | Die SCSS-Variante ist deutlich strukturierter und prägnanter. |
| (automatische Komprimierung bzw. Neuladen des HTML-Datei im Browser) automatisch ausgeführt. Der Watcher läuft solange, bis Sie WebStorm beenden.
| |
| Es erfolgt dabei sogar noch eine Sicherheitsabfrage, on Sie den Prozess „<code>Watch</code>“ beenden wollen.
| |
| <!-- „<code></code>“ npm install grunt-contrib-watch --save-dev-->
| |
|
| |
|
| ==JSHint== | | <source lang="CSS"> |
| | #section_form |
| | { text-align: center; |
| | margin-left: auto; |
| | margin-right: auto; |
|
| |
|
| Ein weiteres sehr interessantes Tool, das den JavaScript-Entwickler unterstützt, ist JSHint (http://jshint.com/).
| | h1 |
| JSHint analysiert vorhandenen JavaScript-Code und weist auf Fehler und Strukturprobleme hin.
| | { margin-bottom: 0.5ex; } |
| | |
| Installieren Sie zunächst die zugehörigen Node.js-Pakete:
| |
| | |
| <source lang="bash">
| |
| npm install grunt-contrib-jshint jshint-stylish --save-dev
| |
| </source>
| |
| | |
| Anschließend fügen Sie einen JSHit-Task in die Datei „<code>gruntfile.js</code>“ ein.
| |
| | |
| <source lang="javascript">
| |
| jshint:
| |
| {
| |
| all: ['gruntfile.js', 'src/**/*.js'],
| |
| | |
| options: | |
| { | |
| esversion: 5,
| |
| eqeqeq: true,
| |
| eqnull: true,
| |
| browser: true,
| |
| reporter: require('jshint-stylish')
| |
| }
| |
| } | | } |
| </source> | | </source> |
|
| |
|
| | Insbesondere bei großen CSS-Dateien erweist sich diese kompaktere Schreibweise als vorteilhaft. |
|
| |
|
| Nun können alle vom Entwickler erstellten JavaScript-Dateien analysiert werden. Geben Sie dazu im
| | ===Weitere SCSS-Konstrukte=== |
| WebStorm-Terminal einfach folgenden Befehl ein:
| |
|
| |
|
| <source lang="bash"> | | SCSS ist sehr mächtig. Es gibt neben der Import-Anweisung eine Use-Anweisung (<code>@use</code>)<ref>https://sass-lang.com/documentation/at-rules/use</ref>, die SCSS-Konstrukten im Gegensatz zur Import-Anweisung einen Namespace zuweist. Damit ist es möglich, mehrere SCSS-Module zu verwenden, auch wenn |
| grunt jshint
| | dieses gleichbenannte Elemente enthalten, ohne dass es zu Namenskollisionen kommt. |
| </source> | |
|
| |
|
| Gut ist es, wenn JSHint mit der Meldung <code>v No problems</code> antwortet.
| | Darüber hinaus gibt es Mixins<ref>https://sass-lang.com/documentation/at-rules/mixin</ref> und Funktionen<ref>https://sass-lang.com/documentation/at-rules/function</ref>. Mit Mixins kann man ganze Styleblöcke definieren, um sie mehrfach zu verwenden. Mixins werden mit <code>@include</code> eingebunden. Dabei kann man Argumente an die Mixins übergeben, mit denen die entsprechenden Konstanten innerhalb des Mixins initialisiert werden. Funktionen funktionieren wie Funktionen in anderen Programmiersprachen auch. Es stehen einem If-Anweisungen und Schleifen-Befehle zur Verfügung. |
| Ansonsten sollten Sie in Ihrem Code die von JSHint gemeldeten Probleme beheben.
| |
|
| |
|
| Machen Sie ruhig mal die Probe auf's Exempel: Ersetzen Sie
| | SCSS ist im Prinzip eine vollwertige Programmiersprache, um CSS-Dateien modular zu erstellen. |
| in der Datei „<code>main.js</code>“ „<code>=</code><code>==</code>“ durch „<code>==</code>“ und lassen Sie
| |
| danach JSHint laufen. Dann sollte JSHint Folgendes melden:
| |
|
| |
|
| <source lang="bash">
| | ==Fortsetzung des Tutoriums== |
| Expected '===' and instead saw '=='.
| |
| </source>
| |
| | |
| Damit wird ausgedrückt, dass ein nicht-strikter Gleichheitstest verwendet wurde,
| |
| aber ein strikter Gleichheitstest verwendet werden sollte. Der Grund ist, dass
| |
| nicht-strikte Fehlertests manchmal subtile Fehler zur Folge haben, die
| |
| nur sehr schwer zu entdecken sind.
| |
| | |
| JSHint kennt zahlreiche Optionen, die festlegen, welche Fehler und Probleme gemeldet
| |
| werden sollen und welche nicht: http://jshint.com/docs/options/.
| |
| Hier muss jeder Programmierer seinen eigenen Stil finden.
| |
| | |
| Folgende Optionen wurden im obigen Beispiel verwendet:
| |
| | |
| <dl>
| |
| </dt><code>esversion: 5</code></dt>
| |
| <dd>Des sollen die Regeln von [[EcmaScript 5]] beachtet werden.</dd>
| |
| </dt><code>eqeqeq: true</code></dt>
| |
| <dd>Es sollt stets ein strikter Gleichheitstest verwendet werden.</dd>
| |
| </dt><code>eqnull</code></dt>
| |
| <dd>Der nicht-strikte Gleichheitstest <code>... == null</code> ist allerdings erlaubt.
| |
| </dd>
| |
| </dt><code>browser: true</code></dt>
| |
| <dd>Globale Variable sollte man eigentlich grundsätzlich nicht verwenden.
| |
| Mit dieser Option werden für die globalen Variablen, die die Browser bereitgestellt werden
| |
| (<code>document</code>, <code>window</code>, <code>console</code> etc) Ausnahmen definiert.</dd>
| |
| </dl>
| |
| | |
| '''Anmerkung''': Wäre der nicht-strikte Gleichheitstest auf „<code>null</code>“ nicht erlaubt, müsste man
| |
| in viele Fällen „
| |
| <source lang="javascript">
| |
| if (... === null || ...=== undefined)
| |
| </source>
| |
| schreiben. Geben Sie folgende Befehle einfach mal in die Konsole Ihres Web-Browsers ein
| |
| (Firefox: <code>Strg-Shift-K</code>, Opera und Chrome: <code>Strg-Shift-I</code> → <code>Console</code>):
| |
| | |
| <source lang="javascript">
| |
| var a;
| |
| var b = null;
| |
| | |
| // Strikte Gleichheitstests
| |
| console.log(a === null); /* -> false */
| |
| console.log(a === undefined); /* -> true */
| |
| console.log(b === null); /* -> true */
| |
| console.log(b === undefined); /* -> false */
| |
| console.log(a === null || a === undefined); /* -> true */
| |
| console.log(b === null || b === undefined); /* -> true */
| |
| | |
| // Nicht-strikte Gleichheitstests
| |
| console.log(a == null); /* -> true */
| |
| console.log(a == undefined); /* -> true */
| |
| console.log(b == null); /* -> true */
| |
| console.log(b == undefined); /* -> true */
| |
| </source>
| |
| | |
| Zum Abschluss können Sie entweder einen WebStorm-Menü-Eintrag hinzufügen, um den JSHint jederzeit per Klickibunti starten zu können.
| |
| Oder Sie fügen gleich „<code>jslint</code>“ in die Watch-Liste ein, damit jede Änderung sofort analysiert und Fehler sofort angezeigt werden:
| |
| | |
| '''<code>gruntfile.js</code>'''
| |
| <source lang="javascript">
| |
| watch:
| |
| { ...
| |
| js:
| |
| { files: ['src/js/**/*.js'],
| |
| tasks: ['uglify', 'jshint']
| |
| },
| |
| ...
| |
| }
| |
| </source>
| |
|
| |
|
| Allerdings kann JSHint manchmal nerven. :-) Dagegen helfen dann spezielle Kommentare im JavaScript-Code, die
| | Sie sollten nun [[HTML5-Tutorium: JavaScript: Hello World Vue 01|Teil 1 des Vue-Tutoriums]] bearbeiten. |
| JSHint anweisen für die Prüfung des nachfolgenden Codes spezielle Optionen zu benutzen, die dann {{iAllg}}
| | In diesem Teil des Tutoriums wird die oben erstelle Variante in das Vue-Framework transferiert. |
| eine etwas weniger strenge Überprüfung des Codes zur Folge haben (http://jshint.com/docs/).
| |
|
| |
|
| ==Quellen== | | ==Quellen== |
| <references/> | | <references/> |
| <ol> | | <ol> |
| <li value="3"> {{Quelle|Kowarschick, W.: Multimedia-Programmierung}}</li> | | <li value="5"> {{Quelle|Kowarschick, W.: Web-Programmierung}}</li> |
| </ol> | | </ol> |
| <noinclude>[[Kategorie: HTML5-Tutorium: JavaScript: Hello World]][[Kategorie: HTML5-Beispiel]][[Kategorie:Kapitel:Multimedia-Programmierung:Beispiele]]</noinclude> | | <noinclude>[[Kategorie: HTML5-Tutorium: JavaScript: Hello World]][[Kategorie: HTML5-Beispiel]][[Kategorie:Kapitel:Multimedia-Programmierung:Beispiele]]</noinclude> |
Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:
Korrektheit: 3
(zu größeren Teilen überprüft)
|
Umfang: 4
(unwichtige Fakten fehlen)
|
Quellenangaben: 3
(wichtige Quellen vorhanden)
|
Quellenarten: 5
(ausgezeichnet)
|
Konformität: 3
(gut)
|
Vorlesung WebProg
Inhalt |
Teil 1 |
Teil 2 |
Teil 3 |
Teil 4 |
Teil 5 |
Teil 6 |
Vue 1 |
Vue 2 |
Vue 3 |
Vue 4 |
Vue 5 |
Vue 6
Musterlösung
v01: index.html (HTML validate)
v02: index.html (HTML validate; Modularisierung analog zu Hello World 04 v02)
v03: index.html (HTML validate; Konfiguration mittels JSON analog zu Hello World 04 v03)
Git-Repository
Anwendungsfälle (Use Cases)
Gegenüber dem dritten, vierten und fünften Teil des Tutoriums
ändern sich die die Anwendungsfälle nicht. Die Anwendung leistet also genau dasselbe wie zuvor.
In diesem Teil des Tutoriums geht es darum, CSS durch SCSS zu ersetzen, um den CSS-Code „DRY zu machen“.
Erstellen eines neuen Projekts
Erstellen Sie ein neues Projekt hello_world_06 als Fork von hello_world_05.
SCSS
Anstelle von CSS-Dateien verwenden Sie künftig SCSS-Dateien. Das ist zunächst einmal nicht weiter schwer,
das jede CSS-Datei automatisch auch eine SCSS-Datei ist. Bei der Verwendung von CSS können Sie
allerdings das Prinzip „Don't repeat yourself“ (DRY) nicht beachten. Sie müssen für verschiedene Elemente
ständig Informationen wiederholen (gewünschter Font, Hintergrundfarbe, Größenangaben etc.). Deshalb
gibt es mehrere Projekte wie z. B. LESS, Sass/SCSS, Stylus, die den CSS-Standard erweitern, um dieses Problem
zu vermeiden. Sass verwendet allerdings eine ganz andere Syntax als CSS. Allerdings
unterstützt das Sass-Projekt auch die Sprache SCSS, die CSS einfach um weitere syntaktische Elemente ergänzt.
Zum Beispiel kann man in SCSS Konstanten definieren:
$font-family-serif: "Times New Roman", Times, serif;
Und nun kann man in eine SCSS-Datei anstelle von "Times New Roman", Times, serif stets $font-family-serif
schreiben, um den Font von bestimmten Elementen zu definieren.
p
{ font-family: $font-family-serif; }
label
{ font-family: $font-family-serif; }
Wenn man nun diesen Font ändern will,
muss das nicht mehr bei allen Elementen einzeln passieren. Es reicht, die Konstantendefinition abzuändern.
Der SCSS-Code ist nun DRY.
Weiterentwicklung von CSS
CSS entwickelt sich stetig weiter. Seit einiger Zeit werden auch hier Variablen unterstützt:
:root
{ --font-family-serif: "Times New Roman", Times, serif; }
p
{ font-family: var(--font-family-serif); }
label
{ font-family: var(--font-family-serif); }
Auch die Möglichkeit, Werte zu berechnen, gibt es in der Zwischenzeit (SCSS: math, CSS: calc).
Das heißt, die Bedeutung von SCSS, Less etc. schwindet. Aber zurzeit bieten sie immer noch genügend mächtige Erweiterungen gegenüber CSS,
wie z. B. die Möglichkeit, CSS-Elemente zu verschachteln, sodass sich der Einsatz von SCSS noch lohnt.
Transformation von SCSS in CSS
Leider unterstützt kein Browser SCSS direkt (im Gegensatz zu CSS). Aber für was gibt es Transpiler, die eine SCSS-Datei
automatisch in eine CSS-Datei übersetzen können. Vite unterstützt CSS-Transpiler von Haus aus. Man muss den gewünschten Transpiler lediglich installieren:
Benennen Sie die Datei src/css/body.css in src/css/body.scss um. Ersetzen Sie außerdem
in der Datei src/js/main.js den Import-Befehl
durch
Wenn Sie Ihren Code nun mittels npm run dev laufen lassen oder mittels npm run build übersetzen,
sollte die Anwendung noch funktionieren, da der SASS-Loader die neue SCCS-Datei in geeigneten CSS-Code übersetzt.
Schwieriger ist der direkte Import von head.scss in der Datei index.html,
da diese SCSS-Datei von Vite nicht in CSS transformiert wird. Ein Workaround für dieses Problem wird später vorgestellt.
Vite-Konfiguration
Fügen Sie "config" als Abkürzung für "./src/css/_config.scss" in die Datei vite.config.js ein.
...
resolve:
{ alias:
{ ...
'config': fileURLToPath(new URL('./src/css/_config.scss', import.meta.url)),
...
}
}
...
SCSS-Konfiguration
In der Datei _config.scss werden alle von den anderen SCSS-Dateien benötigten Konstanten definiert.
Das heißt, das DRY-Prinzip „Konstanten gehören nicht in den Code, sondern in Konfigurationsdateien“ wird ab sofort beachtet.
Wenn man künftig am Layout einen Zeichensatz, eine Farbe, einen Hintergrund oder Ähnliches ändern will,
reicht es, die entsprechenden Konstanten anzupassen und schon erzeugt Vite automatisch aktualisiere
CSS-Dateien.
Der Underscore _ am Beginn des Dateinamens deutet an, dass diese SCSS-Datei nur von anderen SCSS-Dateien
aber nicht von HTML- oder JavaScript-Dateien importiert werden. Durch SCSS-Import-Befehle ist es möglich, auch SCSS-Dateien
zu modularisieren.
src/css/_config.scss
@use 'sass:math';
$background-color: #C5EFFC;
$font-family-sans: Verdana, Helvetica, sans-serif;
$font-family-serif: "Times New Roman", Times, serif;
$font-size-base: 3vw;
$font-size-factor: 1.25; /* cmp. https://type-scale.com/ */
$font-size-h5: math.pow($font-size-factor,1)*$font-size-base;
$font-size-h4: math.pow($font-size-factor,2)*$font-size-base;
$font-size-h3: math.pow($font-size-factor,3)*$font-size-base;
$font-size-h2: math.pow($font-size-factor,4)*$font-size-base;
$font-size-h1: math.pow($font-size-factor,5)*$font-size-base;
$font-size-p: math.pow($font-size-factor,0)*$font-size-base;
$font-size-p-large: math.pow($font-size-factor,2)*$font-size-base;
$font-size-small: math.pow($font-size-factor,-1)*$font-size-base;
In dieser SCSS-Datei werden folgende SCSS-Erweiterungen verwendet:
- Mathematische Berechnungen:
@use 'sass:math';
- Definition von Konstanten (die teilweise per Berechnung ermittelt werden)
- Fonts sollten aus designerischen Gründen besser lokal gespeichert und per CSS eingebunden werden.
Konstanten starten in SCSS mit einem Dollarzeichen. Sobald eine Konstante definiert wurde,
kann sie in allen weiteren SCSS-Konstrukten verwendet werden. In SCSS stehen einen Operatoren zur Verfügung wie
+, -, * und /, um Maße zu berechnen. Es gibt
weitere Operatoren zum Vergleichen von Zahlen und Maßen sowie zur Berechnung von Strings und booleschen Werten:
https://sass-lang.com/documentation/operators.[1]
Die Datei _config.scss kann nun mit Hilfe des SCSS-Befehls @import 'config'; (ohne Underscore und ohne Endung, wegen der zuvor eingeführten Vite-Aliase)
in die anderen beiden SCSS-Dateien eingefügt werden. Das Sass-Package
kennt diesen Befehl und führt ihn beim Erstellen der zugehörigen CSS-Dateien auch aus.
Der Import-Befehl hat erst dann einen Effekt, wenn in den anderen Dateien auf diese Konstanten zugegriffen wird.
Aber er schadet auch nicht, wenn auf keine der dort definierten Konstanten zugegriffen wird. Der Import-Befehl selbst
taucht ebenso wenig in den generierten CSS-Dateien auf, wie die Konstantendefinitionen. Der Transpiler ersetzt Konstanten
in CSS-Definitionen durch ihren jeweiligen Wert.
Sie können nun beispielsweise in der Datei head.scss die Konstante $background-color
verwenden. In der daraus erzeugten CSS-Datei steht weiterhin der Farbwert #C5EFFC;
src/css/head.scss
@import 'config';
body
{ background-color: $background-color; }
.hidden
{ display: none; }
Die Datei body.scss ist deutlich umfangreicher. Daher wird der zugehörige CSS-Code
ja auch erst dynamisch gemeinsam mit der Datei web/js/main.js geladen.
src/css/body.scss
@import 'config';
html
{ height: 100%;
width: 100%;
display: table;
}
body
{ display: table-cell;
text-align: center;
vertical-align: middle;
background-color: $background-color;
font-size: $font-size-base !important;
font-family: $font-family-sans;
}
h1
{ padding: 0;
margin: 0;
font-size: $font-size-h1;
}
p, label
{ font-family: $font-family-serif;
font-size: $font-size-p !important;
}
label, input, button
{ width: 10em;
font-size: 100%;
display: inline-block;
box-sizing: border-box;
margin: 0.5ex;
}
label
{ text-align: right;
}
#section_form
{ text-align: center;
margin-left: auto;
margin-right: auto;
h1
{ margin-bottom: 0.5ex; }
}
#section_hello
{ p
{ font-size: $font-size-p-large !important; }
}
In dieser SCSS-Datei werden folgende SCSS-Erweiterungen verwendet:
- Import-Befehl:
@import 'config';
- Konstanten:
$font-family-sans, $font-size-base etc. (Es sind noch viele weitere konstante Werte in body.scss enthalten, für die in _config.scss Konstanten definiert werden sollten)
- Verschachtelte Anweisungen: z. B.
h1 innerhalb von #section_form
Die verschachtelten Anweisungen strukturieren den CSS-Code deutlich besser. Es ist nicht mehr
notwendig, einen Selektor wie #section_form mehrfach zu verwenden.
Sehen Sie sich den Unterschied an. In der Datei src/css/body.css der Musterlösungen vom dritten Teil des Tutoriums hatte ich
Folgendes geschrieben:
#section_form
{ text-align: center;
margin-left: auto;
margin-right: auto;
}
#section_form > h1
{ margin-bottom: 0.5ex; }
Die SCSS-Variante ist deutlich strukturierter und prägnanter.
#section_form
{ text-align: center;
margin-left: auto;
margin-right: auto;
h1
{ margin-bottom: 0.5ex; }
}
Insbesondere bei großen CSS-Dateien erweist sich diese kompaktere Schreibweise als vorteilhaft.
Weitere SCSS-Konstrukte
SCSS ist sehr mächtig. Es gibt neben der Import-Anweisung eine Use-Anweisung (@use)[2], die SCSS-Konstrukten im Gegensatz zur Import-Anweisung einen Namespace zuweist. Damit ist es möglich, mehrere SCSS-Module zu verwenden, auch wenn
dieses gleichbenannte Elemente enthalten, ohne dass es zu Namenskollisionen kommt.
Darüber hinaus gibt es Mixins[3] und Funktionen[4]. Mit Mixins kann man ganze Styleblöcke definieren, um sie mehrfach zu verwenden. Mixins werden mit @include eingebunden. Dabei kann man Argumente an die Mixins übergeben, mit denen die entsprechenden Konstanten innerhalb des Mixins initialisiert werden. Funktionen funktionieren wie Funktionen in anderen Programmiersprachen auch. Es stehen einem If-Anweisungen und Schleifen-Befehle zur Verfügung.
SCSS ist im Prinzip eine vollwertige Programmiersprache, um CSS-Dateien modular zu erstellen.
Fortsetzung des Tutoriums
Sie sollten nun Teil 1 des Vue-Tutoriums bearbeiten.
In diesem Teil des Tutoriums wird die oben erstelle Variante in das Vue-Framework transferiert.
Quellen
- Kowarschick (WebProg): Wolfgang Kowarschick; Vorlesung „Web-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2024; Quellengüte: 3 (Vorlesung)
