[Proyecto práctico de Vue] Sistema de gestión general: empaquetado API, 404 páginas

Prefacio

Este artículo es el tercer artículo de la serie de pequeños proyectos prácticos de Vue del blogger. Es muy adecuado para back-end o aquellos que recién están comenzando. Es una enseñanza a nivel de niñera de un proyecto front-end de 0 a 1. Contenido anterior:

[Proyecto práctico de Vue] Sistema de gestión general: página de inicio de sesión-Blog CSDN

[Proyecto práctico de Vue] Sistema de gestión general: encapsulación de operaciones de token y solicitudes de red-Blog CSDN

Tabla de contenido

1.encapsulación de API

2.404 página

3.Discutir


1.encapsulación de API

Dado que hay muchas API en un proyecto, se ajustan en todas partes. Si sigue el método de escritura anterior y ajusta la API en cada componente, una vez que se cambia la API, se debe cambiar en todas partes, por lo que la API también debe encapsularse y la API Las llamadas están encapsuladas en funciones y las funciones están agrupadas para facilitar su administración.

Cree un directorio api en src para almacenar la api. Cree un api.js en el directorio api para encapsular cada api:

Dado que el proyecto solo ha utilizado una API de back-end hasta ahora, es decir, iniciar sesión, el contenido de api.js aquí es el siguiente:

import service from '../utils/service'

export function login(data){
    return service({
        method:'post',
        url:'/login',
        data
    })
}

Después de extraer api.js, las futuras llamadas a la API de back-end utilizarán las funciones proporcionadas en api.js. Aquí, primero cambie la lógica de llamada de la API de la página de inicio de sesión:

import {setToken} from '@/utils/setToken.js'
import {login} from '@/api/api.js'
methods:{
    login(form){
      this.$refs[form].validate((valid)=>{
        if(valid){
          console.log(this.form)
          // this.service.post('/login',this.form)
          // .then(res=>{
          //   console.log(res.status)
          //   if(res.status===200){
          //     setToken('username',res.data.username)
          //     setToken('token',res.data.token)
          //     this.$router.push('/home')
          //   }
          // })
          login(this.form).then(res=>{
            console.log(res.status)
            if(res.status===200){
              setToken('username',res.data.username)
              setToken('token',res.data.token)
              this.$router.push('/home')
            }
          })
        }else{
          console.error(this.form)
        }
      })
    }
  }

Después de realizar los cambios, puede intentar ejecutar el proyecto y funcionará normalmente.

2.404 página

A continuación, desarrollamos la página 404. La página 404 es una página general del sistema. Cualquier solicitud ilegal saltará a la página 404. Podemos referirnos a la práctica de las páginas 404 en la mayoría de los sistemas ahora, que es una imagen simple + una ruta para regresar a la página de inicio.

Prepare la imagen de fondo de la página 404 y cree los nuevos componentes de la página 404:

Código de componente:

<template>
  <div class="background-container">
    <!-- Your page content goes here -->
    <div class="content">
      <div>页面不见了!</div>
        <div>首页瞧瞧,点击<router-link to="/">这里</router-link>进入首页.</div>
    </div>
  </div>
</template>

<script>
export default {
  name: 'YourComponent',
};
</script>

<style lang="less">
/* Scoped styles for the component */

.background-container {
  /* Adjust the path to your actual image file */
  background-image: url('../assets/404.jpg');
  background-size: cover;
  background-position: center;
  background-repeat: no-repeat;
  margin: 0;
  padding: 0;
  height: 100vh; /* Set the height to 100% of the viewport height */
  display: flex;
  justify-content: center;
  align-items: center;
  .content {
  text-align: center;
}
}
</style>

El siguiente es el paso clave para redirigir todas las solicitudes ilegales a la página 404: configurar el enrutamiento:

Cuando llega una solicitud, primero intentará hacer coincidir con precisión la ruta. Si no puede coincidir, se manejará mediante comodines. Por lo tanto, el uso de comodines en la ruta de la página 404 puede lograr el efecto de saltar a la página 404 desde la página del método de acceso.

Configuración de enrutamiento:

import Vue from 'vue'
import Router from 'vue-router'

Vue.use(Router)

export default new Router({
    routes:[
        {
            path:'/',
            redirect:'/login',
            component: ()=>import('@/components/Login')
        },
        {
            path:'/login',
            name:'Login',
            component: ()=>import('@/components/Login')
        },
        {
            path:'/home',
            component: ()=>import('@/components/HelloWorld')
        },
        {
            path:'*',
            name:'NotFound',
            component:()=>import('@/components/NotFound')
        }
    ],
    mode:'history'
})

Finalmente mira el efecto:

Accede a un camino inexistente y salta al 404.

3.Discutir

Analicemos el valor de Crazy Transfer api.js aquí (puede omitirlo directamente):

En el desarrollo front-end moderno, encapsular un archivo api.js independiente generalmente sirve para organizar y administrar mejor la interacción de datos entre el front-end y el back-end, y para administrar de manera uniforme las solicitudes de API. .

Aquí hay algunas razones comunes:

  1. Organización y mantenibilidad del código: Centralizar todas las solicitudes de API que se comunican con el backend en un solo archivo facilita la organización y el mantenimiento de su código. Esto facilita que los equipos encuentren y modifiquen el código relacionado con la API.

  2. Administre direcciones API de forma centralizada: Administre de manera centralizada todas las direcciones API en api.js, lo que facilita a los equipos la administración y actualización de estas direcciones. No es necesario Realice búsquedas y reemplazos exhaustivos en toda la aplicación.

  3. Encapsular lógica de solicitud: En api.js, puede encapsular alguna lógica de solicitud común, como interceptores para procesar solicitudes y respuestas, y la inyección de información de autenticación, espera. Esto ayuda a reducir la duplicación de código y mejora la reutilización del código.

  4. Fácil de probar: Encapsular la lógica de solicitud de API en un archivo facilita las pruebas unitarias. Puede concentrarse en probar el archivo api.js para asegurarse de que maneja correctamente diversas situaciones de solicitud y respuesta.

  5. Adaptar a diferentes entornos: En api.js puede configurar direcciones API en diferentes entornos, como entorno de desarrollo, entorno de prueba y entorno de producción. Esto hace que sea más conveniente cambiar de entorno sin tener que cambiar manualmente varios archivos.

  6. Colaboración en equipo: Resumir las solicitudes de API en un archivo puede facilitar la colaboración de los equipos. Los desarrolladores pueden centrarse en implementar páginas y componentes sin tener que profundizar en los detalles subyacentes de la solicitud de API.

  7. Mejor manejo de errores: En api.js, los errores se pueden manejar de forma centralizada, como el procesamiento unificado de códigos de estado de error, la adición de mensajes de error comunes, etc. Proporcionando así una mejor experiencia de usuario.

En general, encapsular un archivo api.js independiente ayuda a mejorar la capacidad de mantenimiento, la capacidad de prueba y la eficiencia de la colaboración en equipo del código y, al mismo tiempo, proporciona soluciones para varios escenarios. Mejor flexibilidad.

Supongo que te gusta

Origin blog.csdn.net/Joker_ZJN/article/details/134425895
Recomendado
Clasificación