DEV Community: FoodieHoodie

- Apenas estou cansado; - Solo estoy cansado; - I'm just tired.

FoodieHoodie — Mon, 06 Apr 2026 17:12:23 +0000

Feudos Digitales

FoodieHoodie — Fri, 30 Jan 2026 21:31:29 +0000

Trabajo en tecnología desde que el internet "era todo campo". Vi nacer y transformarse este mundo, pero lo que ha estado ocurriendo en los últimos cinco años me asusta de verdad. El ecosistema ha cambiado de una forma depredadora. Estamos viviendo tiempos realmente extraños, donde la conveniencia se ha convertido en una trampa y nuestra dependencia de las "empresas digitales" ha alcanzado un nivel crítico.

El artículo que leí hoy solo confirmó lo que ya sentía en carne propia: el control se nos está escapando de las manos.

He decidido omitir el nombre del autor en este primer momento para que el enfoque permanezca estrictamente en las ideas. En un mundo polarizado, muchas veces el mensajero precede al mensaje. El objetivo aquí es una reflexión libre de prejuicios, permitiendo que los hechos y los contextos hablen por sí mismos.

La gravedad del escenario

Al repasar los puntos siguientes, haz un ejercicio mental: aplica cada concepto a la realidad de tu país. Piensa en la escala de datos que tu país posee sobre ti: tu historial de salud, geolocalización, conexiones familiares y vida financiera. Ahora imagina todo eso gestionado por dos o tres empresas distintas, bajo el dominio de un gobierno controlador.

El riesgo de ser rehenes digitales

La lectura nos obliga a encarar cuánto hemos transferido de nuestra soberanía personal y nacional a entidades privadas. Aquí presento tres dimensiones de esa dependencia:

La trampa de la conveniencia

No elegimos usar Google, WhatsApp o Amazon solo porque "sean buenos", sino porque se han convertido en la infraestructura básica de la vida social. Hoy, si eliminas tus cuentas en estas plataformas, no pierdes solo un "perfil"; pierdes el acceso a grupos escolares, contactos profesionales, medios de pago e incluso servicios gubernamentales. La conveniencia de ayer se ha convertido en la restricción de hoy.

El poder del "interruptor"

Imagina si, por una decisión política o un desacuerdo comercial, una Big Tech decidiera "apagar" un país. Ya hemos visto esto ocurrir a pequeña escala con bloqueos de servicios. Somos rehenes porque no somos clientes; somos súbditos de feudos digitales. Si el dueño del feudo cambia las reglas o decide que ya no eres bienvenido, tu vida digital (fotos, recuerdos, trabajo) desaparece en un clic, sin derecho a un recurso real de apelación.

La vigilancia como gobernanza

El peligro aumenta cuando el poder estatal (imagina al presidente de cualquier país) se funde con el poder tecnológico. El nivel de datos que estas empresas poseen sobre cada individuo permite una manipulación conductual y una vigilancia con la que ningún dictador del siglo XX jamás soñó. Cuando el algoritmo decide qué es lo que ves, está, en la práctica, decidiendo qué piensas y cómo votas.

Conclusión

La reflexión que queda es esta: la tecnología debería ser una herramienta de liberación, pero se ha convertido en un collar invisible.

En su artículo, Doctorow menciona que sería necesaria una fragmentación del internet, buscando alternativas descentralizadas y locales. Y esto tiene sentido: no podemos ser rehenes de alguien que simplemente puede presionar un botón y "apagarnos".

Él refuerza que, si no hay una lucha por la soberanía digital y leyes de interoperabilidad (que te permitan salir de una red social sin perder tus contactos, por ejemplo), seguiremos siendo meros pasajeros en un barco donde el capitán puede cambiar la ruta, o hundir la nave en cualquier momento, sin consultarnos.

Feudos Digitais

FoodieHoodie — Fri, 30 Jan 2026 21:28:21 +0000

Trabalho com tecnologia desde que a internet "era tudo mato". Vi esse mundo nascer e se transformar, mas o que está acontecendo nos últimos cinco anos me assusta de verdade.
O ecossistema mudou de uma forma predatória. Estamos vivendo em tempos realmente bizarros, em que a conveniência virou uma armadilha e a nossa dependência de "empresas digitais" atingiu um nível crítico.

O artigo que li hoje apenas confirmou o que eu já sentia na pele: o controle está saindo das nossas mãos.

Optei por omitir o nome do autor neste primeiro momento para que o foco permaneça estritamente nas ideias. Em um mundo de polarização, muitas vezes o mensageiro precede a mensagem. O objetivo aqui é uma reflexão livre de pré-julgamentos, permitindo que os fatos e os contextos falem por si.

A Gravidade do Cenário

Ao percorrer os pontos abaixo, faça um exercício mental: aplique cada conceito à realidade do seu país. Pense na escala de dados que o seu país possui sobre você: seu histórico de saúde, geolocalização, conexões familiares e vida financeira.
Agora imagine tudo isso sendo gerenciado por duas ou três empresas diferentes, sob o domínio de um governo controlador.

O Risco de sermos Reféns Digitais

A leitura nos obriga a encarar o quanto transferimos nossa soberania pessoal e nacional para entidades privadas. Aqui estão três dimensões dessa dependência:

A Armadilha da Conveniência

Nós não escolhemos usar Google, WhatsApp ou Amazon apenas porque "são bons", mas porque se tornaram a infraestrutura básica da vida social. Hoje, se você deletar suas contas nessas plataformas, você não perde apenas um "perfil"; você perde o acesso a grupos escolares, contatos profissionais, meios de pagamento e até serviços governamentais. A conveniência de ontem se tornou o cerceamento de hoje.

O Poder do "Interruptor"

Imagine se, por uma decisão política ou um desentendimento comercial, uma Big Tech decidisse "desligar" um país. Já vimos isso acontecer em pequena escala com bloqueios de serviços. Somos reféns porque não somos clientes; somos súditos de feudos digitais. Se o dono do feudo mudar as regras ou decidir que você não é mais bem-vindo, sua vida digital (fotos, memórias, trabalho) desaparece num clique, sem direito a recurso real.

A Vigilância como Governança

O perigo aumenta quando o poder estatal (imagine o presidente de um país, seja qual for) se funde ao poder tecnológico. O nível de dados que essas empresas possuem sobre cada indivíduo permite uma manipulação comportamental e uma vigilância com que nenhum ditador do século XX jamais sonhou. Quando o algoritmo decide o que você vê, ele está, na prática, decidindo o que você pensa e como você vota.

Conclusão

