Få HTML-udvikling med flere sider til at suge mindre med Pug

Inspireret af en sand historie

Lad os tage en rejse ...

Forestil dig, at du er på opkaldslisten til et freelancebureau i en by, du vælger. Lad os sige, at du får en god besked i din indbakke. Du åbner beskeden, og den ser ret normal ud.

Vi har et øjeblikkeligt behov for en udvikler til at komme i gang i dag.

meddelelsen, og den ser ret normal ud.

Vi har et øjeblikkeligt behov for en udvikler til at komme i gang i dag.

At være en person, der nyder at spise mad for at overleve, skriver du nogle oplysninger og ansøger.

Inden for fem minutter efter at du har trykket på den sendeknap, får du et opkald. 10 minutter efter det får du serveradgang.

Det er overflødigt at sige, at du er på en deadline. Denne frist er ved udgangen af ​​dagen.

Du åbner HTML-filerne og ser på dem ... med rædsel.

Koden er overalt, rodet og uorganiseret. For ikke at nævne, skal du foretage justeringer af sidehoved og sidefod ... på fem forskellige sider.

Den første ting du gør er at køre det gennem Prettify (Gudskelov for Prettify). Det ryddede det op, men der er nogle flere problemer. Dette er et statisk HTML-sted, hvilket betyder, at enhver ændring, du foretager i de globale ting (sidehoved, sidefod osv.), Bliver du nødt til at kopiere i ALLE filer. Åh min.

Hvad vil du gøre???

Enkelt, du pisker op en Webpack-fil for at håndtere den skøre del af at skrive HTML, og du skal gøre det hurtigt.

Her er hvad du bliver nødt til at være fortrolig med:

  • Javascript! (på grund af Webpack)
  • HTML! (fordi det er hvad internettet er lavet af)
  • CSS! (for hvem kan lide grimme ting?)
  • mops! (fordi det er meningen med denne artikel!)
  • npm (fordi det er Gud)
  • Grundlæggende kommandolinjeviden (fordi det er dumt at gøre ting via downloads ...)
  • Ved hvem Jim Carrey er (fordi gifs)

Hvis du ikke er fortrolig med mops, kan du stadig klare dig igennem dette. Men hvis du har tid, skal du læse om det. Jeg anbefaler at lære mops med mops. Eller deres dokumenter. Det er også okay, tror jeg.

Her er de versioner, jeg brugte til dette:

  • html-loader: 0.5.5,
  • html-webpack-plugin: 3.2.0,
  • pug-html-loader: 1.1.5,
  • Webpakke: 4.12.0
  • webpack-cli: 3.0.8
  • npm: 6.1.0
  • node: 10.4.0

Opdatering: Jeg lavede en video! Tjek det, hvis du ikke vil læse, men hellere vil lytte til min stemme i 30 minutter.

Trin 1. Organiser din projektstruktur

Sådan organiserer jeg min mappe til disse typer projekter.

src/ oldHTML/ dist/ images/ css/ webpack.config

Jeg kan godt lide at lægge al den originale HTML i en separat mappe, som jeg ikke ved et uheld ikke kan slette. Webpack er lidt venligere end at sige, Gulp, som jeg tidligere har slettet en hel mappe? Denne struktur er god nok til at komme i gang.

Trin 2. Skru npm-motoren op igen

Bortset fra: Jeg vendte for nylig tilbage til npmfra yarnaf nogle få grunde. Den ene var, at den holdt op med at arbejde, og jeg havde lidt tålmodighed til at få det til at fungere igen. Interessant artikel her, hvis du vil læse mere.

I hvert fald, start den npm.

npm init -y

Bemærk: ( -y er, hvis du ikke vil besvare nogen af ​​dens spørgsmål)

Installer udviklingsafhængigheder.

Bare rolig, jeg forklarer hver enkelt, mens vi går.

npm install -D webpack webpack-cli pug-html-loader html-webpack-plugin html-loader

Føj nogle scripts til package.json

Som standard har package.json et script, men vi skal tilføje et par.

"dev": "webpack --watch --mode development", "prod": "webpack --mode production"

Dette er de to, som jeg gerne vil medtage. Den første kører Webpack i udviklingstilstand (bemærk: --mode-flag er nyt for Webpack 4) og holder øje med filændringer. Det andet er, når vi vil køre Webpack i produktion, dette minimerer normalt ting.

Det skal se sådan ud:

"name": "pugTut", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "dev": "webpack --watch --mode development", "prod": "webpack --mode production" }, .....more code

Opret et par startfiler for at teste vores Webpack-konfiguration

Webpack har brug for et indgangspunkt, så lad os lave et. Opret en app.js i src / mappen. Det kan være tomt. Det betyder ikke noget. Det har også brug for en indledende pug-fil for at kompilere. Opret også en index.pug- fil i src / mappen.

