DEV Community: Giovani Fouz

🚀 WebVirt: Carga tu SPA en Android WebView con solo 3 líneas de código

Giovani Fouz — Fri, 24 Apr 2026 05:16:55 +0000

La primera vez que intenté cargar una SPA de React en un WebView pensé que sería trivial. No lo fue. Terminé escribiendo más de 150 líneas solo para:

servir archivos desde assets
interceptar requests manualmente
arreglar rutas de React Router
y evitar errores 404 en producción

Después de repetir ese proceso varias veces… decidí simplificarlo. Así nació WebVirt.

🎯 El problema

Cargar una SPA (React, Vue, Angular, Svelte) dentro de un WebView en Android implica:

WebViewAssetLoader
shouldInterceptRequest
manejo manual de rutas
configuración de headers y MIME types
cache

No es difícil… pero sí repetitivo, verboso y propenso a errores.

⚡ La solución

Con WebVirt, todo se reduce a esto:

WebVirt.with(this)
    .host("miapp.local")
    .bind(webView);

Eso es todo.

Tu WebView ya puede cargar una SPA completa desde assets sin configuración adicional.

✨ ¿Qué hace WebVirt?

WebVirt actúa como un servidor web virtual dentro de tu APK.

Intercepta las peticiones del WebView y sirve los archivos directamente desde assets, resolviendo automáticamente los problemas más comunes.

🔁 SPA routing automático

Si usas React Router (o similar), no necesitas configuración extra.

/dashboard → WebVirt sirve index.html → tu router toma el control

💾 Caché inteligente

HTML → no cacheado (para reflejar cambios)
JS/CSS → cacheado agresivamente (tipo CDN)
Otros archivos → streaming directo

🔒 Seguridad básica integrada

Prevención de directory traversal (../)
Validación de rutas
Headers seguros por defecto

📁 MIME types listos

Soporte para HTML, JS, CSS, JSON, imágenes, fuentes, WASM y más.

🧪 Ejemplo real

Supongamos que tienes un build de React (Vite, CRA, etc.):

app/src/main/assets/
├── index.html
└── assets/
    ├── index.js
    └── index.css

Solo haces:

webView.loadUrl("https://miapp.local/");

¡Y listo!

✅ React Router funciona
✅ No hay 404 en rutas internas
✅ No necesitas lógica extra

🧠 ¿Cómo funciona?

A alto nivel:

WebView → intercept request → WebVirt → assets → response

Detecta si la URL pertenece a tu host virtual.
Resuelve si es archivo o ruta SPA.
Sirve desde memoria o desde assets.

Sin magia, solo encapsulación de lo que normalmente harías a mano.

🤔 ¿Por qué usarlo?

Porque evita repetir lo mismo en cada proyecto:

menos código boilerplate
menos errores en routing
mejor experiencia de desarrollo

No reemplaza las herramientas existentes,
simplemente las abstrae en una API más simple.

🚀 Uso rápido en tu MainActivity

WebVirt.with(this)
    .host("miapp.local")
    .bind(webView);

webView.loadUrl("https://miapp.local/");

🔮 Próximamente

Publicación en Maven Central / JitPack
Kotlin DSL
LRU cache configurable
Hooks para personalización

📦 Código y documentación

Estoy preparando el repo público con README completo y ejemplos.

Si te interesa el proyecto o quieres probarlo antes:

👉 Déjame un comentario
👉 o sígueme para actualizaciones

🎯 Conclusión

Cargar una SPA en un WebView no debería tomar 150 líneas.

Con WebVirt:

✅ es simple
✅ es rápido
✅ funciona

¿Te ha pasado lo mismo con WebView?
Me interesa saber cómo lo estás resolviendo tú 👇

Tu WebView no necesita un servidor HTTP. Necesita un Virtual Host.

Giovani Fouz — Sun, 19 Apr 2026 09:01:38 +0000

Cómo un patrón de los años 90 resolvió uno de los problemas más frustrantes del desarrollo móvil moderno