A reflexão que fica é: a tecnologia deveria ser uma ferramenta de libertação, mas se tornou uma coleira invisível.

No seu artigo, Doctorow menciona que seria necessária uma fragmentação da internet, buscando alternativas descentralizadas e locais. E isso faz sentido: não podemos ser reféns de quem pode simplesmente apertar um "botão" e nos desligar da rede, seja como indivíduo ou como país.

Ele reforça que, se não houver uma luta por soberania digital e leis de interoperabilidade (que permitam você sair de uma rede social sem perder seus contatos, por exemplo), continuaremos sendo meros passageiros em um navio onde o capitão pode mudar a rota ou afundar o barco a qualquer momento, sem nos consultar.

Implementación de Remote Config Modular (v23.x.x)

FoodieHoodie — Fri, 23 Jan 2026 12:52:35 +0000

Con el lanzamiento de la versión 23.x.x, React Native Firebase adoptó completamente la API Modular (similar al Firebase Web SDK v9).

¿Qué cambió?

En versiones anteriores se utilizaba una instancia basada en clases (por ejemplo, remoteConfig().fetchAndActivate()).

Con la API modular, la instancia de configuración se pasa como primer argumento a funciones independientes como fetchAndActivate(instance).

Implementación del Servicio

import {
  fetchAndActivate,
  getRemoteConfig,
  getValue,
  setConfigSettings
} from '@react-native-firebase/remote-config'

// Tiempo de caché (ej.: 5 minutos)
export const REMOTE_CONFIG_CACHE_TIME = 300000

let remoteConfig: any = null

/**
 * Inicializa la instancia de Remote Config y define configuraciones globales.
 */
const initializeRemoteConfig = async () => {
  if (!remoteConfig) {
    remoteConfig = getRemoteConfig()
  }

  await setConfigSettings(remoteConfig, {
    minimumFetchIntervalMillis: REMOTE_CONFIG_CACHE_TIME
  })
}

/**
 * Obtiene y activa los valores más recientes antes de retornarlos como string.
 */
const getValueAsString = async (property: string): Promise<string> => {
  await fetchAndActivate(remoteConfig)
  return getValue(remoteConfig, property).asString()
}

/**
 * Obtiene y activa los valores más recientes antes de retornarlos como boolean.
 */
const getValueAsBoolean = async (property: string): Promise<boolean> => {
  await fetchAndActivate(remoteConfig)
  return getValue(remoteConfig, property).asBoolean()
}

export const RemoteConfigService = {
  getValueAsBoolean,
  getValueAsString,
  initializeRemoteConfig
}

Cómo usarlo

1. Inicialización Global

Se recomienda inicializar el servicio al inicio del ciclo de vida de la aplicación (por ejemplo, en App.tsx o en una store de Redux).

import { useEffect } from 'react'
import { RemoteConfigService } from './services/RemoteConfigService'

const App = () => {
  const setupRemoteConfig = async () => {
    try {
      await RemoteConfigService.initializeRemoteConfig()
    } catch (error) {
      console.error('Error al inicializar Remote Config:', error)
    }
  }

  useEffect(() => {
    setupRemoteConfig()
  }, [])

  return <MainNavigator />
}

2. Consumo de Valores

const isNewUiEnabled =
  await RemoteConfigService.getValueAsBoolean('enable_new_interface')

Notas Rápidas

Instancia Global: Si usas Expo o React Native estándar y la configuración de Firebase es correcta, @react-native-firebase se inicializa automáticamente.
Seguridad: Siempre envuelve la inicialización en un bloque try/catch.

Otra Opción

Singleton Auto-Inicializable

let remoteConfig = null

const initializeRemoteConfig = async () => {
  if (remoteConfig) return

  const instance = getRemoteConfig()

  await setConfigSettings(instance, {
    minimumFetchIntervalMillis: REMOTE_CONFIG_CACHE_TIME
  })

  remoteConfig = instance
}

const getValueAsString = async (property: string): Promise<string> => {
  await initializeRemoteConfig()

  await fetchAndActivate(remoteConfig)

  return getValue(remoteConfig, property).asString()
}

const getValueAsBoolean = async (property: string): Promise<boolean> => {
  await initializeRemoteConfig()

  await fetchAndActivate(remoteConfig)

  return getValue(remoteConfig, property).asBoolean()
}

¡Hasta luego a todos!

Usando Remote Config Modular no React Native (v23.x.x)

FoodieHoodie — Fri, 23 Jan 2026 12:40:51 +0000

Com o lançamento da versão 23.x.x, o React Native Firebase adotou a API Modular (semelhante ao Firebase Web SDK v9).

O que mudou?

Nas versões anteriores, utilizávamos uma instância baseada em classes, por exemplo, remoteConfig().fetchAndActivate().

Na versão modular, agora passamos a instância de configuração como primeiro argumento para funções independentes, como fetchAndActivate(instance).

Implementação de um Serviço

A implementação abaixo centraliza a lógica do Remote Config em um serviço reutilizável:

import {
  fetchAndActivate,
  getRemoteConfig,
  getValue,
  setConfigSettings
} from '@react-native-firebase/remote-config'

// Tempo de cache (ex.: 5 minutos)
export const REMOTE_CONFIG_CACHE_TIME = 300000

let remoteConfig: any = null

/**
 * Inicializa a instância do Remote Config e define configurações globais.
 */
const initializeRemoteConfig = async () => {
  if (!remoteConfig) {
    remoteConfig = getRemoteConfig()
  }

  await setConfigSettings(remoteConfig, {
    minimumFetchIntervalMillis: REMOTE_CONFIG_CACHE_TIME
  })
}

/**
 * Busca e ativa os valores mais recentes antes de retorná-los como string.
 */
const getValueAsString = async (property: string): Promise<string> => {
  await fetchAndActivate(remoteConfig)

  return getValue(remoteConfig, property).asString()
}

/**
 * Busca e ativa os valores mais recentes antes de retorná-los como boolean.
 */
const getValueAsBoolean = async (property: string): Promise<boolean> => {
  await fetchAndActivate(remoteConfig)
  return getValue(remoteConfig, property).asBoolean()
}

export const RemoteConfigService = {
  getValueAsBoolean,
  getValueAsString,
  initializeRemoteConfig
}

Como usar

1. Inicialização Global

Recomenda-se inicializar o serviço logo no início do ciclo de vida do app, por exemplo, em App.tsx ou em um Redux Store.

import { useEffect } from 'react'
import { RemoteConfigService } from './services/RemoteConfigService'

