Saltar al contenido principal

Durante el proceso de desarrollo de una mini aplicación, pueden surgir algunos problemas y soluciones.

init-qydesarrollo front-endmini-appmpvueAlrededor de 5 min

Prefacio

Recientemente he completado una pequeña aplicación de distribución de contenido, cuya función principal es proporcionar la edición, carga y comentarios de los artículos (además de la cuenta pública). Para esto, se utilizó el framework mpvue y vant-weapp. Elegí este framework porque es el que mejor conozco y, dado que el proyecto tenía prisa, aunque había investigado sobre uniapp, no lo había utilizado antes y requeriría tiempo para aprenderlo y evitar problemas. Por lo tanto, finalmente decidí utilizar este framework tecnológico como base para esta pequeña aplicación. Dado que nunca había trabajado antes con este tipo de aplicación, me encontré con algunos problemas con componentes poco comunes de WeChat.

Registro de problemas encontrados

Componente editor

La edición de los artículos es una de las funciones principales, y debido a que los artículos deben mostrar tanto imágenes como texto, después de discutirlo con el equipo de desarrollo, se eligió la opción más sencilla, que es almacenarlos como texto enriquecido. En la aplicación de WeChat, se puede utilizar el componente rich-text para mostrarlos, y en el backend no hay problemas, ya que se utiliza el tipo de dato "text" en la base de datos. En el backend, se utiliza el editor de texto enriquecido tinymce, pero en la aplicación de WeChat solo encontré el componente editor.

Problemas encontrados:

  • El componente editor no permite desplazarse hacia arriba, solo se puede mover el cursor del campo de entrada.
  • Cuando se llega al final del componente editor y se presiona "Enter", el cursor se mueve al final y no es visible hasta que se ingresa contenido.
  • El componente editor proporciona muchas API, pero muchas funciones deben ser implementadas por uno mismo. Se puede consultar este enlace para obtener más información (封装富文本编辑器open in new window).
  • Aunque el componente editor tiene muchas funciones de entrada, como cargar imágenes y cambiar su tamaño, la experiencia en un dispositivo real es muy pobre y requiere que los usuarios aprendan a utilizarlo. Además, el enfoque del componente entra en conflicto con las teclas personalizadas, lo que hace que el teclado se active constantemente.

Debido a estos problemas, finalmente decidí eliminar la mayoría de las funciones del componente editor y solo conservar la función básica de edición de texto. La edición de estilos se realiza en el backend web. Aquí tengo algunas ideas de mejora, que se pueden considerar según los requisitos del proyecto en el futuro.

  • Reemplazar el componente editor por un textarea y la carga de imágenes, y luego combinarlos para enviar el texto enriquecido al backend. Los usuarios pueden elegir agregar párrafos o imágenes, lo que reduce el costo de operación. La desventaja es que no se pueden personalizar los estilos, pero tener un estilo uniforme ayuda a mantener una apariencia coherente en la aplicación de WeChat. Creo que esta es la opción más económica hasta que tenga la capacidad de lograr el mismo nivel de habilidad técnica que la edición en la cuenta pública.
  • Durante la edición, se puede abrir una página que solo contenga el componente editor, eliminando todos los demás componentes y centrándose en resolver el problema del teclado. Esta solución requiere investigación y tiene ciertos riesgos.
  • Se puede desarrollar un teclado virtual personalizado para incluir las teclas personalizadas. Esta podría ser la solución definitiva. (WeChat podría tomar esto como referencia para mejorar)
  • Esperar a que WeChat solucione el problema (sin fecha de finalización)

Diferencias en la apariencia entre iOS y Android

Este problema ha existido desde hace mucho tiempo. En realidad, una de las innovaciones de WeChat Mini Program es que se puede ejecutar en ambos sistemas al mismo tiempo y tener la misma experiencia en diferentes dispositivos (aunque algunos modelos especiales tienen problemas especiales, como el iPhone X). Pero, seamos sinceros, si hay un problema, hay que solucionarlo.

