react-puro-19
  • React Puro - 19
  • code
    • README
    • README
    • README
    • README
    • README
    • README
    • README
    • README
  • 7-state-en-clases
    • Ejemplo inicial: un contador
    • Manejo de eventos
    • El state
    • Sintaxis limpia en Class Components
    • setState es Asincrónico
    • Fusión superficial vs profunda
  • 5-children
    • Personalizar Children antes de renderizar
    • PropTypes para Children
    • Los Children
    • Diferentes tipos de Children
    • Manejando uso Children
  • 13-hook-usereducer
    • Qué es un Reducer?
    • Un ejemplo más practico
    • Entonces, Redux murió?
  • 4-proptypes
    • Documentación y depuración incluida
    • PropTypes como documentación
    • Cómo validar, formas comunes
    • Ejemplo Tweet con PropTypes
  • 3-props
    • Comunicación con componentes Padre
    • Las Props:
    • Pasar Props
    • Recibir Props
    • Ejemplo Tweet con Props
  • 11-pensando-uso-state
    • "Tipos" de componentes
    • Qué colocar en el State
    • Dónde mantener el estado
    • Pensando declarativamente
  • 9-requests-api
    • Intro
    • Eligir libreria HTTP
    • Obtener datos y mostrarlos
  • 10-state-en-funciones
    • El useState Hook
    • Actualizar State basado en State anterior
    • State como un Array
    • Reglas de los Hooks
    • La "magia" de los Hooks
    • State como un Objeto
    • Intro Hooks
  • 15-api-context
    • Usando React API Context
    • Patrón "Slots"
    • Patrón "Render Props"
    • Intro API Context
    • Otros Patrones de Context
    • Ejemplo perforación de props
    • hook_usecontext
  • 8-ciclo-vida-componente
    • Fases
    • El ciclo
    • Manejo de errores
    • Desmontaje
    • Representación
    • Montaje
  • 14-hook-useeffect
    • Límite cuando se ejecuta un Effect
    • Hacer cambios visibles del DOM
    • Obtener datos (Fetch) con useEffect
    • Intro useEffect
    • Re-obtener datos (Re-Fetch) cuando cambian
    • Solo ejecución en montaje y desmontaje
  • 2-jsx
    • Ejemplo componente Tweet:
    • JSX:
    • Trabajando con JSX:
  • 12-controles-entrada
    • Entradas controladas
    • Entradas no controladas
  • 6-github-file-list
    • Parte 2: la Prop 'key'
    • Parte inicial
  • 1-hola_mundo
    • Hola mundo:
Con tecnología de GitBook
En esta página

¿Te fue útil?

  1. 11-pensando-uso-state

Dónde mantener el estado

AnteriorQué colocar en el StateSiguientePensando declarativamente

Última actualización hace 5 años

¿Te fue útil?

Siempre que se pueda, lo mejor es mantener los componentes sin estado. Los componentes sin estado son más fáciles de escribir y más fáciles de razonar. A veces esto no es posible, pero a menudo, los datos que inicialmente se piensan que deberían ir en el estado interno se pueden elevar al componente principal, o incluso más.

Imaginar una sección de página que se puede mostrar u ocultar, como una barra lateral:

Cuando se hace clic en el botón "Ocultar", la barra lateral debería desaparecer, lo que significa que algo debe establecer un indicador showSidebar en falso. Este indicador debe almacenarse en el estado en algún lugar. ¿Pero donde?

Opción 1, el indicador showSidebar podría residir en el componente Sidebar. De esta manera, la barra lateral "sabe" si está abierta o no. Esto es similar a cómo funcionan las entradas no controladas.

Opción 2, el indicador showSidebar puede residir en el elemento padre de Sidebar, que es el componente Layout. Entonces el padre puede decidir si renderiza la barra lateral o no:

class Layout extends React.Component {
    state = {
        showSidebar: false
    }

    toggleSidebar = () => {
        this .setState({
            showSidebar: !this.state.showSidebar
        });
    } 

    render() {
        const { showSidebar } = this.state;
        return (
        <div className="layout" >
            {showSidebar &&
            <Sidebar
            onHide={this.toggleSidebar} >
            algún contenido de la barra lateral
            </Sidebar> }
            <Content
            isSidebarVisible={showSidebar}
            onShowSidebar={ this.toggleSidebar} >
            algún contenido aquí
            </Content>
        </div>
        );
    }
}

const Content = ({
    children,
    isSidebarVisible,
    onShowSidebar
    }) => (
        <div className="content" >
        {children}
        {!isSidebarVisible && (
            <button onClick={onShowSidebar} > Show </button>
        )}
        </div>
);

const Sidebar = ({
    onHide,
    children
    }) => (
        <div className="sidebar" >
        {children}
        <button onClick={onHide} > Hide </button>
        </div>
);

De esta manera, Sidebar no "sabe" internamente si es visible. Se represente o no se represente.

Mantener el estado en un componente padre puede parecer antinatural. A primera vista, incluso podría parecer que esto haría que Sidebar sea difícil de reutilizar, ya que debe pasarse una función de devolución de llamada a la que Sidebar pueda llamar cuando necesite ocultarse.

Por el contrario, tener menos componentes que contengan estado significa menos lugares para buscar cuando aparece un error. Y si se necesita hacer algo con ese estado, como guardarlo en localStorage para persistir en las recargas de la página, la lógica solo debe existir en un componente. Menos código duplicado significa menos tiempo para rastrear errores y menos tiempo para mantener todos los duplicados sincronizados.

captura