Hay una idea en ingeniería de software que reaparece una y otra vez, con décadas de distancia y en plataformas completamente distintas. Una idea tan elegante que la industria la redescubre cada cierto tiempo, la viste con nueva ropa, y la presenta como si fuera nueva.

Esta es la historia de esa idea. Y de cómo terminó viviendo dentro de una app Android.

El problema que nadie quiere admitir

Construir una app móvil con React, Vue o cualquier framework web moderno es tentador. Tienes un equipo que ya sabe web, una base de código compartida, y la promesa de "escribe una vez, corre en todas partes."

Hasta que llega el momento de cargar tu app en Android sin conexión a internet.

Android no tiene un servidor local. WebView no sabe hablar con tu carpeta assets/ como si fuera un dominio real. Y React Router — el corazón de la navegación en casi toda SPA moderna — necesita que las rutas como /dashboard o /perfil/123 devuelvan siempre el mismo index.html, sin importar qué tan profunda sea la URL.

Sin eso, tu app se rompe. El usuario navega, presiona atrás, recarga — y ve una pantalla en blanco o un error 404 que no debería existir.

La solución obvia sería levantar un servidor HTTP local. Pero eso consume batería, requiere permisos, complica el ciclo de vida de la app, y abre vectores de seguridad innecesarios. No es la respuesta correcta.

La respuesta correcta tiene 30 años de historia detrás.

1991: Cuando los servidores aprendieron a mentir (bien)

En los primeros días de la web, cada URL correspondía a un archivo físico en el disco del servidor. /pagina.html era literalmente un archivo llamado pagina.html. Simple, predecible, rígido.

El problema llegó cuando los sitios crecieron. Un servidor físico, múltiples dominios. ¿Cómo diferenciaba el servidor a cuál de ellos le hablaba el visitante?

La respuesta fue el Virtual Hosting: la capacidad de un solo servidor de hacerse pasar por muchos, respondiendo diferente según el dominio que el cliente pedía. Apache HTTP Server lo popularizó a mediados de los 90. Un servidor físico podía alojar empresa-a.com, empresa-b.com y empresa-c.com simultáneamente, cada uno con su propio espacio de archivos, sus propias reglas, su propia identidad.

Era, en esencia, enseñarle a un servidor a interceptar una petición y decidir: ¿quién eres tú y qué te mereces recibir?

Nginx lo refinó. Los CDNs lo escalaron a millones de dominios. Y el patrón quedó grabado en el ADN de la infraestructura web moderna.

2010: Las SPAs rompen todo (de nuevo)

Cuando llegaron las Single Page Applications, el Virtual Hosting tuvo que evolucionar.

Una SPA tiene una sola entrada: index.html. Todo lo demás — rutas, vistas, estados — es JavaScript puro que corre en el navegador. El servidor no sabe nada de /dashboard o /usuario/perfil. Cuando alguien recarga esa URL, el servidor busca un archivo llamado dashboard en el disco. No existe. 404.

La solución fue tan simple como poderosa: el fallback a index.html. Si el servidor no encuentra el archivo estático solicitado, en lugar de responder con un error, devuelve siempre index.html. React Router toma el control desde ahí y reconstruye la vista correcta.

En Nginx, son dos líneas:

try_files $uri $uri/ /index.html;

En ASP.NET Core, Microsoft lo formalizó como middleware oficial con MapFallbackToFile("index.html"). El patrón tenía nombre, documentación, y respaldo institucional.

Pero todo eso asume que tienes un servidor. ¿Qué pasa cuando no lo tienes?

2024: El mismo patrón, sin servidor

Android tiene un mecanismo poco conocido pero extraordinariamente poderoso: shouldInterceptRequest. Cada vez que el WebView está a punto de hacer una petición de red, se detiene y pregunta: ¿alguien quiere manejar esto antes que yo?

La mayoría de los desarrolladores lo ignora. Algunos lo usan para bloquear anuncios o inyectar headers. Pero hay una tercera posibilidad: usarlo para construir un servidor virtual completo que nunca hace una petición de red real.

Eso es exactamente lo que hace VirtualHostManager.