Opret og opsæt webpack.config.js i rodmappen

Okay, hvis du ikke har brugt Webpack før, går jeg gennem hver del individuelt for at give dig (og forhåbentlig mig) en idé om wtf foregår i denne konfigurationsfil.

Lad os først erklære vores afhængighed.

// webpack.config.js const path = require('path'); const webpack = require('webpack'); const HtmlWebpackPlugin = require('html-webpack-plugin');

sti er en indbygget nodeafhængighed, så du skal ikke bekymre dig om, at det kræves i din pakke.json.

Webpack er godt Webpack ...

HtmlWebpackPlugin er hvordan vi udtrækker HTML. Jeg er ikke ekspert på, hvordan Webpack fungerer. Efter hvad jeg forstår, da det er designet til at forbruge JavaScript, er vi nødt til at have loadere i vores konfigurationsfil for at trække ting som HTML og CSS ud. HtmlWebpackPlugin er, hvordan vi gør noget nyttigt med HTML'en, der ekstraheres fra indlæserne .

Fedt nok? Næste skridt…

const pug = { test: /\.pug$/, use: ['html-loader?attrs=false', 'pug-html-loader'] };

This method is used by Wes Bos and I really like it, so I use it. We have to define rules on how to handle certain file types, for example .pug or .css. Putting it into a variable makes it more legible, in my opinion. Anyways, we setup a test case with a regexp, then define the loaders we want to use. For whatever reason, the loaders are listed in reverse order of what you’d think. I’m sure there is an explanation but I couldn’t find it.

Confused? What that means is, if we want to use pug to compile to HTML, we write it in the order above: our html loader ->pug loader. However, in reality when the code runs, it runs the pug loader first…then the HTML loader. Yep.

Note: Don’t worry about ?attrs=false for right now, I’ll explain it a bit later.

Cool? Next step…

const config = { entry: './src/app.js', output: { path: path.resolve(__dirname, 'dist'), filename: '[name].bundle.js' }, module: { rules: [pug] }, plugins: [ new HtmlWebpackPlugin({ filename: 'index.html', template: 'src/index.pug', inject: false }) ] }; module.exports = config;

Holy Crap. That’s a lot of stuff. Let’s break it down.

entry is simply the entry point for our JS file.

output defines where we want our JS file to go. This is not where our HTML files will go. As mentioned above, path is a node module. __dirname is a variable we can get from Node. The filename is what we want to call our JS file. The [name] is a substitution. In this case, it uses the file name of the entry file. You can also use [hash] if you want a unique identifier.

module defines the different modules. For the purpose of this tutorial, there is only one module with one set of rules. rules defines the rules we will use for that module. We throw the pug variable we made earlier into there. So nice, so clean.

Finally, plugins is where we get to add any third party stuff. In our case, we are using HtmlWebpackPlugin to do something with our pug files.

filename is what we want our HTML file to be called. template is the pug file that are compiling. inject is: “inject all assets into the given template.” I have it set to false because…well, honestly I don’t remember.

One of the crappiest things about HtmlWebpackPlugin is that you have to create an entry for EVERY HTML file. I tried to figure a way around it, but found no simple solutions.

// webpack.config.js const path = require('path'); const webpack = require('webpack'); const HtmlWebpackPlugin = require('html-webpack-plugin'); const pug = { test: /\.pug$/, use: ['html-loader?attrs=false', 'pug-html-loader'] }; const config = { entry: './src/app.js', output: { path: path.resolve(__dirname, 'dist'), filename: '[name].bundle.js' }, module: { rules: [pug] }, plugins: [ new HtmlWebpackPlugin({ filename: 'index.html', template: 'src/index.pug', inject: false }) ] }; module.exports = config;

Before we move on, let’s make sure our code works! Run the script.

npm run dev

If all went well, you should see something like this:

We’ve come a long way. Here’s a present:

Step 3. Break up the pages into partials

This is where magic starts happening. I know it seems like we’ve been working for a while with very little gain, but trust me…it was worth it.

One of the most important features for pug is the partials. The idea is to have one file that holds most of your global code (head, header, footer, nav, and so on) and have individual files for all your content.

Let’s make a couple files. You should have created the index.pug file already, but let’s make one more, layout.pug.

src/ - index.pug - layout.pug

Step 4. Setup layout file

The layout file is basically the main template for your whole site. It will have hold all the global stuff, for example head, header and footer.

//- layout.pug doctype html html head title I'm a title body block header block content block footer script(src="somescript.js")

I guess something to explain is that pug is all based on indentation, similar to YAML. It is glorious, because that means no more closing tags! However, this can throw some, especially those with crappy indentation to begin with. So just make sure to start slow and make sure everything is indented correctly and you’ll be fine.