const App = () => {
  const setupRemoteConfig = async () => {
    try {
      await RemoteConfigService.initializeRemoteConfig()
    } catch (error) {
      console.error('Falha ao inicializar o Remote Config:', error)
    }
  }

  useEffect(() => {
    setupRemoteConfig()
  }, [])

  return <MainNavigator />
}

2. Consumindo Valores

Como os métodos são async, você pode chamá-los sempre que precisar de uma flag específica:

const isNewUiEnabled = await RemoteConfigService.getValueAsBoolean('enable_new_interface')

Observações Rápidas

Instância Global: Se você estiver usando Expo ou React Native "padrão" e já tiver o google-services.json (ou GoogleService-Info.plist) configurado corretamente, o @react-native-firebase/app é inicializado automaticamente.
Segurança: Sempre envolva a inicialização em um bloco try/catch para evitar crashes causados por falhas de rede no primeiro fetch.

Outra Opção

Singleton Auto-Inicializável

let remoteConfig = null

const initializeRemoteConfig = async () => {
  if (remoteConfig) {
    return
  }

  const instance = getRemoteConfig()

  await setConfigSettings(instance, {
    minimumFetchIntervalMillis: REMOTE_CONFIG_CACHE_TIME
  })

  remoteConfig = instance
}

const getValueAsString = async (property: string): Promise<string> => {
  await initializeRemoteConfig()

  await fetchAndActivate(remoteConfig)

  return getValue(remoteConfig, property).asString()
}

const getValueAsBoolean = async (property: string): Promise<boolean> => {
  await initializeRemoteConfig()

  await fetchAndActivate(remoteConfig)

  return getValue(remoteConfig, property).asBoolean()
}

Espero ter ajudado, até mais!

🚀 React 19: ¡Adiós a forwardRef en muchos casos!

FoodieHoodie — Thu, 22 Jan 2026 20:42:55 +0000

¡Veamos cómo usar ref como una prop normal!

Con la llegada de React 19, finalmente podemos despedirnos del molesto forwardRef en muchos casos sencillos. Uno de los cambios más sutiles —pero poderosos— fue la mejora en el comportamiento del ref, que ahora puede pasarse como una prop común a componentes funcionales.

Este cambio ayuda a que nuestro código sea más limpio e intuitivo, especialmente en librerías como React Native, donde usamos ref con frecuencia para acceder a elementos como TextInput, ScrollView, FlatList, etc.

🧠 Antes: `forwardRef` obligatorio

Hasta React 18, si queríamos que un componente personalizado aceptara un ref, estábamos obligados a envolver el componente con `forwardRef`. Mira:

// MiInput.tsx (antes)
import React, { forwardRef } from 'react'
import { TextInput, TextInputProps } from 'react-native'

export const MiInput = forwardRef<TextInput, TextInputProps>((props, ref) => {
  return <TextInput ref={ref} {...props} />
})

En el componente padre, usábamos el ref normalmente:

// Padre.tsx
import React, { useRef } from 'react'
import { View, Button, TextInput } from 'react-native'
import { MiInput } from './MiInput'

export const Padre = () => {
  const inputRef = useRef<TextInput>(null)

  return (
    <View>
      <MiInput ref={inputRef} />
      <Button title="Enfocar" onPress={() => inputRef.current?.focus()} />
    </View>
  )
}

📌 Problema: estabas obligado a usar `forwardRef en MiInput`, aunque fuera un componente simple.

✅ Ahora: `ref` como una prop común

Con React 19, si tu componente pasa el ref directamente a un elemento compatible, ya no necesitas usar `forwardRef`.

Mira cómo queda el mismo ejemplo con React 19:

// MiInput.tsx (React 19)
import React from 'react'
import { TextInput, TextInputProps } from 'react-native'

export const MiInput = (props: TextInputProps & { ref?: React.Ref<TextInput> }) => {
  return <TextInput {...props} />
}

Y en el componente padre, ningún cambio:

// Padre.tsx
import React, { useRef } from 'react'
import { View, Button, TextInput } from 'react-native'
import { MiInput } from './MiInput'

export const Padre = () => {
  const inputRef = useRef<TextInput>(null)

  return (
    <View>
      <MiInput ref={inputRef} />
      <Button title="Enfocar" onPress={() => inputRef.current?.focus()} />
    </View>
  )
}

✅ ¡Sin forwardRef! React ahora entiende que si pasas un ref como prop y este se encamina directamente a un elemento interno (TextInput en este caso), todo funciona automáticamente.

🔥 Y más: `ref` con cleanup (React 19)

Otra mejora sutil: los callbacks de ref ahora pueden devolver una función de cleanup (limpieza), al igual que los efectos (useEffect):

<TextInput
  ref={(node) => {
    console.log('Montado', node)
    return () => {
      console.log('Desmontado', node)
    }
  }}
/>

⚠️ Limitaciones

No todo es color de rosa. Esta simplificación solo funciona si:

El ref se pasa directamente a un elemento nativo o del DOM.
Tu componente no intercepta ni modifica el `ref` internamente.

Si quieres aplicar lógica extra al ref o combinarlo con otro, seguirá siendo necesario usar forwardRef.

📦 Conclusión

React 19 trae pequeños cambios que, en conjunto, hacen que el desarrollo sea más fluido y elegante. Con esta mejora en el uso de ref, logramos:

Eliminar forwardRef de muchos componentes.
Reducir el boilerplate.
Tener un código más simple y directo.

🧩 Cuándo sigue siendo necesario usar `forwardRef`

Incluso con las mejoras de React 19, el forwardRef sigue siendo necesario en algunos escenarios más avanzados. Mira un ejemplo real:

❌ Ejemplo que no funciona sin `forwardRef`

import React from 'react'
import { View, Text, ViewProps } from 'react-native'

export const MiCaja = (props: ViewProps & { ref?: React.Ref<View> }) => {
  const { style, children, ...rest } = props

  return (
    <View ref={props.ref} style={[{ padding: 12 }, style]} {...rest}>
      <Text>{children}</Text>
    </View>
  )
}

En este caso, React no garantiza que el ref se pase correctamente, ya que el componente no es "transparente".

✅ Correcto: usando `forwardRef`

import React, { forwardRef } from 'react'
import { View, Text, ViewProps } from 'react-native'

export const MiCaja = forwardRef<View, ViewProps>(({ style, children, ...rest }, ref) => {
  return (
    <View ref={ref} style={[{ padding: 12 }, style]} {...rest}>
      <Text>{children}</Text>
    </View>
  )
})

⚠️ Otros casos que aún requieren `forwardRef`