Cuando el WebView intenta cargar https://app.gfouz.com/assets/main.js, la clase intercepta esa petición antes de que salga al mundo. Busca el archivo en la carpeta assets/ del APK. Lo sirve directamente, con el MIME type correcto, con los headers de caché apropiados, sin tocar internet.

Y cuando el WebView pide https://app.gfouz.com/dashboard — una ruta de React Router que no existe como archivo — la clase reconoce que no tiene extensión, asume que es una ruta SPA, y devuelve index.html. React Router hace el resto.

El servidor está dentro de la app. El dominio es ficticio. Las peticiones nunca salen del dispositivo. Y React Router nunca se entera de la diferencia.

Por qué esto importa más de lo que parece

La mayoría de soluciones para este problema siguen uno de dos caminos: usar file:// (que rompe CORS y tiene restricciones de seguridad severas) o levantar un servidor HTTP local con librerías como NanoHTTPD (que consume recursos y complica el ciclo de vida de la app).

VirtualHostManager toma un tercer camino: habitar la infraestructura existente del WebView en lugar de luchar contra ella o rodearla.

El resultado es una clase que:

· No abre puertos de red.
· No requiere permisos adicionales.
· Cachea solo lo que vale cachear (index.html, que se pide en cada navegación).
· Transmite archivos grandes como streams, sin cargarlos completos en RAM.
· Valida rutas para prevenir path traversal attacks.
· Soporta 25 tipos de archivo con sus MIME types correctos.
· Funciona en Android 4.1 en adelante.

Y hace todo eso en menos de 200 líneas de Java.

El patrón que no envejece

Lo fascinante de esta historia no es la clase en sí. Es que el problema — ¿cómo sirvo contenido estático con inteligencia? — ha tenido exactamente la misma solución en cada era de la computación:

1995 → Apache Virtual Hosting
2005 → Nginx try_files
2016 → ASP.NET Core MapFallbackToFile
2024 → Android shouldInterceptRequest + SPA fallback

El contexto cambia. El hardware cambia. Los frameworks cambian. El patrón permanece.

Eso, en ingeniería de software, es la señal más confiable de que algo es fundamentalmente correcto.

VirtualHostManager es parte de FouzStack — una colección de soluciones de ingeniería para desarrollo móvil con tecnologías web.

gfouz (Giovani Fouz) · GitHub

Welcome, I'm excited to share my journey, skills, and projects with you. Dive in, explore my projects, and get to know the developer behind the screen. - gfouz

github.com

Android Virtual Host and Fake Server

Giovani Fouz — Tue, 14 Apr 2026 20:29:30 +0000

🚀 Virtual Host para Android: Mi réplica nativa del SetVirtualHostNameToFolderMapping de Microsoft WebView2... ¡pero para WebView de Android!

