Modulariseerimise mõiste on enamiku kaasaegsete programmeerimiskeelte lahutamatu osa. JavaScripti puhul pole aga modulaarsuse osas olnud mingit ametlikku lähenemist kuni ECMAScript ES6 uusima versiooni saabumiseni.

Node.js-is, mis on tänapäeva üks populaarsemaid JavaScripti raamistikke, võimaldavad moodulite kogumid laadida NPM moodulid veebibrauserites ja komponentidele orienteeritud teegid (nagu React) julgustavad ja hõlbustavad JavaScripti koodi moduleerimist.

Veebipakk on üks saadaolevatest moodulite komplektidest et protsessid JavaScripti kood, samuti kõik staatilised varad, nagu stiililehed, pildid ja fondid, koondfailiks. Töötlemine võib hõlmata kõiki koodisõltuvuste haldamiseks ja optimeerimiseks vajalikke ülesandeid, näiteks kompileerimine, liitmine, minimeerimine ja tihendamine.

Webpacki ja selle sõltuvuste konfigureerimine võib aga olla stressirohke ja see pole alati algajatele lihtne protsess.

üks viise, kuidas ründajad pääsevad krüptimata juurde

Selles blogipostituses on toodud näited juhiste kohta, kuidas veebipaketti konfigureerida erinevate stsenaariumide jaoks, ning tuuakse välja kõige tavalisemad lõksud, mis on seotud projektisõltuvuste komplekteerimisega Webpacki abil.

Selle blogipostituse esimene osa selgitab, kuidas lihtsustada sõltuvuste määratlust projektis. Järgmisena arutame ja demonstreerime mitme ja ühe lehe rakenduste koodijaotuse seadistamist. Lõpuks arutame, kuidas Webpacki konfigureerida, kui tahame oma projekti kaasata kolmandate osapoolte teeke.

Pseudonüümide ja suhteliste teede konfigureerimine

Suhtelised teed pole sõltuvustega otseselt seotud, kuid me kasutame neid sõltuvuste määratlemisel. Kui projektifailide struktuur on keeruline, võib asjakohaste mooduliteede lahendamine olla keeruline. Webpacki seadistamise üks põhilisi eeliseid on see, et see aitab projekti suhteliste teede määratlust lihtsustada.

Oletame, et meil on järgmine projekti struktuur:

- Project - node_modules - bower_modules - src - script - components - Modal.js - Navigation.js - containers - Home.js - Admin.js

Võime viidata sõltuvustele suhteliste teede järgi vajalikele failidele ja kui tahame komponente importida oma lähtekoodi konteineritesse, näeb see välja järgmine:

Home.js

Import Modal from ‘../components/Modal’; Import Navigation from ‘../components/Navigation’;

Modal.js

import {datepicker} from '../../../../bower_modules/datepicker/dist/js/datepicker';

Iga kord, kui tahame skripti või moodulit importida, peame teadma praeguse kataloogi asukohta ja leidma suhtelise tee imporditavate juurde. Võime ette kujutada, kuidas see probleem võib keerukamaks muutuda, kui meil on suur sisestatud failistruktuuriga projekt või kui soovime mõne keeruka projekti struktuuri osa ümber kujundada.

Saame selle probleemiga hõlpsasti hakkama veebipaketi resolve.alias abil valik. Saame deklareerida nn varjunimed - kataloogi või mooduli nimi koos asukohaga ja me ei tugine projekti lähtekoodis suhtelistele radadele.

webpack.config.js

resolve: { alias: { 'node_modules': path.join(__dirname, 'node_modules'), 'bower_modules': path.join(__dirname, 'bower_modules'), } }

Väljal Modal.js faili, saame nüüd importida datepickerit palju lihtsamalt:

import {datepicker} from 'bower_modules/datepicker/dist/js/datepicker';

Koodi jagamine

Meil võib olla stsenaariume, kus peame skripti lisama lõplikku kimpu või lõpliku kimpu jagama või soovime soovi korral eraldi kimbud laadida. Nende stsenaariumide jaoks meie projekti ja Webpacki konfiguratsiooni seadistamine ei pruugi olla lihtne.

Veebipaketi konfiguratsioonis on Entry suvand ütleb Webpackile, kus on viimase paketi alguspunkt. Sisestuspunktil võib olla kolm erinevat tüüpi andmeid: string, massiiv või objekt.

