A többoldalas HTML-fejlesztés kevesebbet szívhat a Mopsz segítségével

Igaz történet ihlette

Vegyünk egy utat ...

Képzelje el, hogy egy szabadúszó ügynökség hívólistáján szerepel egy választott városban. Tegyük fel, hogy szép üzenetet kap a postaládájába. Kinyitja az üzenetet, és ez nagyon normálisnak tűnik.

Nekünk azonnal szükségünk van egy fejlesztőre, hogy elinduljon ma.

az üzenet, és nagyon normálisnak tűnik.

Nekünk azonnal szükségünk van egy fejlesztőre, hogy elinduljon ma.

Mivel valaki olyan ember, aki élelmezéssel él a túlélés érdekében, beír néhány információt és jelentkezik.

Öt percen belül, miután megnyomta a küldés gombot, hívást kap. 10 perc múlva megkapja a szerver hozzáférést.

Mondanom sem kell, hogy határidőn van. Ez a határidő a nap végére szól.

Megnyitja a HTML fájlokat, és rémülten vizsgálja meg őket.

A kód mindenhol rendetlen és rendezetlen. Nem is beszélve arról, hogy a fejlécet és a láblécet ki kell igazítani… öt különböző oldalon.

Az első dolog, amit a Prettify-on (hála istennek a Prettify-n keresztül) futtat. Ez megtisztította, de van még néhány probléma. Ez egy statikus HTML webhely, ami azt jelenti, hogy a globális dolgokon (fejléc, lábléc stb.) Végrehajtott minden változtatást MINDEN fájlba be kell másolnia . Jaj nekem.

Mit fogsz csinálni???

Egyszerű: felver egy Webpack fájlt, hogy kezelje a HTML írás gagyi részét, és gyorsan meg is fogja csinálni.