Durante algún tiempo observé una característica elegante de WebView2 en .NET: SetVirtualHostNameToFolderMapping. Te permite mapear un hostname virtual (como https://miapp.local/) directamente a una carpeta local, sirviendo archivos estáticos de forma limpia, segura y con soporte perfecto para Single Page Applications (SPA) como React, Svelte, Vue o Angular.

En Android, la historia siempre ha sido más complicada. La mayoría de soluciones recurren a trucos, copiar assets a archivos internos, servidores locales embebidos (como react-native-static-server) o frameworks completos que añaden capas de abstracción.

Hasta ahora.

Presento VirtualHostManager: mi implementación propia, ligera y optimizada en Java/Kotlin para Android. Una clase con responsabilidad única que transforma tu WebView en un mini-servidor virtual inteligente, inspirada directamente en la solución de Microsoft pero adaptada al ecosistema Android.

¿Qué hace exactamente?

Sirve todos tus assets estáticos desde la carpeta assets/ (o un subdirectorio).
Maneja automáticamente el fallback a index.html para rutas de React Router, Vue Router, etc. (cualquier ruta sin extensión se trata como SPA).
Soporta dominio virtual seguro (https://tudominio.local/).
Optimizada para bajo consumo de RAM: solo cachea index.html (el archivo más solicitado), el resto se sirve con InputStream directo sin cargar todo en memoria.
Manejo seguro de paths (evita ../ y accesos no deseados).
Headers inteligentes de caché (immutable para JS/CSS/imágenes).
Compatible con versiones antiguas de Android.

Aquí el corazón de la clase (código completo en los comentarios o en el repo si lo publico):

// Ejemplo de uso súper simple
VirtualHostManager vhm = new VirtualHostManager(context, "miapp.local", "dist/");

webView.setWebViewClient(new WebViewClient() {
    @Override
    public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
        if (vhm.shouldIntercept(request.getUrl().toString())) {
            return vhm.serveStaticAsset(request.getUrl().toString());
        }
        return super.shouldInterceptRequest(view, request);
    }
});

webView.loadUrl(vhm.getVirtualBaseUrl() + "index.html");

¿Es esto una innovación a nivel de sistemas y arquitectura?

No, no es una innovación
disruptiva a nivel de sistemas o arquitectura, pero sí es una buena solución y mejora de calidad sobre las soluciones típicas.

Algunas ventajas:

Portabilidad de conceptos maduros de escritorio a móvil — Llevamos una feature potente de WebView2 (.NET) de Microsoft al mundo Android de forma limpia y nativa, sin depender de bibliotecas pesadas ni servidores embebidos.
Arquitectura minimalista y eficiente — En lugar de lanzar un servidor HTTP completo (con overhead de hilos, sockets y consumo de batería), usamos el mecanismo nativo de shouldInterceptRequest del WebView. Es más directo, ligero y respeta el ciclo de vida de la app.
Optimización consciente de recursos móviles — El diseño prioriza bajo uso de RAM y CPU, algo crítico en dispositivos Android de gama media/baja. El cacheo lazy y thread-safe de solo index.html es un detalle pequeño pero poderoso para SPAs con navegación frecuente.

No es "reinventar la rueda". Es traer la rueda correcta al vehículo correcto, con mejoras específicas para el entorno móvil.

Ventajas frente a soluciones modernas existentes

Vs. React Native + WebView (o react-native-webview):

React Native obliga a un puente JS → Native, añade complejidad de ecosistema y tamaño de APK. Con VirtualHostManager cargas tu SPA React/Vue directamente en un WebView nativo puro. Menos capas = mejor rendimiento, menor tamaño y mantenimiento más simple si ya tienes el frontend web.
Vs. Capacitor / Ionic / Cordova:

Estos frameworks son geniales para acceso a APIs nativas, pero introducen su propio runtime, plugins y bridge. Si tu app es principalmente una SPA web bien hecha, VirtualHostManager te da control total sin el overhead. Quieres cámara o notificaciones? Añades solo los permisos y llamadas nativas que necesites, sin arrastrar todo el framework.
Vs. WebViewAssetLoader (oficial de AndroidX):

Es buena, pero más básica. No maneja automáticamente el fallback SPA de forma tan elegante, ni domina el concepto de "virtual host" con dominio personalizado. Mi implementación es más cercana a la experiencia de WebView2.
Vs. servidores locales embebidos (NanoHTTPD, etc.):

Mucho más pesado en memoria y batería. Mi solución es interceptación directa: cero sockets, cero hilos extras.

Resultado: una app más ligera, más rápida al arrancar, con mejor ahorro de batería y que se siente como una experiencia web premium dentro de un contenedor nativo.

¿Para quién es ideal?

Desarrolladores que tienen una SPA moderna (React, Vue, Svelte, etc.) y quieren empaquetarla como app Android con mínima fricción.
Equipos que buscan máximo rendimiento y control fino sin adoptar un framework completo.
Quienes valoran la simplicidad y la inspiración cross-platform (de .NET a Android).

Esta clase es open-source en espíritu: la comparto porque creo que la comunidad Android merece herramientas más elegantes para servir SPAs locales, teniendo muy en cuenta que las aplicaciones web son cada vez más sofisticadas y de alta tecnología.

¿Qué opinas?

¿Te ha pasado que luchas con WebView + SPA y terminas añadiendo capas innecesarias?

¿Crees que vale la pena priorizar esta simplicidad sobre frameworks más "todo en uno"?

Me encantaría leer tus experiencias en comentarios. Si te sirve, ¡úsala, mejórala y compártela!

Android #WebView #React #typescript #tailwindcss #SPA #MobileDevelopment #Architecture #DotNet #Kotlin #Java

Virtual Host for Android

Giovani Fouz — Tue, 14 Apr 2026 04:37:16 +0000

Implementando el Patrón UseSpa de ASP.NET Core en Android WebView: Una Alternativa Ligera a Cordova para SPAs Offline

Cómo construí un enrutador SPA eficiente para apps React que se ejecutan completamente desde los assets de Android, sin servidor HTTP y con consumo mínimo de batería y de RAM.

El Problema: El Enrutamiento SPA se Rompe en Android WebView

Si alguna vez has intentado empaquetar una app React o Vue dentro de un WebView de Android usando file:///android_asset/index.html, te has topado con este muro:

net::ERR_FILE_NOT_FOUND

La página de inicio carga perfectamente. Pero cuando el usuario navega a /inventario y refresca la página (o recibe un enlace profundo), el WebView intenta buscar el archivo físico /inventario dentro de la carpeta assets. No existe. La app se rompe.

Las soluciones tradicionales son pesadas:

Solución Problema
Cordova / Capacitor Levanta un servidor HTTP real en localhost. Funciona, pero consume batería y RAM.
PWA con Service Workers Requiere HTTPS e internet para la primera carga. No es verdaderamente offline-first.

Pero espera—Microsoft ya resolvió esto elegantemente en ASP.NET Core:

app.UseStaticFiles();
app.UseSpa(spa => spa.Options.DefaultPage = "/index.html");

Este middleware sirve archivos estáticos normalmente, pero hace fallback a index.html para cualquier ruta que no tenga extensión de archivo. React Router toma el control a partir de ahí.

Entonces me pregunté: "¿Por qué Android no tiene algo así?"

La Solución: VirtualHostManager

Desarrollé una clase Java ligera que replica el comportamiento de UseSpa de ASP.NET completamente dentro de la capa de interceptación de peticiones del WebView. Sin servidor HTTP local. Sin Cordova. Android SDK puro o Java sin dependencias ni librerías externas.

El Corazón de la idea

/**
 * Determina si una ruta solicitada es una ruta de React Router.
 * Lógica: Si no tiene extensión de archivo, es una ruta SPA.
 */
private boolean isReactRouterRoute(String assetPath) {
    if (assetPath == null || assetPath.isEmpty()) return true;
    int lastDot = assetPath.lastIndexOf('.');
    return lastDot == -1; // Sin extensión = ruta SPA
}

Esta simple validación es lo que permite que /inventario, /reportes o /configuracion no devuelvan 404, sino que entreguen index.html para que React Router maneje la navegación.

Configuración del WebView

VirtualHostManager vhm = new VirtualHostManager(this, "app.local", "www");

webView.setWebViewClient(new WebViewClient() {
    @Override
    public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
        String url = request.getUrl().toString();
        if (vhm.shouldIntercept(url)) {
            return vhm.serveStaticAsset(url);
        }
        return super.shouldInterceptRequest(view, request);
    }
});

