Frontend-applikationer, især de mere komplekse, skal behandle en masse data. Programmører introducerer forskellige designmønstre for at gøre deres projekter læsbare og vedligeholdelsesvenlige. I de fleste almindelige scenarier med MVC ønsker vi at adskille data fra de visuelle dele af appen.
Det er grunden til, at butik er blevet så nyttig. Det er op til dig, om du vil bruge React + Redux eller Vue + Vuex - hovedmålet er det samme, nemlig holder dine data strukturerede, tilgængelige og sikre på samme tid.
I denne artikel vil jeg vise dig et par eksempler på, hvordan du kan holde din Vuex-butik ren og effektiv.
Lad os antage det, før vi går i gang:
- du har noget erfaring med moderne JavaScript,
- du ved stort set, hvad Vue er, og hvordan man bruger det rekvisitter, beregnet, osv,
- du er bekendt med Vuex (handlinger, mutationer, osv.) og ønsker at gøre dine apps bedre.
Vuexligesom størstedelen af core Vue-projekterer ret veldokumenteret, og du kan finde mange nyttige hacks i de officielle dokumenter. Vi har trukket nogle vigtige oplysninger ud af den til dig.
En grundlæggende implementering af en Vuex-butik ser sådan ud:
// main.js
import Vue from 'vue'
import Vuex fra 'vuex'
import App from "./App";
Vue.use(Vuex)
const store = new Vuex.Store((
tilstand: (
data: null;
),
actions: (
someAction: (( commit ), data) (
commit("SOME_MUTATION", data);
)
),
mutationer: (
SOME_MUTATION (tilstand, data) (
state.data = data;
)
))
));
new Vue((
el: "#app",
render: h => h(App),
butik
));
Når din app bliver større, er du normalt nødt til at anvende routing, nogle globale direktiver, plugins osv. Det gør den main.js
fil meget længere og sværere at læse. Det er en god idé at gemme lageret i en ekstern fil, som her:
// store.js
import Vue from 'vue'
import Vuex fra 'vuex'
Vue.use(Vuex);
const state = (
data: null;
);
const actions = (
someAction: (( commit ), data) (
commit("SOME_MUTATION", data);
)
);
mutationer = (
SOME_MUTATION (tilstand, data) (
state.data = data;
)
);
export default new Vuex.Store((
state,
handlinger,
mutationer
));
1. Moduler
Hvad skal du gøre, når store.js
filen bliver enorm og svær at arbejde med? Der er faktisk en rigtig cool Vuex-funktion - moduler. De er beregnet til at opdele dine data i separate filer.
Forestil dig, at du arbejder på en virksomhedsapp, hvor du f.eks. har få datadomæner:
- bruger (administrerer alle autorisationer og tilladelser),
- ruteparametre (administrer globale parametre før anmodninger til API),
- salg (for din SalesMegaChart-komponent, der er synlig i en månedlig/kvartalsvis/årlig kontekst),
- ordrer (synlig efter klik på SalesMegaChart-linjen).
... og måske et par stykker mere. Nu har du seriøse grunde til at indføre noget modularitet i din butik.
Først og fremmest skal du flytte store.js
fil til en nyoprettet Store/
og omdøb den til index.js
. Hvis du vil beholde alt pakket ind i moduler, kan du eventuelt fjerne stat, handlinger og mutationer fra hovedfilen.
// store/index.js
import Vue from 'vue'
import Vuex fra 'vuex'
Vue.use(Vuex);
export default new Vuex.Store((
moduler: (
// moduler kommer til at stå her
)
));
Ved siden af filen `store/index.js` skal du oprette det første modul - `store/user.js`.
import ApiService from '../services/api.service';
const state = (
loggedIn: false,
loginError: null,
bruger: null
);
const actions = (
login: async (( commit ), data) (
prøv (
const response = await ApiService.post('/login', data);
const ( user ) = response.data;
COMMIT("SAVE_USER", bruger);
COMMIT("LOGIN_SUCCES");
) catch (fejl) (
commit("LOGIN_ERROR", fejl);
)
)
);
mutationer = (
SAVE_USER (tilstand, bruger) (
state.user = user;
),
LOGIN_SUCCESS (state) (
state.loggedIn = true;
),
LOGIN_ERROR (tilstand, fejl) (
state.loginError = fejl;
state.loggedIn = false;
)
);
eksport const user (
state,
handlinger,
mutationer
)
Og nu skal du indlæse det færdige modul i hovedfilen `store/index.js`:
import Vue from 'vue'
import Vuex fra 'vuex'
import ( user ) from './user';
Vue.use(Vuex);
export default new Vuex.Store((
moduler: (
bruger
)
));
Tillykke med det! Nu har du en rigtig flot butiksimplementering. Du kan også få adgang til data fra komponenten (f.eks, Brugerprofil.vue
) sådan her:
<template>
<div class="user-profile">
<h2>(( bruger.navn ))!</h2>
<!-- component template goes here -->
</div>
</template>
<script> import ( mapActions ) from 'Vuex';
export default (
name: 'UserProfile',
computed: mapState((
user: state => state.user
// user: 'user' <-- alternative syntax
))
)
</script>
2. Navnerum
Nu hvor du ved, hvordan du bruger moduler, bør du også blive fortrolig med Vuex's Navneafstand. I det foregående trin oprettede vi store/user.js
filen med bruger modul.
Den datastruktur, der er defineret i user.js
filen er tilgængelig fra komponenter, men du kan se, at alle bruger data går direkte til den globale stat
kontekst, som her:
beregnet: mapState((
user: state => state.user
// user: 'user' <-- alternativ måde
))
Når du definerer flere moduler, vil du sandsynligvis blive forvirret over, hvilket objekt der kommer fra hvilket modul. Så bør du bruge namespaced moduler og definere dem på denne måde:
export const user (
namespaced: true, // <-- namespacing!
state,
handlinger,
mutationer
)
Fra nu af vil alle dine bruger data (stat
variabel fra store/user.js
fil) vil blive håndteret under stat.bruger
reference:
beregnet: mapState((
user: state => state.user.user
// user: 'user/user' <-- alternativ måde
))
Et par skridt senere kan du opnå noget lignende for komponenten:
import ( mapActions ) fra 'Vuex';
eksport standard (
navn: 'Dashboard',
beregnet: mapState((
salg: 'salg/data',
ordrer: 'ordrer/data',
sortBy: 'ordrer/sortBy',
loggedIn: 'bruger/loggedIn'
)),
metoder: mapActions((
logout: 'user/logout',
loadSales: 'salg/load',
loadOrders: 'ordrer/load'
)),
created() (
if (this.loggedIn) (
loadSales();
loadOrders();
)
)
)
Bravo! Så frisk, så ren ... Men bare rolig, refaktorering slutter aldrig. Er du klar til de næste trin?
3. Kommunikation mellem moduler
I det første trin viste jeg dig noget handling i bruger modul:
const actions = (
login: async (( commit ), data) (
prøv (
const response = await ApiService.post('/login', data);
const ( user ) = response.data;
COMMIT("SAVE_USER", bruger);
COMMIT("LOGIN_SUCCES");
) catch (fejl) (
commit("LOGIN_ERROR", fejl);
)
)
);
I tilfælde af fejl tilføjer vi login-fejl i vores butik - hvad bliver det næste?
Her har vi et par muligheder, og valget afhænger af, hvilken mulighed der passer bedst til dine behov. Den enkleste måde er at bruge v-if
direktiv, som gør det muligt at vise en fejlmeddelelse, hvis der opstår en fejl i din butik.
<template>
<div class="dashboard">
<!-- dashboard component template -->
<div
v-if="error"
class="error-message"
> (( fejl.besked )) </div>
</div>
</template>
<script> import ( mapActions ) from 'Vuex';
export default (
name: 'Dashboard',
computed: mapState((
error: "user/loginError"
))
)
</script>
Forestil dig igen, at du har mange moduler, og at hvert try/catch
syntaks genererer en ny fejl i din butik. Det er klart, at du kommer til at misbruge DRY-reglen på denne måde.
Hvordan kan du gøre dine fejlhåndteringsprocesser mere generiske?
Lad os definere fælles modul og lægge noget logik ind, som skal bruges globalt.
// store/common.js
const state = (
errors: []
);
const actions = (
fejl: (
rod: true,
handler(( commit ), error) (
commit("ERROR", fejl);
)
)
),
mutationer = (
ERROR (tilstand, fejl) (
/* på denne måde får vi den nyeste fejl øverst på listen */
state.errors = [error, ...state.errors];
))
);
export const common (
namespaced: true,
tilstand,
mutationer
)
Nu kan vi tilpasse bruger modul (og også andre moduler):
prøv (
// en eller anden handling
)fang (fejl) (
commit("common/ERROR", error, ( root: true ));
)
eller på en mere elegant måde ved at bruge vores globale handling:
prøv (
// en eller anden handling
) catch (fejl) (
dispatch("fejl", fejl);
)
Denne syntaks af begå
og afsendelse
opkald virker selvforklarende, men du kan læse mere om disse tricks her.
Når du har alle fejl på ét sted, kan du nemt lægge dem ind i din Dashboard
komponent:
beregnet: mapState((
errors: 'fælles/fejl'
)),
watch: (
/* dette vil blive påkaldt efter hver "common/ERROR"-mutation, hvor vi kun tilføjer nye fejl til lageret, en efter en */
errors() (
this.showErrorMessage(this.errors[0]);
)
)
Det forrige eksempel med fælles Modulhåndtering af fejl er allerede en effektiv løsning, men man kan gå endnu længere.
Som du kan se, holder vi øje med ændringer på fælles/fejl
array i butikken. I tilfælde som disse, hvor du har brug for at bestemme en handling på en bestemt mutation, kan du bruge Vuex plugins eller endda komponenter af højere orden (HOC).
Jeg vil diskutere plugins og HOC'er i den næste artikel. I mellemtiden takker jeg dig for at have læst dette indlæg, og jeg håber, at du har nydt de eksempler, vi har forberedt.
Hold øje og bliv ved med at kode!
Læs mere om det:
– Hvordan forbedrer man Vue.js-apps? Nogle praktiske tips
– GraphQL: erfaringer fra produktion
– Shopify, Spree eller Solidus? Se, hvorfor Ruby on Rails kan hjælpe dig med at udvikle din e-handel