Kui meil on üks lähtepunkt, saame kasutada mõnda neist vormingutest ja saada sama tulemuse.

Kui soovime lisada mitu faili ja need ei sõltu üksteisest, võime kasutada massiivi vormingut. Näiteks võime lisada analytics.js bundle.js lõpuni:

webpack.config.js

module.exports = { // creates a bundle out of index.js and then append analytics.js entry: ['./src/script/index.jsx', './src/script/analytics.js'], output: { path: './build', filename: bundle.js ' } };

Mitme sisenemispunkti haldamine

Oletame, et meil on mitme lehega rakendus, millel on mitu HTML-faili, näiteks index.html ja admin.html. Saame luua mitu kimpu, kasutades sisestuspunkti objekti tüübina. Allpool olev konfiguratsioon loob kaks JavaScripti kimpu:

webpack.config.js

module.exports = { entry: { index: './src/script/index.jsx', admin: './src/script/admin.jsx' }, output: { path: './build', filename: '[name].js' // template based on keys in entry above (index.js & admin.js) } };

index.html

admin.html

CommonsChunkPlugin

webpack.config.js

Mõlemad JavaScripti paketid võivad jagada ühiseid teeke ja komponente. Selleks võime kasutada var commonsPlugin = new webpack.optimize.CommonsChunkPlugin('common.js'); module.exports = { entry: { index: './src/script/index.jsx', admin: './src/script/admin.jsx' }, output: { path: './build', filename: '[name].js' // template based on keys in entry above (index.js & admin.js) }, plugins: [commonsPlugin] }; , mis leiab moodulid, mis esinevad mitmes sisestustükis, ja loob jagatud kogumi, mida saab vahemällu salvestada mitme lehe vahel.

require.ensure

System.import

Nüüd ei tohi unustada enne komplekteeritud skriptide lisamist.

Laisa laadimise lubamine

Webpack saab staatilised varad jagada väiksemateks tükkideks ja see lähenemine on paindlikum kui tavaline liitmine. Kui meil on suur üksikleheline rakendus (SPA), ei ole lihtne ühendamine ühte kimpu hea lähenemine, sest ühe tohutu kogumi laadimine võib olla aeglane ja kasutajad ei vaja tavaliselt kõiki vaateid kõiki sõltuvusi.

kuidas robotit Pythoniga programmeerida

Me selgitasime varem, kuidas jagada rakendus mitmeks kogumiks, liita tavalised sõltuvused ja saada brauseri vahemälu käitumisest kasu. See lähenemine töötab väga hästi mitmeleheliste rakenduste puhul, kuid mitte üheleheliste rakenduste puhul.

SPA jaoks peaksime pakkuma ainult neid staatilisi varasid, mis on vajalikud praeguse vaate kuvamiseks. SPA-arhitektuuri kliendipoolne ruuter on ideaalne koht koodi jagamise käsitsemiseks. Kui kasutaja sisestab marsruudi, saame tulemuseks oleva vaate jaoks laadida ainult neid vajalikke sõltuvusi. Teise võimalusena võime sõltuvusi laadida siis, kui kasutaja lehte allapoole kerib.

Sel eesmärgil saame kasutada admin.jsx või import React, {Component} from 'react'; export default class Admin extends Component { render() { return Admin ; } } funktsioonid, mida Webpack suudab staatiliselt tuvastada. Veebipakett saab selle jaotuspunkti põhjal genereerida eraldi kogumi ja helistada sellele nõudmisel.

Selles näites on meil kaks React konteinerit; administraatori vaade ja armatuurlaua vaade.

dashboard.jsx

import React, {Component} from 'react'; export default class Dashboard extends Component { render() { return Dashboard ; } }

/dashboard

/admin

Kui kasutaja sisestab kas index.jsx või if (window.location.pathname === '/dashboard') { require.ensure([], function() { require('./containers/dashboard').default; }); } else if (window.location.pathname === '/admin') { require.ensure([], function() { require('./containers/admin').default; }); } URL, laaditakse ainult vastav vajalik JavaScripti komplekt. Allpool näeme näiteid kliendipoolse ruuteriga ja ilma.

index.jsx

ReactDOM.render( {props.children} }> { require.ensure([], function (require) { cb(null, require('./containers/dashboard').default) }, 'dashboard')}} /> { require.ensure([], function (require) { cb(null, require('./containers/admin').default) }, 'admin')}} /> , document.getElementById('content') );

style-loader

css-loader

Stiilide eraldamine eraldi kimpudesse

Veebipakendis laadurid , nagu ExtractTextWebpackPlugin ja webpack.config.js, töötle stiililehed ette ja manusta need JavaScripti väljundkomplekti, kuid mõnel juhul võivad need põhjustada Stiliseerimata sisu välk (FOUC) .

FOUC-i saame vältida var ExtractTextPlugin = require('extract-text-webpack-plugin'); module.exports = { module: { loaders: [{ test: /.css/, loader: ExtractTextPlugin.extract('style', 'css’)' }], }, plugins: [ // output extracted CSS to a file new ExtractTextPlugin('[name].[chunkhash].css') ] } -ga see võimaldab genereerida kõik stiilid eraldi CSS-kimpudesse selle asemel, et need oleks lõplikku JavaScripti kimpu manustatud.

$

jQuery

Kolmandate osapoolte raamatukogude ja pistikprogrammide käitlemine

Mitu korda peame kasutama kolmandate osapoolte teeke, erinevaid pistikprogramme või täiendavaid skripte, sest me ei soovi kulutada aega samade komponentide arendamiseks nullist. Saadaval on palju pärandkogusid ja pistikprogramme, mida ei hooldata aktiivselt, mis ei mõista JavaScripti mooduleid ja eeldavad sõltuvuste olemasolu globaalselt etteantud nimede all.

Allpool on mõned näited jQuery pistikprogrammidega koos selgitusega, kuidas Webpacki lõpliku kogumi genereerimiseks õigesti konfigureerida.

Pakkuge pistikprogrammi

Enamik kolmandate osapoolte pistikprogramme tugineb konkreetsete globaalsete sõltuvuste olemasolule. JQuery puhul toetuvad pistikprogrammid $(‘div.content’).pluginFunc() -le või ProvidePlugin määratletav muutuja ja saame kasutada jQuery pistikprogramme, helistades var $ = require('jquery') meie koodis.

Saame kasutada Webpacki pistikprogrammi $ eelkäima webpack.config.js iga kord, kui see kohtub globaalse webpack.ProvidePlugin({ ‘$’: ‘jquery’, }) identifikaator.

$

require

Kui Webpack koodi töötleb, otsib ta kohalolekut $ ja annab viite globaalsetele sõltuvustele importimata moodulit, mille on määranud this funktsioon.

Import-laadur

Mõni jQuery pistikprogramm eeldab, et window globaalses nimeruumis või tuginege imports-loader olles example.js objekt. Sel eesmärgil saame kasutada $(‘div.content’).pluginFunc(); mis süstib globaalseid muutujaid moodulitesse.

kuidas arvutada nõudluse hinnaelastsust

$

imports-loader

Seejärel saame süstida require('imports?$=jquery!./example.js'); muutuja moodulisse, seadistades var $ = require('jquery');

example.js

See lihtsalt eelistab webpack.config.js kuni module: { loaders: [{ test: /jquery-plugin/, loader: 'imports?jQuery=jquery,$=jquery,this=>window' }] } .

Teisel juhul:

=>

this

Kasutades window sümbol (mitte segi ajada sümboliga ES6 noole funktsioonid ), saame määrata suvalised muutujad. Viimane väärtus määratleb globaalse muutuja (function () { ... }).call(window); uuesti osutada this objekt. See on sama mis faili kogu sisu pakkimine window -ga ja helistamine // CommonJS var $ = require('jquery'); // jquery is available // AMD define([‘jquery’], function($) { // jquery is available }); funktsioon funktsiooniga jquery-plugin.js argumendina.

Samuti võime nõuda teeke, mis kasutavad moodulit CommonJS või AMD:

(function(factory) { if (typeof define === 'function' && define.amd) { // AMD format is used define(['jquery'], factory); } else if (typeof exports === 'object') { // CommonJS format is used module.exports = factory(require('jquery')); } else { // Neither AMD nor CommonJS used. Use global variables. } });

Mõni teek ja moodul võivad toetada erinevaid moodulivorminguid.

Järgmises näites on meil jQuery pistikprogramm, mis kasutab moodulite AMD ja CommonJS vormingut ning millel on jQuery sõltuvus:

webpack.config.js

module: { loaders: [{ test: /jquery-plugin/, loader: 'imports?define=>false,exports=>false' }] }

define

false

Saame valida, millist moodulivormingut soovime konkreetse teegi jaoks kasutada. Kui deklareerime exports võrdseks false, Webpack ei sõelu moodulit AMD mooduli vormingus ja kui deklareerime muutuja expose-loader võrdseks webpack.config.js, Webpack ei parsitse moodulit CommonJS-mooduli vormingus.

Expose-laadur

Kui peame mooduli globaalsesse konteksti eksponeerima, võime kasutada module: { loaders: [ test: require.resolve('jquery'), loader: 'expose-loader?jQuery!expose-loader?$' ] } See võib olla kasulik näiteks siis, kui meil on väliseid skripte, mis ei kuulu Webpacki konfiguratsiooni ja tuginevad globaalses nimeruumis olevale sümbolile, või kasutame brauseri pistikprogramme, mis peavad brauseri konsoolis sümbolile juurde pääsema.

window.$ window.jQuery

millised on disaini elemendid ja põhimõtted

externals

JQuery teek on nüüd veebisaidil saadaval ka teiste skriptide globaalses nimeruumis.

webpack.config.js

Väliste sõltuvuste seadistamine

Kui tahame kaasata väliselt hostitud skriptide mooduleid, peame need konfiguratsioonis määratlema. Vastasel juhul ei saa Webpack lõplikku kogumit genereerida.

Väliseid skripte saame konfigureerida, kasutades externals: { react: 'React', 'react-dom': 'ReactDOM' } suvand Webpacki konfiguratsioonis. Näiteks saame eraldiseisva sildi kaudu kasutada CDN-i teeki, deklareerides seda siiski selgesõnaliselt oma moodulisõltuvuses.

project | |-- node_modules | |-- react |-- react-plugin | |--node_modules | |--react

react-plugin

Teegi mitme eksemplari toetamine

On suurepärane kasutada NPM-i paketihaldurit esiotsa arendamisel kolmandate osapoolte teekide ja sõltuvuste haldamiseks. Kuid mõnikord võib meil olla mitu sama teegi eksemplari, millel on erinevad versioonid, ja need ei mängi ühes keskkonnas hästi koos.

See võib juhtuda näiteks Reacti teegiga, kuhu saame Reacti installida NPM-ist ja hiljem võib mõne täiendava paketi või pistikprogrammiga saada kättesaadavaks ka teise Reacti versiooni. Meie projekti struktuur võib välja näha järgmine:

webpack.config.js

Komponendid, mis pärinevad module.exports = { resolve: { alias: { 'react': path.join(__dirname, './node_modules/react'), 'react/addons': path.join(__dirname, '/node_modules/react/addons'), } } } on erinev React-eksemplar kui ülejäänud projekti komponendid. Nüüd on meil Reactist kaks eraldi eksemplari ja need võivad olla erinevad versioonid. Meie rakenduses võib see stsenaarium segi ajada meie ülemaailmse muutuva DOM-i ja näeme veebikonsooli logis tõrketeateid. Selle probleemi lahenduseks on kogu projekti vältel sama reaktiiversiooni olemasolu. Saame selle lahendada Webpacki varjunimede abil.

react-plugin

node_modules

Millal console.log(React.version) React'i nõuab, kasutab see projekti versioonis

|_+_|

Kui tahame teada saada, millist Reacti versiooni kasutame, võime lisada

|_+_|

lähtekoodis.

Keskenduge arendamisele, mitte veebipakendi seadistamisele

See postitus lihtsalt kriimustab Webpacki võimsuse ja kasulikkuse pinda.

Webpacki on veel palju laadurid ja pistikprogrammid mis aitab teil JavaScripti komplektimist optimeerida ja sujuvamaks muuta.

Isegi kui olete algaja, annab see juhend teile kindla aluse Webpacki kasutama hakkamiseks, mis võimaldab teil rohkem keskenduda arendamisele vähem komplektide seadistamisele.

Seotud: Juhtimise säilitamine: veebipaki ja reageerimise juhend, Pt. 1