webView.loadUrl(vhm.getVirtualBaseUrl()); // https://app.local/

El Código Completo (Fragmentos Clave)

Interceptación y Fallback al Index

public WebResourceResponse serveStaticAsset(String url) {
    try {
        String relativePath = urlToAssetPath(url);
        String fullAssetPath;

        // 🧠 Aquí está la innovación: detección de rutas SPA
        if (isReactRouterRoute(relativePath) || relativePath.isEmpty()) {
            fullAssetPath = indexAssetPath; // Fallback a index.html
        } else {
            fullAssetPath = assetSubfolder + relativePath;
        }

        // Servir desde assets con MIME types y headers de caché
        // ...
    } catch (IOException e) {
        return create404Response();
    }
}

Cacheo Thread-Safe de index.html

private volatile byte[] indexHtmlCache;

// Double-checked locking para evitar bloqueos innecesarios en lecturas concurrentes
if (fullAssetPath.equals(indexAssetPath)) {
    if (indexHtmlCache == null) {
        synchronized (this) {
            if (indexHtmlCache == null) {
                indexHtmlCache = loadAssetBytes(fullAssetPath);
            }
        }
    }
    dataStream = new ByteArrayInputStream(indexHtmlCache);
}

Validación de Seguridad contra Path Traversal

private void validatePath(String path) {
    if (path.isEmpty() || path.contains("..") || path.contains("\\") || path.startsWith("/")) {
        throw new SecurityException("Path inválido: " + path);
    }
}