Situación	¿`forwardRef` necesario?
El Ref se aplica directamente a un elemento DOM/Nativo	❌ No
El Ref es interceptado o modificado internamente	✅ Sí
El Ref necesita ser almacenado o combinado con otro (`mergeRefs`)	✅ Sí
El componente necesita exponer imperativamente una API vía `ref`	✅ Sí

A pesar de las mejoras, forwardRef sigue siendo una herramienta esencial en componentes más complejos. Usa el nuevo comportamiento siempre que sea posible, pero identifica cuándo sigue siendo necesario el patrón tradicional.

🚀 React 19: Adeus forwardRef em muitos casos!

FoodieHoodie — Thu, 22 Jan 2026 20:40:24 +0000

Vejamos como usar ref como prop normalmente!

Com a chegada do React 19, finalmente podemos nos despedir do incômodo forwardRef em muitos casos simples. Uma das mudanças mais sutis — porém poderosas — foi a melhoria no comportamento do ref, que agora pode ser passado como uma prop comum para componentes funcionais.

Essa mudança ajuda a deixar nosso código mais limpo e intuitivo, especialmente em bibliotecas como React Native, onde usamos ref com frequência para acessar elementos como TextInput, ScrollView, FlatList, etc.

🧠 Antes: `forwardRef` obrigatório

Até o React 18, se quiséssemos que um componente personalizado aceitasse ref, éramos obrigados a envolver o componente com forwardRef. Veja:

// MeuInput.tsx (antes)
import React, { forwardRef } from 'react'
import { TextInput, TextInputProps } from 'react-native'

export const MeuInput = forwardRef<TextInput, TextInputProps>((props, ref) => {
  return <TextInput ref={ref} {...props} />
})

No componente pai, usamos o ref normalmente:

// Pai.tsx
import React, { useRef } from 'react'
import { View, Button, TextInput } from 'react-native'
import { MeuInput } from './MeuInput'

export const Pai = () => {
  const inputRef = useRef<TextInput>(null)

  return (
    <View>
      <MeuInput ref={inputRef} />
      <Button title="Focar" onPress={() => inputRef.current?.focus()} />
    </View>
  )
}

📌 Problema: você era obrigado a usar forwardRef em MeuInput, mesmo que ele fosse simples.

✅ Agora: `ref` como uma prop comum

Com o React 19, se o seu componente passar o ref diretamente para um elemento compatível, você não precisa mais usar forwardRef.

Veja como fica o mesmo exemplo com React 19:

// MeuInput.tsx (React 19)
import React from 'react'
import { TextInput, TextInputProps } from 'react-native'

export const MeuInput = (props: TextInputProps & { ref?: React.Ref<TextInput> }) => {
  return <TextInput {...props} />
}

E no componente pai, nenhuma mudança:

// Pai.tsx
import React, { useRef } from 'react'
import { View, Button, TextInput } from 'react-native'
import { MeuInput } from './MeuInput'

export const Pai = () => {
  const inputRef = useRef<TextInput>(null)

  return (
    <View>
      <MeuInput ref={inputRef} />
      <Button title="Focar" onPress={() => inputRef.current?.focus()} />
    </View>
  )
}

✅ Sem forwardRef!

O React agora entende que se você passar um ref como prop e ele for encaminhado diretamente para um elemento interno (TextInput nesse caso), tudo funciona automaticamente.

🔥 E mais: `ref` com cleanup (React 19)

Outra melhoria sutil: callbacks de ref agora podem retornar uma função de cleanup, como os efeitos (useEffect):

<TextInput
  ref={(node) => {
    console.log('Montado', node)
    return () => {
      console.log('Desmontado', node)
    }
  }}
/>

⚠️ Limitações

Nem tudo são flores. Essa simplificação só funciona se:

O ref for passado diretamente para um elemento nativo ou DOM.
O seu componente não interceptar ou modificar o ref internamente.

Se você quiser aplicar lógica extra ao ref ou combiná-lo com outro, ainda será necessário usar forwardRef.

📦 Conclusão

O React 19 traz pequenas mudanças que, somadas, deixam o desenvolvimento mais fluido e elegante. Com essa melhoria no uso de ref, conseguimos:

Eliminar forwardRef de muitos componentes.
Reduzir boilerplate.
Ter código mais simples e direto.

🧩 Quando ainda é necessário usar `forwardRef`

Mesmo com as melhorias do React 19, o forwardRef ainda é necessário em alguns cenários mais avançados. Veja um exemplo real:

❌ Exemplo que não funciona sem `forwardRef`

import React from 'react'
import { View, Text, ViewProps } from 'react-native'

export const MeuBox = (props: ViewProps & { ref?: React.Ref<View> }) => {
  const { style, children, ...rest } = props

  return (
    <View ref={props.ref} style={[{ padding: 12 }, style]} {...rest}>
      <Text>{children}</Text>
    </View>
  )
}

Nesse caso, o React não garante que o ref será passado corretamente, pois o componente não é “transparente”.

✅ Correto: usando `forwardRef`

import React, { forwardRef } from 'react'
import { View, Text, ViewProps } from 'react-native'

export const MeuBox = forwardRef<View, ViewProps>(({ style, children, ...rest }, ref) => {
  return (
    <View ref={ref} style={[{ padding: 12 }, style]} {...rest}>
      <Text>{children}</Text>
    </View>
  )
})

⚠️ Outros casos que ainda exigem `forwardRef`

Situação	`forwardRef` necessário?
Ref é aplicado diretamente a um elemento DOM/Nativo	❌ Não
Ref é interceptado ou modificado internamente	✅ Sim
Ref precisa ser armazenado ou combinado com outro (`mergeRefs`)	✅ Sim
Componente precisa expor imperativamente uma API via `ref`	✅ Sim

Mesmo com as melhorias, o forwardRef ainda é uma ferramenta essencial em componentes mais complexos. Use o novo comportamento quando possível, mas saiba quando ainda é necessário usar o padrão tradicional.

Por qué JavaScript no es un desorden?

FoodieHoodie — Mon, 20 Jan 2025 19:38:43 +0000

Siempre me pongo triste

Me irrita mucho cuando escucho a personas decir que el Frontend es un desorden, especialmente cuando afirman que JavaScript "acepta cualquier cosa" y que se puede escribir de cualquier manera, ya que podemos alcanzar el mismo resultado de diversas formas.

En realidad, no están equivocados. Sí, es posible escribir JavaScript de diferentes maneras y aún así alcanzar el mismo objetivo.

