window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(funktion () { var w = vindue if (w.LeadBooster) { console.warn('LeadBooster findes allerede') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Vuex-funktioner, du bør kende, hvis du virkelig bekymrer dig om din butik - The Codest
Codest
  • Om os
  • Serviceydelser
    • Udvikling af software
      • Frontend-udvikling
      • Backend-udvikling
    • Staff Augmentation
      • Frontend-udviklere
      • Backend-udviklere
      • Dataingeniører
      • Cloud-ingeniører
      • QA-ingeniører
      • Andet
    • Det rådgivende
      • Revision og rådgivning
  • Industrier
    • Fintech og bankvirksomhed
    • E-commerce
    • Adtech
    • Sundhedsteknologi
    • Produktion
    • Logistik
    • Biler
    • IOT
  • Værdi for
    • ADMINISTRERENDE DIREKTØR
    • CTO
    • Leder af levering
  • Vores team
  • Casestudier
  • Ved hvordan
    • Blog
    • Møder
    • Webinarer
    • Ressourcer
Karriere Tag kontakt til os
  • Om os
  • Serviceydelser
    • Udvikling af software
      • Frontend-udvikling
      • Backend-udvikling
    • Staff Augmentation
      • Frontend-udviklere
      • Backend-udviklere
      • Dataingeniører
      • Cloud-ingeniører
      • QA-ingeniører
      • Andet
    • Det rådgivende
      • Revision og rådgivning
  • Værdi for
    • ADMINISTRERENDE DIREKTØR
    • CTO
    • Leder af levering
  • Vores team
  • Casestudier
  • Ved hvordan
    • Blog
    • Møder
    • Webinarer
    • Ressourcer
Karriere Tag kontakt til os
Pil tilbage GÅ TILBAGE
2020-07-21
Udvikling af software

Vuex-funktioner, du bør kende, hvis du virkelig bekymrer dig om din butik

Wojciech Bak

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

Relaterede artikler

Udvikling af software

Byg fremtidssikrede webapps: Indsigt fra The Codest's ekspertteam

Oplev, hvordan The Codest udmærker sig ved at skabe skalerbare, interaktive webapplikationer med banebrydende teknologier, der leverer sømløse brugeroplevelser på tværs af alle platforme. Lær, hvordan vores ekspertise driver digital transformation og...

DENKODEST
Udvikling af software

Top 10 Letlands-baserede softwareudviklingsvirksomheder

Læs om Letlands bedste softwareudviklingsvirksomheder og deres innovative løsninger i vores seneste artikel. Find ud af, hvordan disse teknologiledere kan hjælpe med at løfte din virksomhed.

thecodest
Løsninger til virksomheder og scaleups

Grundlæggende om Java-softwareudvikling: En guide til succesfuld outsourcing

Udforsk denne vigtige guide til vellykket outsourcing af Java-softwareudvikling for at forbedre effektiviteten, få adgang til ekspertise og skabe projektsucces med The Codest.

thecodest
Udvikling af software

Den ultimative guide til outsourcing i Polen

Den voldsomme stigning i outsourcing i Polen er drevet af økonomiske, uddannelsesmæssige og teknologiske fremskridt, der fremmer it-vækst og et erhvervsvenligt klima.

TheCodest
Løsninger til virksomheder og scaleups

Den komplette guide til IT-revisionsværktøjer og -teknikker

IT-revisioner sikrer sikre, effektive og kompatible systemer. Lær mere om deres betydning ved at læse hele artiklen.

Codest
Jakub Jakubowicz CTO og medstifter

Tilmeld dig vores vidensbase, og hold dig opdateret om ekspertisen fra it-sektoren.

    Om os

    The Codest - International softwareudviklingsvirksomhed med tech-hubs i Polen.

    Storbritannien - Hovedkvarter

    • Kontor 303B, 182-184 High Street North E6 2JA
      London, England

    Polen - Lokale teknologiske knudepunkter

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Kraków
    • Hjerneambassaden, Konstruktorska
      11, 02-673 Warszawa, Polen

      Codest

    • Hjem
    • Om os
    • Serviceydelser
    • Casestudier
    • Ved hvordan
    • Karriere
    • Ordbog

      Serviceydelser

    • Det rådgivende
    • Udvikling af software
    • Backend-udvikling
    • Frontend-udvikling
    • Staff Augmentation
    • Backend-udviklere
    • Cloud-ingeniører
    • Dataingeniører
    • Andet
    • QA-ingeniører

      Ressourcer

    • Fakta og myter om at samarbejde med en ekstern softwareudviklingspartner
    • Fra USA til Europa: Hvorfor beslutter amerikanske startups sig for at flytte til Europa?
    • Sammenligning af Tech Offshore-udviklingsknudepunkter: Tech Offshore Europa (Polen), ASEAN (Filippinerne), Eurasien (Tyrkiet)
    • Hvad er de største udfordringer for CTO'er og CIO'er?
    • Codest
    • Codest
    • Codest
    • Privacy policy
    • Vilkår for brug af hjemmesiden

    Copyright © 2025 af The Codest. Alle rettigheder forbeholdes.

    da_DKDanish
    en_USEnglish de_DEGerman sv_SESwedish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek da_DKDanish