Limpieza de URLs con Fragmentos y Query Params

private String urlToAssetPath(String url) {
    String path = url.replace("https://", "").replace("http://", "")
        .replace(virtualHost + "/", "").replace(virtualHost, "");

    if (path.contains("?")) path = path.split("\\?")[0];
    if (path.contains("#")) path = path.split("#")[0];

    return path;
}

Optimizaciones que Marcan la Diferencia

Característica Implementación Beneficio
Cacheo de index.html volatile + double-checked locking Acceso concurrente sin bloqueos
Cero sobrecarga de RAM para otros assets InputStream directo, sin byte[] Memoria mínima en dispositivos viejos
Headers de caché inmutables max-age=31536000 para assets con hash El WebView no re-descarga archivos
Protección contra Path Traversal Bloqueo de ../ y rutas absolutas Seguridad en apps offline
Soporte para subcarpetas assetSubfolder configurable Compatible con npm run build sin cambios

Comparativa: VirtualHostManager vs. Soluciones Existentes

Métrica Cordova/Capacitor WebView + file:// VirtualHostManager
Soporte SPA Routing ✅ Sí ❌ Roto ✅ Sí
Requiere Servidor HTTP ✅ Sí (localhost) ❌ No ❌ No
Consumo de Batería Alto Bajo Mínimo
Consumo de RAM ~40-60 MB ~10 MB ~8 MB
Deep Linking ✅ Sí ❌ No ✅ Sí
Hot Updates ❌ No ❌ No ✅ Sí (reemplazar assets)
Tiempo de inicio Lento (espera al servidor) Instantáneo Instantáneo

Caso de Uso Real: App de Inventarios en Cuba

Esta solución está actualmente en producción en una app de control de inventarios para pequeños negocios en Cuba, donde:

· El internet es caro e inestable.
· Los dispositivos tienen RAM y batería limitadas.
· El trabajo por turnos requiere traspaso de datos offline vía exportación de archivos.

La app funciona completamente offline, sincroniza mediante archivos exportados, y genera reportes PDF—todo desde un único WebView con persistencia de datos utilizando a IndexDB.

Código Fuente Completo
En fin quiero compartir este pensamiento:

No necesitas Cordova para tener una SPA funcional en Android. A veces, una clase Java de 150 líneas es todo lo que necesitas para que React Router funcione como si estuviera en un servidor real.

Microsoft lo hizo bien con UseSpa. Ahora Android también lo tiene, (VirtualHostManager) una clase de 150 líneas en Java.

¿Preguntas? ¿Ideas?

Déjamelas en los comentarios. Si estás construyendo algo similar para entornos offline-first en Latinoamérica, me encantaría saber de tu proyecto.

Giovani Fouz
Desarrollador de Software. No deberíamos aferrarnos a ciertas tecnologías donde radica nuestra zona de comodidad sino explorar nuevas alternativas, pero no termino sin mencionar: ¡ Wow vaya éxito el de React o Typescript o Tailwindcss ! ¡ Que grandiosas herramientas!
Cuba, 2026

Comprendiendo el uso del Asterisco (`*`) y Doble Asterisco (`**`) en Python

Giovani Fouz — Sat, 09 Nov 2024 11:15:03 +0000

Cuando trabajamos en Python, a menudo nos encontramos con situaciones en las que necesitamos que nuestras funciones sean flexibles y capaces de manejar diferentes tipos y cantidades de argumentos. Para facilitar esto, Python ofrece dos operadores muy útiles: el asterisco simple (*) y el doble asterisco (**). En este post, exploraremos en detalle su funcionamiento, así como su aplicación en funciones, clases y estructuras de datos como listas y diccionarios.