iOS tiene requisitos de formato diferentes a Android para el método new Date() en JavaScript
Este problema se descubrió en una versión anterior de la aplicación. En esta ocasión, quiero mencionarlo de manera general.
Por lo general, el formato de fecha almacenado en el backend es yyyy-MM-dd, y el método new Date() en JavaScript puede interpretar correctamente este formato. Sin embargo, iOS es diferente a los demás, ya que solo admite el formato de fecha yyyy/MM/dd. Dado que los teléfonos Android comunes también pueden interpretar este formato, es necesario realizar un procesamiento uniforme en la cadena de fecha recibida del backend:

const dateString = "2020-12-14 00:00:00";
const date = new Date(dateString.replace(/-/g, "/"));

Si parece complicado, se puede solicitar (amenazar) al backend que realice un procesamiento de datos uniforme. Por lo general, en el backend (en este caso, Java), se puede utilizar la anotación de fastjson (una por una) o configurar un interceptor para manejar uniformemente el formato de los datos de fecha (estas configuraciones generalmente se utilizan para convertir long de Java a string, ya que el tipo de dato number en JavaScript tiene una pérdida de precisión con respecto al tipo de dato long en Java).

Problema de pérdida de enfoque de entrada en iOS (posible error)
En el diseño de formularios comunes, generalmente se utilizan campos de entrada y selectores. En la experiencia en dispositivos iOS, al hacer clic primero en el campo de entrada y luego en el selector (ya sea un selector nativo o un selector de componente Vant), el teclado no se oculta automáticamente.
La solución aquí es llamar a una API de WeChat wx.hideKeyboard(), pero la desventaja es que no se puede mostrar correctamente en la herramienta de desarrollo.

    popup(showPicker) {
      // console.log(this[showPicker])
      // this[showPicker] = true
      // 解决ios键盘不收起的问题,开发者工具时可以注掉
      wx.hideKeyboard({
        complete: res => {
          this[showPicker] = true
        }
      })
    }

El comportamiento de position: fixed; en iOS es diferente al de Android en las páginas que contienen el componente editor
Puedes encontrar más información en este informe de erroropen in new window.
Por ahora, es solo una mala experiencia, no se ha realizado ninguna modificación. La solución propuesta por el usuario de la segunda respuesta es:

En iOS, después de obtener la altura del teclado, se debe establecer manualmente la distancia inferior.

Puedes intentarlo.

Reflexiones y consideraciones

Este proyecto no es de gran envergadura, consta de 25 páginas en total, de las cuales solo dos son similares (una página con una barra de pestañas y una página normal, la página con la barra de pestañas no permite pasar parámetros fácilmente). Se reutilizan muchas páginas de listas de artículos y el resultado es bueno. Debido a la prisa del proyecto, no se desarrollaron componentes de negocio y algunos elementos similares (como los elementos de los artículos en la lista) no se reutilizaron, por lo que cualquier cambio en la interfaz de usuario debe realizarse en varios lugares, pero afortunadamente no hay muchas páginas y se puede manejar.
Al revisar todo el proceso de desarrollo, hay algunas áreas que se pueden mejorar:

  • Es necesario diseñar algunas plantillas de página comunes (lista, detalle, información) y organizar algunos métodos comunes (paginación, entrada, navegación entre páginas) para acelerar el desarrollo.
  • Es posible que sea necesario bifurcar una versión personalizada de los componentes de la interfaz de usuario y realizar modificaciones personalizadas en ellos.
  • La interacción entre el frontend y el backend requiere documentación, de lo contrario, el mantenimiento posterior será muy complicado.
  • Es conveniente diferenciar los módulos mediante la nomenclatura para facilitar la migración de módulos en caso de encontrar negocios similares en el futuro.
  • Aprender a desarrollar estilos de forma modular para facilitar las modificaciones uniformes.
  • Utilizar el software ScreenToGif para grabar efectos dinámicos y facilitar la reflexión y el aprendizaje (y escribir un blog al respecto).

Este post está traducido usando ChatGPT, por favor feedbackopen in new window si hay alguna omisión.