Itt kell megismernie:

  • Javascript! (a Webpack miatt)
  • HTML! (mert ez az internet)
  • CSS! (mert ki szereti a csúnya dolgokat?)
  • mopsz! (mert ez a cikk lényege!)
  • npm (mert Isten)
  • Alapszintű parancssori ismeretek (mert hülyeség…
  • Tudd ki Jim Carrey (mert gifek)

Ha még nem ismeri a mopszot, akkor is kezelheti ezt. De ha van ideje, olvassa el. Azt javaslom, hogy tanuljunk mopszot mopszokkal. Vagy a dokik. Ezek is rendben vannak, azt hiszem.

Itt vannak a verziók, amelyeket ehhez használtam:

  • html-loader: 0.5.5,
  • html-webpack-plugin: 3.2.0,
  • pug-html-loader: 1.1.5,
  • Webcsomag: 4.12.0
  • webpack-cli: 3.0.8
  • npm: 6.1.0
  • csomópont: 10.4.0

Frissítés: Készítettem egy videót! Nézd meg, ha nem szeretnél olvasni, inkább 30 percig hallgatnád a hangomat.

1. lépés: Szervezze meg a projekt felépítését

Így szeretem rendezni a mappámat az ilyen típusú projektekhez.

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

Szeretem az összes eredeti HTML-t külön mappába tenni, amelyet véletlenül nem tudok törölni. A Webpack egy kicsit kedvesebb, mint mondjuk, Gulp, amelyet korábban egy teljes mappával töröltem? Ez a szerkezet elég jó ahhoz, hogy elindulhasson.

2. lépés Fordítsa fel az npm motort

Eltekintve: Nemrég visszatért a npmkövetkezőtől yarnnéhány ok. Az egyik az volt, hogy abbahagyta a működését, és alig volt türelmem, hogy újra működjön. Érdekes cikk itt, ha többet szeretne olvasni.

Mindenesetre kezdeményezze azt az npm-et.

npm init -y

Megjegyzés: (az -y az, ha nem akarsz válaszolni egyik kérdésére sem)

Telepítse a fejlesztési függőségeket.

Ne aggódj, elmagyarázom mindegyiket menet közben.

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

Adjon hozzá néhány szkriptet a package.json fájlhoz

Alapértelmezés szerint a package.json egy szkriptet tartalmaz, de hozzá kell adnunk néhányat.

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

Ez a kettő, amit szívesen felveszek. Az első futtatja a Webpack fejlesztési módban (megjegyzés: a --mode jelző új a Webpack 4-ben), és figyelni fogja a fájlváltozásokat. A második az, amikor a Webpack-ot gyártásban szeretnénk futtatni, ez általában enyhíti a dolgokat.

Valahogy így kell kinéznie:

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

Hozzon létre néhány indító fájlt a Webpack konfiguráció teszteléséhez

A Webpacknak ​​szüksége van egy belépési pontra, ezért készítsünk egyet. Hozzon létre egy app.js fájlt az src / mappában. Lehet üres. Nem számít. Szüksége van egy kezdeti mopsz fájlra is a fordításhoz. Hozzon létre egy index.pug fájlt az src / mappában is.

Hozza létre és állítsa be a webpack.config.js fájlt a gyökérkönyvtárban

Rendben, ha még nem használta a Webpack-ot, akkor minden egyes részt külön-külön végigmegyek, hogy (és remélhetőleg nekem is) képet adjak a wtf-ről ebben a konfigurációs fájlban.

Először deklaráljuk függőségeinket.

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

Az elérési út egy natív csomópont-függőség, ezért nem kell aggódnia amiatt, hogy ezt megköveteli a csomagja.json.

A Webpack az, hát a Webpack…

A HTML-t a HtmlWebpackPlugin segítségével nyerjük ki. Nem vagyok a Webpack működésének szakértője. Megértésem szerint, mivel JavaScript használatára készült, a konfigurációs fájlban betöltőkkel kell rendelkeznünk, hogy kivonjuk a HTML és CSS fájlokat. A HtmlWebpackPlugin segítségével tehetünk valami hasznosat a HTML-ről, amelyet kibontunk a betöltőkből.

Menő? Következő lépés…

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

Nem fogok hazudni, amikor először dobsz be HTML-t, a Webpack nem fog tetszeni neki. Íme néhány dolog, amire figyelni kell:

Képek

  1. Győződjön meg arról, hogy a képekre mutató linkek jók. Bármilyen okból kifolyólag gyakran meghiúsul, ha az src = “images /” helyett src = “/ images /”

2. Korábban megígértem, hogy visszatérek arra, ami ?attrs=falsevolt, nos, itt vagyunk!

Ez a html-loader webhely áttekintése, amely elmagyarázza, mit csinál.

A címkeattribútum-feldolgozás teljes letiltásához (például, ha a kliens oldalon kezeljük a kép betöltését) átadhatja attrs=false.
html-loader?attrs=false 

Javascript

A mopsz nem játszik jól a JS-szel a script tagekben. Ha rendszeresen nyit és zár be JS szkript címkéket, akkor ez rendben is működhet. Ha azonban használni szeretné a mopsz szkript címkéjét, csak feltétlenül adjon meg egy pontot a végén:

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

This wouldn’t be a very good tutorial if we didn’t talk about includes. Remember those blocks in the layout file? Well, if you don’t want the layout file to be giant, you can create separate files that will be pulled in at compile time. For instance, if you want to make a single file that holds all the header info. Breaking it up this way also helps substantially with indentation.

Create a new file “header” in a new folder “includes”:

src/ -- includes/ header.pug

In that file, put whatever you want to be in the header.

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

Now go back to layout.pug and include it.

//- 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")

Step 7. Want to get Fancy?

There’s a ton more stuff you can do with pug and webpack. However, I think we’ve reached the end of the basics. Still, check out mixins. Those things are amazing.

Wrapping Up

I highly suggest bringing in HTML slowly, otherwise you’ll end up debugging 1,000 errors at once.