Cuando el usuario se equivoca de red, el producto debe impedirlo lo antes posible, en lugar de esperar a que firme y luego reportar un error.
DuskEVM tiene una identidad de red clara: la red de pruebas tiene el Chain ID 745, y los demás entornos también tienen IDs diferentes. Para los desarrolladores, esto es solo un parámetro de configuración; para los usuarios comunes, es una fuente de errores frecuente. Es posible que la persona esté un segundo en otra cadena EVM y al siguiente, en la app de Dusk, haga clic en enviar; además, la apariencia del pop-up del monedero es casi la misma.
Un buen producto, después de leer el monedero, debe comparar el Chain ID de inmediato, convertir la página en un estado no operativo y decirle con claridad a qué red deberá cambiar. No debería dejar que el usuario complete el formulario, apruebe Tokens y firme una cadena de mensajes primero, para recién entonces decir “la red no es correcta” usando un RPC Error. Cuanto antes se corte el error, menor será el costo.
Las pruebas más detalladas incluyen: que el usuario rechace el cambio de red, que el monedero no reconozca la red, que durante el cambio se modifique la cuenta y que la página tenga en caché el saldo de la cuenta anterior. La aplicación debe responder a los cambios de Network y Account del monedero, limpiando a tiempo las cotizaciones y las credenciales antiguas. Si no, la página parecerá seguir adelante, pero a nivel de negocio ya cambió de persona.
El Dusk Connect con @Dusk descubrirá monederos compatibles y percibirá los cambios de estado; $DUSK #dusk . Lo que debe hacer la capa de aplicación es convertir esas señales en una interacción segura. Considero que para juzgar si un producto Web3 está maduro, normalmente basta con ver cómo maneja cuando los usuarios no siguen el guion estándar.
DuskEVM tiene una identidad de red clara: la red de pruebas tiene el Chain ID 745, y los demás entornos también tienen IDs diferentes. Para los desarrolladores, esto es solo un parámetro de configuración; para los usuarios comunes, es una fuente de errores frecuente. Es posible que la persona esté un segundo en otra cadena EVM y al siguiente, en la app de Dusk, haga clic en enviar; además, la apariencia del pop-up del monedero es casi la misma.
Un buen producto, después de leer el monedero, debe comparar el Chain ID de inmediato, convertir la página en un estado no operativo y decirle con claridad a qué red deberá cambiar. No debería dejar que el usuario complete el formulario, apruebe Tokens y firme una cadena de mensajes primero, para recién entonces decir “la red no es correcta” usando un RPC Error. Cuanto antes se corte el error, menor será el costo.
Las pruebas más detalladas incluyen: que el usuario rechace el cambio de red, que el monedero no reconozca la red, que durante el cambio se modifique la cuenta y que la página tenga en caché el saldo de la cuenta anterior. La aplicación debe responder a los cambios de Network y Account del monedero, limpiando a tiempo las cotizaciones y las credenciales antiguas. Si no, la página parecerá seguir adelante, pero a nivel de negocio ya cambió de persona.
El Dusk Connect con @Dusk descubrirá monederos compatibles y percibirá los cambios de estado; $DUSK #dusk . Lo que debe hacer la capa de aplicación es convertir esas señales en una interacción segura. Considero que para juzgar si un producto Web3 está maduro, normalmente basta con ver cómo maneja cuando los usuarios no siguen el guion estándar.