Looking at our layout.pug file, you’ll see some familiar HTML tags mixed with unfamiliar ones. I highly suggest downloading syntax highlighting for pug in your editor of choice. If you’re using VSCode, it should come with it by default. Thanks Microsoft.

I think it’s pretty easy to figure out, but let’s take a look at the meat of the document to make sure we know what’s going on.

head title I'm a title body block header block content block footer script(src="somescript.js")

head, body, title and script are normal tags, but what the hell is block? block is how we define dynamic content. Basically, this is telling pug that some content is going to go in here. Hopefully it’ll make more sense when we create our individual page files.

Step 5. Create more partials

Let’s make use of that index.pug file.

//- index.pug extends layout block content p Woah.

Looking at our index file, it seems awfully small for a whole HTML page. That’s because of that little extends fella. extends tells pug that you want to use another pug file as the template, in our case layout. Then below that block content is in reference to what we put in our layout.pug file.

If you have your Webpack still running in the background, it should recompile and you’ll get a fresh new index.html in your dist/ folder. If not, run Webpack again.

Step 6. Grab all the old HTML

Those starter files are fine and dandy, but we need to make some real progress. We need to start grabbing that HTML and using it! Luckily, pug will recognize regular old HTML tags, so you can literally copy all the HTML content you want and just paste it in there.

It might look something like this:

extends layout block content 

blerb

Woah.

Alright, it’s not really that simple.

Like I mentioned, pug is based on indentation. To make life easier on yourself, I suggest removing all indentation from the HTML file before pasting into the pug file. It will mostly work, but you’ll probably have to finagle it a bit. Lucky for us, pug-html-loader will tell us what’s wrong with it when it tries to compile. There are some examples of common problems in the next Step.

Step 7. Start optimizing

Jeg lyver ikke, når du først smider HTML, vil Webpack ikke lide det. Her er et par ting at passe på:

Billeder

  1. Sørg for, at linkene til billederne er gode. Uanset årsag mislykkes det ofte, hvis src = “images /” i stedet for src = “/ images /”

2. Jeg lovede tidligere at vende tilbage til det der ?attrs=falsevar, ja, her er vi!

Dette er blurb fra html-loader-webstedet, der forklarer, hvad det gør.

For fuldstændigt at deaktivere behandling af tagattributter (for eksempel, hvis du håndterer billedindlæsning på klientsiden), kan du sende ind attrs=false.
html-loader?attrs=false 

Javascript

pug spiller ikke godt med JS i script tags. Hvis du klistrer i regelmæssige åbning og lukning af JS script tags, fungerer det muligvis okay. Men hvis du vil bruge pug script-tagget, skal du bare sørge for at tilføje en periode i slutningen, sådan her:

Step 8. Make more pages and start converting to pug tags

Clearly it’s useless if you are only doing the index page. For whatever you’re doing, just create a new file for each page you want. Also, make sure to make new HtmlWebpackPlugin entries in the plugins section in Webpack.

It’ll end up looking like this:

//webpack.config.js ...previous code... plugins: [ new HtmlWebpackPlugin({ filename: 'index.html', template: 'src/index.pug', inject: false }), new HtmlWebpackPlugin({ filename: 'contact.html', template: 'src/contact.pug', inject: false }) ] ...more code...

You don’t have to convert everything to pug format immediately. In fact, if you have a huge site with a crap ton of HTML, then you can do it as you go, but it does make it easier.

Includes

Dette ville ikke være en meget god tutorial, hvis vi ikke talte om inkluderer. Husk disse blokke i layoutfilen? Nå, hvis du ikke ønsker, at layoutfilen skal være kæmpe, kan du oprette separate filer, der trækkes ind på kompileringstidspunktet. For eksempel, hvis du vil oprette en enkelt fil, der indeholder al overskriftinfo. At bryde det op på denne måde hjælper også væsentligt med indrykning.

Opret en ny fil "header" i en ny mappe "inkluderer":

src/ -- includes/ header.pug

I den fil skal du placere hvad du vil være i overskriften.

//- header.pug header h1 I'm a header

Gå nu tilbage til layout.pug og inkluder det.

//- layout.pug doctype html html head title I'm a title body block header include includes/header block content block footer script(src="somescript.js")

Trin 7. Vil du få lyst?

Der er mange flere ting, du kan gøre med pug og webpack. Jeg tror dog, at vi har nået slutningen af ​​det grundlæggende. Tjek stadig mixins. Disse ting er fantastiske.

Afslutter

Jeg foreslår stærkt at indbringe HTML langsomt, ellers vil du ende med at debugge 1.000 fejl på én gang.