El principal problema es que, al hablar de Frontend y JavaScript, no contamos con patrones de diseño tan definidos como los que se encuentran en el Backend, donde existen frameworks y convenciones ampliamente adoptados. En el caso del Frontend, la información sobre buenas prácticas y patrones está dispersa por la web, lo que resulta en una diversidad de opiniones y visiones. Esta falta de uniformidad dificulta el desarrollo y la comprensión, especialmente para quienes están comenzando. ~~Incluso el autor que habla de esto tiene sus propias opiniones.~~

El punto que quiero abordar

Al concluir este desahogo, quiero destacar que el hecho de que algo no sea evidente no significa que no exista o que no debas buscar conocimiento para aplicar al menos lo básico de patrones en tu código. En el caso de JavaScript, por ejemplo, existen numerosos sitios que presentan diversas implementaciones y patrones ya establecidos en el lenguaje, listos para ser utilizados en el desarrollo. Solo es necesario dedicar tiempo a leer, y entenderás la finalidad de cada recurso y el momento adecuado para utilizarlo. Ejemplo: Mozilla Docs JS

Veamos un ejemplo de código real

El código a continuación fue extraído de un proyecto real que estaba en producción. Aunque, teóricamente, "no hay nada de malo en él" y funciona normalmente, en la práctica, la implementación podría haberse realizado de una manera diferente, lo que resultaría en mejoras en la legibilidad y el rendimiento.

Vamos a ajustar algunas partes del código para alinearlo mejor con las recomendaciones de la documentación de JavaScript. Esto se debe a que el lenguaje ofrece métodos/funciones específicos para manejar ciertas situaciones de forma más eficiente.

Quiero recordar que aquí abordaremos un concepto básico de JavaScript: trabajar con Arrays y Objetos. El código ha sido diseñado de manera didáctica, evitando complejidades innecesarias.

Entonces, vamos allá. Primero, definiremos un objeto que, teóricamente, sería recibido desde nuestro Backend a través de una API:

const storesList = [{
  activeStories: [
    {
      name: 'Starbucks',
      code: 1
    },
    {
      name: 'Duck Duck Coffe',
      code: 2
    }
  ],
  inactiveStories: [
    {
      name: 'Mac Coffe',
      code: 3
    }
  ]
}]

Ahora, por alguna razón inusual y poco convencional, pero solo con fines de ejemplo, necesitamos agregar un nuevo campo llamado "label" a este objeto. El campo "label" debe consistir en el prefijo Opened seguido del nombre de la tienda.

Primero, vamos a analizar una implementación que considero "menos ideal", ya que no utiliza las mejores herramientas, métodos o funciones de JavaScript para agregar el campo "label".

storesList.reduce((previous, current) => {
  current.activeStories.forEach(store => {
    previous.push({
      ...store,
      label: `Opened ${store.name}`
    })
  })

  return previous
}, [])

// resultado:
[
    {
        "name": "Starbucks",
        "code": 1,
        "label": "Opened Starbucks"
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2,
        "label": "Opened Duck Duck Coffe"
    }
]

Aquí podemos ver que, primero, tenemos un .reduce, luego un .forEach y finalmente un .push. Todo esto se utiliza solo para devolver una nueva lista reconstruida para mostrar en pantalla. Lo que más me molesta aquí es la aparente falta de conocimiento o el no uso de funciones como .flatMap y .map, que son herramientas básicas y fundamentales al trabajar con JavaScript. Además, la sintaxis del código termina siendo confusa y excesivamente verbosa.

Veamos ahora cómo podría haberse hecho:

storesList.flatMap((item) => {
  return item.activeStories
}).map((item) => {
  return {
    ...item,
    label: `Opened ${item.name}`
  }
})

¿Qué opinas? ¿Más simple, no?

¿Por qué esto? ¿Por qué así?

Vamos allá. Conceptualmente, el .flatMap "aplasta" nuestro array de objetos en un solo nivel. El resultado sería algo así:

[
    {
        "name": "Starbucks",
        "code": 1
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2
    }
]

Ahora, utilizamos el .map, que se utiliza para "remapear" un array, es decir, recorremos cada elemento, agregando la propiedad "label". El resultado se vería así:

[
    {
        "name": "Starbucks",
        "code": 1,
        "label": "Opened Starbucks"
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2,
        "label": "Opened Duck Duck Coffe"
    }
]

Conclusión

¡Esto es realmente genial! JavaScript ofrece todas las herramientas necesarias para escribir código de calidad.

Todo lo que necesitas hacer es estudiarlo y aplicar los conceptos correctamente, no solo codificar por codificar.

Sugerencia de libro:

[PT-BR] - https://github.com/cezaraugusto/You-Dont-Know-JS
[EN] - https://github.com/getify/You-Dont-Know-JS

Why is JavaScript not a mess?

FoodieHoodie — Mon, 20 Jan 2025 19:36:14 +0000

I Always Get Frustrated

I get really frustrated when I hear people saying that Frontend is a mess, especially when they claim that JavaScript "accepts anything" and that you can write it any way you want since we can achieve the same result in multiple ways.

In reality, they're not wrong. Yes, it is possible to write JavaScript in various ways and still reach the same goal.

The main issue is that, when we talk about Frontend and JavaScript, we don't have well-defined design patterns like we do in Backend, where there are widely adopted frameworks and conventions. In Frontend, information about best practices and patterns is scattered across the web, leading to a variety of views and opinions. This lack of uniformity makes development and understanding more difficult, especially for beginners. ~~Even the author of this text has his own opinions.~~

The Point I Want to Address

To conclude this rant, I want to highlight that just because something isn't obvious doesn't mean it doesn't exist, or that you shouldn't seek knowledge to apply at least the basic patterns in your code. In the case of JavaScript, for example, there are numerous websites that present established implementations and patterns in the language, ready to be used during development. You just need to dedicate time to reading, and you'll understand the purpose of each resource and the right time to use it. Example: Mozilla Docs JS.

Let's Look at a Real Code Example

The following code was taken from a real project that was running in production. While, theoretically, "there's nothing wrong with it" and it works fine, in practice, the approach used could have been different, resulting in improved readability and performance.

Let's simply adjust some parts of the code to make it more aligned with the JavaScript documentation recommendations. This is possible because the language provides specific methods/functions to handle certain situations more efficiently.

I would like to remind you that here we will address a very basic JavaScript concept: working with Arrays and Objects. The code was written in the simplest form possible, avoiding unnecessary complexities.

So, let's get started! First, we'll define an object that would theoretically be received from our Backend via API:

const storesList = [{
  activeStories: [
    {
      name: 'Starbucks',
      code: 1
    },
    {
      name: 'Duck Duck Coffe',
      code: 2
    }
  ],
  inactiveStories: [
    {
      name: 'Mac Coffe',
      code: 3
    }
  ]
}]

Now, for some unusual and unconventional reason, but just for example's sake, we need to add a new field called "label" to this object. The "label" field should be composed of the prefix Opened followed by the store's name.

First, let's look at an implementation that I consider "less ideal," as it doesn't use the best tools, methods, or functions in JavaScript to perform the addition of the "label" field.

storesList.reduce((previous, current) => {
  current.activeStories.forEach(store => {
    previous.push({
      ...store,
      label: `Opened ${store.name}`
    })
  })

  return previous
}, [])

// result:
[
    {
        "name": "Starbucks",
        "code": 1,
        "label": "Opened Starbucks"
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2,
        "label": "Opened Duck Duck Coffe"
    }
]

Here, we can observe that, first, we have a .reduce, followed by a .forEach, and finally, a .push. All of this is used just to return a newly reconstructed list for display on the screen. What bothers me the most here is the apparent lack of knowledge or the non-use of functions like .flatMap and .map, which are basic and important resources when working with JavaScript. Moreover, the code's syntax becomes confusing and overly verbose.

Now, let's see how it could have been done:

storesList.flatMap((item) => {
  return item.activeStories
}).map((item) => {
  return {
    ...item,
    label: `Opened ${item.name}`
  }
})

So, what do you think? Simpler, right?
Why is that? Why like this?

Let's go! Conceptually, .flatMap "flattens" our array of objects into a single level. The result will look like this:

[
    {
        "name": "Starbucks",
        "code": 1
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2
    }
]

Now, we use .map, which serves to "remap" an array, meaning we go through each item, adding the "label" property. The result looks like this:

[
    {
        "name": "Starbucks",
        "code": 1,
        "label": "Opened Starbucks"
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2,
        "label": "Opened Duck Duck Coffe"
    }
]

Conclusion

This is truly amazing! JavaScript provides all the tools you need to write high-quality code.

All you need to do is study it and apply the concepts correctly, not just code for the sake of coding.

Book Recommendations:

[PT-BR] - https://github.com/cezaraugusto/You-Dont-Know-JS
[EN] - https://github.com/getify/You-Dont-Know-JS

Por que JavaScript não é bagunça?

FoodieHoodie — Mon, 20 Jan 2025 19:34:48 +0000

Eu Sempre fico pistola

Fico muito irritado quando ouço pessoas dizendo que o Frontend é uma bagunça, especialmente quando afirmam que o JavaScript "aceita qualquer coisa" e que dá para escrever de qualquer jeito, já que podemos alcançar o mesmo resultado de várias maneiras.

Na verdade, elas não estão erradas. Sim, é possível escrever JavaScript de diversas formas e, ainda assim, chegar ao mesmo objetivo.

A principal questão é que, ao falarmos de Frontend e JavaScript, não contamos com padrões de projeto tão bem definidos como os encontrados no Backend, onde há frameworks e convenções amplamente adotados. No caso do Frontend, as informações sobre boas práticas e padrões estão dispersas pela web, resultando em uma diversidade de visões e opiniões. Essa falta de uniformidade dificulta o desenvolvimento e entendimento, principalmente para quem está começando. ~~Inclusive o autor que lhos fala tem as opiniões dele.~~

O ponto que quero abordar

Ao concluir este desabafo, quero destacar que o fato de algo não ser evidente não significa que ele não exista ou que você não deva buscar conhecimento para aplicar pelo menos o básico de padrões em seu código. No caso do JavaScript, por exemplo, há inúmeros sites que apresentam diversas implementações e padrões já estabelecidos na linguagem, prontos para serem utilizados no desenvolvimento. Basta se dedicar à leitura, e você entenderá a finalidade de cada recurso e o momento adequado para utilizá-lo. Exemplo: Mozilla Docs JS

Vejamos um exemplo de código real

O código abaixo foi extraído de um projeto real que estava sendo executado em produção. Embora, teoricamente, "não haja nada de errado com ele" e ele funcione normalmente, na prática, a abordagem utilizada poderia ser diferente, resultando em melhorias na legibilidade e no desempenho.

Vamos simplesmente ajustar algumas partes do código para torná-lo mais alinhado com as recomendações da documentação do JavaScript. Isso porque a linguagem oferece métodos/funções específicos para lidar com certas situações de forma mais eficiente.

Gostaria de lembrar que aqui abordaremos um conceito bastante básico do JavaScript: trabalhar com Arrays e Objetos. O código foi elaborado de forma didática, evitando complexidades desnecessárias.

Então, vamos lá! Primeiro, definiremos um objeto que, teoricamente, seria recebido do nosso Backend via API:

const storesList = [{
  activeStories: [
    {
      name: 'Starbucks',
      code: 1
    },
    {
      name: 'Duck Duck Coffe',
      code: 2
    }
  ],
  inactiveStories: [
    {
      name: 'Mac Coffe',
      code: 3
    }
  ]
}]

Agora, por algum motivo inusitado e pouco convencional, mas apenas para fins de exemplo, precisamos adicionar um novo campo chamado "label" a este objeto. O campo "label" deve ser composto pelo prefixo Opened seguido pelo nome da loja.

Primeiramente, vamos analisar uma implementação que considero "menos ideal", pois não utiliza as melhores ferramentas, métodos ou funções do JavaScript para realizar essa adição do campo "label".

storesList.reduce((previous, current) => {
  current.activeStories.forEach(store => {
    previous.push({
      ...store,
      label: `Opened ${store.name}`
    })
  })

  return previous
}, [])

// resultado:
[
    {
        "name": "Starbucks",
        "code": 1,
        "label": "Opened Starbucks"
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2,
        "label": "Opened Duck Duck Coffe"
    }
]

Aqui podemos observar que, primeiramente, temos um .reduce, seguido de um .forEach e, por fim, um .push. Tudo isso é utilizado apenas para retornar uma nova lista reconstruída para exibição na tela. O que mais me incomoda aqui é a aparente falta de conhecimento ou o não uso de funções como .flatMap e .map, que são recursos básicos e importantes ao trabalhar com JavaScript. Além disso, a sintaxe do código acaba ficando confusa e excessivamente verbosa.

Vejamos agora como poderia ter sido feito:

storesList.flatMap((item) => {
  return item.activeStories
}).map((item) => {
  return {
    ...item,
    label: `Opened ${item.name}`
  }
})

Então, o que achou? Mais simples não?
Por que isso? Por que assim?