¿Qué son las estructuras de datos en Python?

Antes de entrar en el uso del asterisco, es importante entender qué son las estructuras de datos. En Python, las estructuras de datos son formas de organizar y almacenar datos en el programa. Las más comunes son:

Listas: Colecciones ordenadas que permiten elementos duplicados.
Tuplas: Similares a las listas, pero son inmutables.
Diccionarios: Colecciones no ordenadas de pares clave-valor.

Estas estructuras son fundamentales para manejar datos en Python y son el contexto donde los operadores * y ** se vuelven particularmente interesantes.

Usos del Asterisco Simple (`*`)

1. Funciones con Argumentos Variables

El asterisco simple se utiliza principalmente en funciones para permitir que acepten un número variable de argumentos posicionales. Esto significa que puedes pasarle cualquier cantidad de argumentos y todos serán tratados como una tupla dentro de la función.

def func(*args):
    for arg in args:
        print(arg)

func(1, 2, 3, 4)

# Esto imprime: 1 2 3 4

Desempaquetado de Listas o Tuplas También puedes usar el asterisco simple para desempaquetar elementos de una lista o tupla al pasar argumentos a una función.

numbers = [1, 2, 3]
print(*numbers)  # Esto imprime: 1 2 3

Este uso del asterisco puede ser muy conveniente cuando tienes una lista de elementos y quieres pasarlos como argumentos a otra función.

Usos del Doble Asterisco (`**`)

Funciones con Argumentos de Palabra Clave El doble asterisco se utiliza para permitir que una función acepte un número variable de argumentos de palabra clave (nombre-valor). Dentro de la función, estos argumentos se almacenan en un diccionario.

def func(**kwargs):
    for key, value in kwargs.items():
        print(f"{key}: {value}")

func(name="Alice", age=30)
# Salida:
# name: Alice
# age: 30

Desempaquetado de Diccionarios Al igual que el asterisco para listas y tuplas, puedes usar el doble asterisco para desempaquetar pares clave-valor desde un diccionario al llamar a una función.

data = {"name": "Alice", "age": 30}
func(**data)  # Osea es lo mismo que: func(name="Alice", age=30)

Usos Avanzados de * y ** en Clases

class MyClass:
    def __init__(self, *args, **kwargs):
        self.args = args
        self.kwargs = kwargs

obj = MyClass(1, 2, a=3, b=4)
print(obj.args)   # (1, 2)
print(obj.kwargs) # {'a': 3, 'b': 4}

En Herencia
Puedes utilizar *args y **kwargs para pasar argumentos al constructor de la clase base, lo que permite que la clase derivada extienda el comportamiento del constructor de la clase base.

class Base:
    def __init__(self, x):
        self.x = x

class Derived(Base):
    def __init__(self, x, *args, **kwargs):
        super().__init__(x)  # Llama al constructor de Base
        # Puedes hacer algo adicional con args y kwargs aquí

d = Derived(10)

Combinaciones de simple y doble asterisco:
A veces, puede ser útil combinar tanto los argumentos posicionales como los de palabra clave en tus funciones para permitir un manejo completo de los datos de entrada:

def mixed_args(a, b, *args, **kwargs):
    print(a, b)
    print(args)
    print(kwargs)

mixed_args(1, 2, 3, 4, x=5, y=6)

#Salida:

# 1 2
# (3, 4)
# {'x': 5, 'y': 6}

Documentación Oficial de Python sobre Funciones
Python para Todos - Curso Gratuito
Real Python - Unpacking in Python
W3Schools - Python Functions (Defining Functions)

Resumen:

args es útil para recibir un número variable de argumentos posicionales, mientras que kwargs es útil para recibir un número variable de argumentos de palabra clave.
Puedes usar simple y doble asterisco para desempaquetar listas/tuplas y diccionarios, respectivamente, al llamar funciones.
Ambos operadores pueden mejorar la flexibilidad y reutilización de tu código, permitiendo funciones que manejan diferentes tipos de entradas de manera eficiente.
Recursos Útiles