Vamos lá! Conceitualmente, o .flatMap, "achata" nosso array de objetos em um único nível. O resultado será algo assim:

[
    {
        "name": "Starbucks",
        "code": 1
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2
    }
]

Agora, utilizamos o .map, que serve para "remapear" um array, ou seja, percorremos item por item, adicionando a propriedade "label". O resultado fica assim:

[
    {
        "name": "Starbucks",
        "code": 1,
        "label": "Opened Starbucks"
    },
    {
        "name": "Duck Duck Coffe",
        "code": 2,
        "label": "Opened Duck Duck Coffe"
    }
]

Conclusão

Isso é realmente incrível! O JavaScript oferece todas as ferramentas necessárias para escrever um código de qualidade.

Tudo o que você precisa fazer é estudá-lo e aplicar os conceitos corretamente, e não apenas codificar por codificar.

Dica de Livro:

[PT-BR] - https://github.com/cezaraugusto/You-Dont-Know-JS
[EN] - https://github.com/getify/You-Dont-Know-JS

Cómo Comenzar en la Carrera de Programador: Una Guía Práctica para Principiantes [Web y Móvil]

FoodieHoodie — Mon, 20 Jan 2025 13:25:13 +0000

Lo esencial aquí es que comprendas que:

Este texto está formado por opiniones basadas en mi trayectoria y visión del mercado. Es decir, las ideas expresadas aquí provienen de lo más profundo de mi ~~trasero~~ – o, para ser más preciso, de mi cabeza. Dicho esto, el enfoque aquí es FRONTEND, es decir, WEB y MÓVIL HÍBRIDO. Pero si eres del BACKEND, vale la pena leer también, ya que todo el contenido es relevante y siempre tenemos algo que aprender.

Vamos allá:

Si estás comenzando en la programación, es fácil perderse con la cantidad de tecnologías, lenguajes y frameworks disponibles. Pero la verdad es simple: enfoque y consistencia son las claves para construir una carrera sólida. En este artículo, compartiré una hoja de ruta práctica que puede ayudarte a comenzar tu viaje en la programación de forma eficiente y dirigida.

Define el Enfoque: ¿Web o Móvil?

El primer paso para iniciar tu carrera es decidir qué camino seguir. Si tienes dudas, comenzar con programación web es una excelente elección.

¿Por qué Web primero?
- Aprendes los fundamentos esenciales: HTML, CSS y JavaScript.
- El mercado de trabajo para desarrolladores web es más accesible.
- Es más fácil encontrar trabajos como freelancer, en agencias u otras empresas.
- Esta base facilitará la transición a otras áreas, como el desarrollo móvil.

Si tu objetivo final es ser desarrollador móvil, comienza construyendo esta base sólida. Así, cuando migres a frameworks como React Native, la curva de aprendizaje será mucho menor.

¿Qué Aprender Primero?

1. Lógica de Programación

La lógica de programación es la base de cualquier lenguaje.

¿Por qué es importante?
- Todos los lenguajes utilizan los mismos conceptos de operadores, condiciones y estructuras de repetición.
- Con una buena lógica, aprender nuevos lenguajes será mucho más fácil.
- Estarás preparado tanto para los desafíos profesionales como personales.

2. HTML, CSS y JavaScript

Estas tres tecnologías son la base del desarrollo web. (En "palabras" breves)

HTML: Lenguaje de marcado, usado para estructurar páginas web.
CSS: Lenguaje de estilo, usado para dar estilo a las páginas web.
JavaScript: Lenguaje de programación para interactividad en las páginas web.

Dedica tiempo a comprender profundamente estos conceptos antes de avanzar a frameworks más complejos.

Cuando hablo de entender, me refiero a dominar realmente el contenido, no solo copiar y pegar. Conoce el significado de cada elemento y por qué funciona de esa manera. Esta comprensión hará toda la diferencia en tu carrera.

3. Programación Web con React

Después de dominar HTML, CSS y JavaScript, el siguiente paso es aprender React, uno de los frameworks más usados para desarrollar interfaces web.

Con React, podrás crear aplicaciones robustas y modernas. ~~(texto listo, pero cierto)~~
También será útil cuando migres al desarrollo móvil, ya que React Native usa la misma base de conocimientos.

De Web a Móvil: El Camino hacia React Native

Después de adquirir experiencia práctica con desarrollo web, puedes migrar al desarrollo móvil. Aquí, React Native es una excelente opción.

¿Por qué React Native?
- Permite crear aplicaciones nativas utilizando JavaScript.
- Es más accesible para quienes ya conocen React y JavaScript.
- Tiene una amplia aceptación en el mercado, siendo usado por grandes empresas como Facebook e Instagram.

Consejos Prácticos para Principiantes

Elige un material de estudio y sigue hasta el final.
- Evita saltar de curso en curso o tratar de aprender todo a la vez.
Equivócate sin miedo.
- Al principio, lo más importante es hacer que funcione. Refinar y optimizar vendrán con el tiempo.
No te compares con otros desarrolladores.
- Cada persona tiene su propio ritmo y forma de aprender. Enfócate en tu progreso.
Sé resiliente.
- El mercado tecnológico exige aprendizaje continuo. Acepta que nunca sabrás todo y enfócate en mantenerte actualizado con las demandas del mercado.

Mensaje Final

La programación no es fácil, pero tampoco es imposible. Lo más importante es entender que el aprendizaje es un proceso continuo. No trates de dominar todo de una vez o seguir las tendencias solo porque están "de moda". Elige un camino, mantén el enfoque y avanza de manera consistente.

Recuerda: “La vida es como una rapadura – dulce, pero no es fácil.” Enfrenta los desafíos con paciencia, resiliencia y voluntad de aprender. El mercado tecnológico es desafiante, pero también está lleno de oportunidades para aquellos dispuestos a dedicarse.

¡Buena suerte en tu viaje como programador!

How to Start a Career as a Programmer: A Practical Guide for Beginners [Web and Mobile]

FoodieHoodie — Mon, 20 Jan 2025 13:18:49 +0000

The essentials here are that you understand that:

This text is made up of opinions based on my journey and market perspective. In other words, the ideas expressed here came from the depths of my ~~butt~~ – or, to be more precise, from my head. That said, the focus here is FRONTEND, meaning WEB and HYBRID MOBILE. But if you’re from the BACKEND, it’s worth reading as well, because all the content is relevant, and we always have something to learn.

Let's go:

If you’re just starting with programming, it’s easy to get lost with the number of technologies, languages, and frameworks available. But the truth is simple: focus and consistency are the keys to building a solid career. In this article, I’ll share a practical roadmap that can help you start your programming journey efficiently and with direction.

Define the Focus: Web or Mobile?

The first step in starting your career is deciding which path to take. If you're in doubt, starting with web programming is an excellent choice.

Why Web first?
- You’ll learn the essential fundamentals: HTML, CSS, and JavaScript.
- The job market for web developers is more accessible.
- It’s easier to find freelance jobs, work in agencies, or other companies.
- This foundation will make the transition to other areas, like mobile development, easier.

If your ultimate goal is to become a mobile developer, start by building that solid foundation. This way, when you move to frameworks like React Native, the learning curve will be much smaller.

What to Learn First?

1. Programming Logic

Programming logic is the foundation of any language.

Why is it important?
- All languages use the same concepts of operators, conditions, and loops.
- With solid logic, learning new languages will be much easier.
- You’ll be prepared for both professional and personal challenges.

2. HTML, CSS, and JavaScript

These three technologies are the core of web development. (In short words)

HTML: Markup language, used to structure web pages.
CSS: Styling language, used to style web pages.
JavaScript: Programming language for interactivity on web pages.

Dedicate yourself to deeply understanding these concepts before moving on to more complex frameworks.

When I say understand, I mean truly mastering the content, not just copy-pasting. Know the meaning of each element and why it works that way. This understanding will make all the difference in your career.

3. Web Programming with React

After mastering HTML, CSS, and JavaScript, the next step is learning React, one of the most widely used frameworks for building web interfaces.

With React, you’ll be able to create robust and modern applications. ~~(true, but ready text)~~
It will also be useful when you move to mobile development, since React Native uses the same knowledge base.

From Web to Mobile: The Path to React Native

After gaining practical experience with web development, you can transition to mobile development. Here, React Native is a great choice.

Why React Native?
- It allows you to create native apps using JavaScript.
- It’s more accessible for those already familiar with React and JavaScript.
- It has wide market acceptance and is used by major companies like Facebook and Instagram.

Practical Tips for Beginners

Choose a study material and stick to it until the end.
- Avoid jumping from course to course or trying to learn everything at once.
Don’t be afraid to make mistakes.
- In the beginning, the most important thing is to make it work. Refining and optimizing will come with time.
Don’t compare yourself to other developers.
- Everyone has their own pace and way of learning. Focus on your progress.
Be resilient.
- The tech industry requires continuous learning. Accept that you’ll never know everything and focus on staying updated with market demands.

Final Message

Programming is not easy, but it’s not impossible either. The most important thing is to understand that learning is a continuous process. Don’t try to master everything at once or follow trends just because they’re “popular.” Choose a path, stay focused, and make consistent progress.

Remember: “Life is like sugarcane – sweet, but not soft.” Face challenges with patience, resilience, and a willingness to learn. The tech market is challenging, but it’s also full of opportunities for those who are willing to dedicate themselves.

Good luck on your journey as a programmer!

DEV Community: FoodieHoodie

- Apenas estou cansado; - Solo estoy cansado; - I'm just tired.

Feudos Digitales

La gravedad del escenario

El riesgo de ser rehenes digitales

La trampa de la conveniencia

El poder del "interruptor"

La vigilancia como gobernanza

Conclusión

Feudos Digitais

A Gravidade do Cenário

O Risco de sermos Reféns Digitais

A Armadilha da Conveniência

O Poder do "Interruptor"

A Vigilância como Governança

Conclusão

Implementación de Remote Config Modular (v23.x.x)

¿Qué cambió?

Implementación del Servicio

Cómo usarlo

1. Inicialización Global

2. Consumo de Valores

Notas Rápidas

Otra Opción

Usando Remote Config Modular no React Native (v23.x.x)

O que mudou?

Implementação de um Serviço

Como usar

1. Inicialização Global

2. Consumindo Valores

Observações Rápidas

Outra Opção

🚀 React 19: ¡Adiós a forwardRef en muchos casos!

🧠 Antes: forwardRef obligatorio

✅ Ahora: ref como una prop común

🔥 Y más: ref con cleanup (React 19)

⚠️ Limitaciones

📦 Conclusión

🧩 Cuándo sigue siendo necesario usar forwardRef

❌ Ejemplo que no funciona sin forwardRef

✅ Correcto: usando forwardRef

⚠️ Otros casos que aún requieren forwardRef

🚀 React 19: Adeus forwardRef em muitos casos!

🧠 Antes: forwardRef obrigatório

✅ Agora: ref como uma prop comum

🔥 E mais: ref com cleanup (React 19)

⚠️ Limitações

📦 Conclusão

🧩 Quando ainda é necessário usar forwardRef

❌ Exemplo que não funciona sem forwardRef

✅ Correto: usando forwardRef

⚠️ Outros casos que ainda exigem forwardRef

Por qué JavaScript no es un desorden?

Siempre me pongo triste

El punto que quiero abordar

Veamos un ejemplo de código real

Conclusión

Why is JavaScript not a mess?

I Always Get Frustrated

The Point I Want to Address

Let's Look at a Real Code Example

Conclusion

Book Recommendations:

Por que JavaScript não é bagunça?

Eu Sempre fico pistola

O ponto que quero abordar

Vejamos um exemplo de código real

Conclusão

Cómo Comenzar en la Carrera de Programador: Una Guía Práctica para Principiantes [Web y Móvil]

Lo esencial aquí es que comprendas que:

Vamos allá:

Define el Enfoque: ¿Web o Móvil?

¿Qué Aprender Primero?

1. Lógica de Programación

2. HTML, CSS y JavaScript

3. Programación Web con React

De Web a Móvil: El Camino hacia React Native

Consejos Prácticos para Principiantes

Mensaje Final

How to Start a Career as a Programmer: A Practical Guide for Beginners [Web and Mobile]

🧠 Antes: `forwardRef` obligatorio

✅ Ahora: `ref` como una prop común

🔥 Y más: `ref` con cleanup (React 19)

🧩 Cuándo sigue siendo necesario usar `forwardRef`

❌ Ejemplo que no funciona sin `forwardRef`

✅ Correcto: usando `forwardRef`

⚠️ Otros casos que aún requieren `forwardRef`

🧠 Antes: `forwardRef` obrigatório

✅ Agora: `ref` como uma prop comum

🔥 E mais: `ref` com cleanup (React 19)

🧩 Quando ainda é necessário usar `forwardRef`

❌ Exemplo que não funciona sem `forwardRef`

✅ Correto: usando `forwardRef`

⚠️ Outros casos que ainda exigem `forwardRef`