React query, hook personalizado.

Giovani Fouz — Sat, 09 Nov 2024 08:02:56 +0000

En aplicaciones de React, es común necesitar acceder a datos de una API externa. Tradicionalmente, muchos desarrolladores utilizan métodos nativos de javascript como fetch dentro de los componentes, lo que puede llevar a problemas de administración del estado y a un manejo complicado de efectos secundarios (side effects). Aquí es donde React Query entra en juego.

¿Qué es React Query?

React Query es una biblioteca destinada a simplificar las operaciones de obtención y manejo de datos en React. Proporciona potentes funciones para:

Efectuar solicitudes de datos de una API.
Almacenar y sincronizar el estado de la UI con los datos.
Realizar refetching automáticamente y gestionar cachés.
Nuestro Hook Personalizado

A continuación, veamos nuestro hook personalizado, useCustomQuery:

import { useQuery } from '@tanstack/react-query';

export type GenericObject = {
  [key: string]: any;
};

export type QueryFunction = (
  url: string,
  token?: string,
) => Promise<GenericObject>;

export const useCustomQuery = (
  queryFunction: QueryFunction,
  url: string,
  queryKey: string[],
  token?: string,
) => {
  const { isPending, isError, data, error, refetch, isLoading } = useQuery<
    GenericObject | GenericObject[]
  >({
    queryKey: [queryKey],
    queryFn: () => queryFunction(url, token),
  });

  return { data, error, isError, isPending, refetch, isLoading };
};

Desglose del Hook

GenericObject y QueryFunction:

Definimos tipos genéricos que facilitan el trabajo con objetos y funciones que realizan fetching de datos. Esto asegura que nuestro código pueda adaptarse a diferentes estructuras de datos que puedan regresar las APIs.

useQuery:

Usamos el hook useQuery de React Query, que maneja automáticamente el estado de nuestras solicitudes. Proporciona propiedades útiles para manejar la carga de datos, errores y refetching.

Esto mejora la calidad del código y reduce bugs.
Interfaces Genéricas: Utilizando interfaces genéricas, podemos definir estructuras de datos que se adaptan a diferentes situaciones. Esto hace que el código sea más reutilizable y fácil de mantener.
Mejor Documentación: El uso de TypeScript como una herramienta de documentación proporcionada por los tipos mejora la comprensión de cómo se deben usar las funciones y qué tipo de datos se esperan.

Enlaces Útiles

React Query:
- Documentación oficial: TanStack Query Documentation
- Guía de inicio rápido: Getting Started with React Query
TypeScript:
- Documentación oficial: TypeScript Documentation
- Guía de TypeScript para React: Using TypeScript with React
GitHub de React Query:
- Repositorio oficial: TanStack Query (React Query) GitHub
Ejemplos y Tutoriales:
- Tutorial de RapidAPI sobre React Query: Getting Started with React Query
- Artículo sobre los beneficios de utilizar React Query: Benefits of Using React Query

Conclusión

Integrar un hook personalizado junto con React Query y TypeScript en tus aplicaciones React transforma la forma en que gestionas las solicitudes de datos. No sólo mejora la experiencia de desarrollo al reducir la carga de lógica de manejo de estado, sino que también enriquece la robustez y facilidad de mantenimiento de tu código.
Espero que encuentren útil este enfoque y les animo a probarlo en sus propios proyectos. ¡Feliz codificación!

Errores Comunes de Pylint. Guía Práctica

Giovani Fouz — Mon, 27 May 2024 09:10:20 +0000

Pylint es una herramienta de análisis estático de código que se utiliza para encontrar errores y mejorar la calidad del código Python. Sin embargo, enfrentarse a los errores que reporta puede ser desalentador, especialmente para los desarrolladores novatos. Aquí exploramos algunos de los errores más comunes que lanza Pylint, cómo resolverlos y cómo podemos beneficiarnos de estas correcciones para escribir un código más limpio y eficiente.

1- C0103: Variable name "x" doesn't conform to snake_case naming style
Error:
Este error se produce cuando el nombre de una variable no sigue la convención de nombres en Python, que es usar snake_case.