Tengo un objeto observable externo (al componente) en el que quiero escuchar los cambios. Cuando el objeto se actualiza, emite eventos de cambio, y luego quiero volver a renderizar el componente cuando se detecta algún cambio.

Con un nivel superior React.renderesto ha sido posible, pero dentro de un componente no funciona (lo que tiene algún sentido ya que el rendermétodo solo devuelve un objeto).

Aquí hay un ejemplo de código:

export default class MyComponent extends React.Component {

  handleButtonClick() {
    this.render();
  }

  render() {
    return (
      <div>
        {Math.random()}
        <button onClick={this.handleButtonClick.bind(this)}>
          Click me
        </button>
      </div>
    )
  }
}

Hacer clic en el botón llama internamente this.render(), pero eso no es lo que realmente hace que suceda la renderización (puede ver esto en acción porque el texto creado por {Math.random()}no cambia). Sin embargo, si simplemente llamo en this.setState()lugar de this.render(), funciona bien.

Entonces, supongo que mi pregunta es: ¿los componentes de React deben tener un estado para volver a rendirse? ¿Hay alguna forma de obligar al componente a actualizarse a pedido sin cambiar el estado?

En su componente, puede llamar this.forceUpdate()para forzar una rendición.

Documentación: https://facebook.github.io/react/docs/component-api.html

forceUpdatedebe evitarse porque se desvía de la mentalidad React. Los documentos de React citan un ejemplo de cuándo forceUpdatepodría usarse:

De forma predeterminada, cuando el estado o los accesorios de su componente cambian, su componente se volverá a renderizar. Sin embargo, si estos cambian implícitamente (por ejemplo: los datos en el fondo de un objeto cambian sin cambiar el objeto en sí) o si su método render () depende de otros datos, puede decirle a React que necesita volver a ejecutar render () llamando forceUpdate ().

Sin embargo, me gustaría proponer la idea de que incluso con objetos profundamente anidados, forceUpdatees innecesaria. Al utilizar una fuente de datos inmutable, el seguimiento de los cambios resulta económico; un cambio siempre dará como resultado un nuevo objeto, por lo que solo necesitamos verificar si la referencia al objeto ha cambiado. Puede usar la biblioteca Immutable JS para implementar objetos de datos inmutables en su aplicación.

Normalmente, debe intentar evitar todos los usos de forceUpdate () y solo leer de this.props y this.state en render (). Esto hace que su componente sea "puro" y su aplicación mucho más simple y eficiente. forceUpdate ()

Cambiar la clave del elemento que desea volver a renderizar funcionará. Configure el accesorio de clave en su elemento a través del estado y luego, cuando desee actualizar el estado establecido, para tener una nueva clave.

<Element key={this.state.key} /> 

Entonces ocurre un cambio y restablece la clave

this.setState({ key: Math.random() });

Quiero señalar que esto reemplazará el elemento en el que está cambiando la clave. Un ejemplo de dónde esto podría ser útil es cuando tiene un campo de entrada de archivo que le gustaría restablecer después de cargar una imagen.

Si bien la verdadera respuesta a la pregunta del OP sería forceUpdate(), he encontrado que esta solución es útil en diferentes situaciones. También quiero señalar que si se encuentra usando, forceUpdatees posible que desee revisar su código y ver si hay otra forma de hacer las cosas.

NOTA 1-9-2019:

Lo anterior (cambiar la clave) reemplazará completamente el elemento. Si se encuentra actualizando la clave para realizar cambios, probablemente tenga un problema en otro lugar de su código. El uso Math.random()de la clave volverá a crear el elemento con cada render. NO recomendaría actualizar la clave de esta manera, ya que react usa la clave para determinar la mejor manera de volver a renderizar las cosas.

En realidad, forceUpdate()es la única solución correcta, ya que setState()podría no desencadenar una nueva renderización si se implementa lógica adicional en shouldComponentUpdate()o cuando simplemente regresa false.

forceUpdate ()

Llamar forceUpdate()hará render()que se llame en el componente, saltando shouldComponentUpdate(). más...

setState ()

setState()siempre activará una nueva renderización a menos que se implemente la lógica de renderización condicional en shouldComponentUpdate(). más...

Hooks: ¿Cómo puedo forzar al componente a volver a renderizar con ganchos en React?

Por cierto: ¿Está mutando el estado o sus propiedades anidadas no se propagan?

• Cómo actualizar las propiedades del estado anidado en React
• Cómo actualizar las propiedades del estado anidado en React

Evité forceUpdatehaciendo lo siguiente

FORMA INCORRECTA : no utilice el índice como clave

this.state.rows.map((item, index) =>
   <MyComponent cell={item} key={index} />
)

MANERA CORRECTA : use la identificación de datos como clave, puede ser alguna guía, etc.

this.state.rows.map((item) =>
   <MyComponent item={item} key={item.id} />
)

así que al hacer tal mejora en el código, su componente será ÚNICO y se renderizará naturalmente

Cuando desee que dos componentes de React se comuniquen, que no están vinculados por una relación (padre-hijo), es recomendable utilizar Flux o arquitecturas similares.

Lo que desea hacer es escuchar los cambios del almacén de componentes observables , que contiene el modelo y su interfaz, y guardar los datos que hacen que el renderizado cambie como stateen MyComponent. Cuando la tienda inserta los nuevos datos, cambia el estado de su componente, lo que activa automáticamente el renderizado.

Normalmente deberías intentar evitar usar forceUpdate(). De la documentación:

Normalmente, debe intentar evitar todos los usos de forceUpdate () y solo leer de this.props y this.state en render (). Esto hace que su aplicación sea mucho más simple y eficiente.

use ganchos o HOC elija

Usando ganchos o el patrón HOC (componente de orden superior) , puede tener actualizaciones automáticas cuando cambien sus tiendas. Este es un enfoque muy liviano sin un marco.

UseStore Hooks forma de manejar las actualizaciones de la tienda

interface ISimpleStore {
  on: (ev: string, fn: () => void) => void;
  off: (ev: string, fn: () => void) => void;
}

export default function useStore<T extends ISimpleStore>(store: T) {
  const [storeState, setStoreState] = useState({store});
  useEffect(() => {
    const onChange = () => {
      setStoreState({store});
    }
    store.on('change', onChange);
    return () => {
      store.off('change', onChange);
    }
  }, []);
  return storeState.store;
}

withStores HOC maneja las actualizaciones de la tienda

export default function (...stores: SimpleStore[]) {
  return function (WrappedComponent: React.ComponentType<any>) {
    return class WithStore extends PureComponent<{}, {lastUpdated: number}> {
      constructor(props: React.ComponentProps<any>) {
        super(props);
        this.state = {
          lastUpdated: Date.now(),
        };
        this.stores = stores;
      }

      private stores?: SimpleStore[];

      private onChange = () => {
        this.setState({lastUpdated: Date.now()});
      };

      componentDidMount = () => {
        this.stores &&
          this.stores.forEach((store) => {
            // each store has a common change event to subscribe to
            store.on('change', this.onChange);
          });
      };

      componentWillUnmount = () => {
        this.stores &&
          this.stores.forEach((store) => {
            store.off('change', this.onChange);
          });
      };

      render() {
        return (
          <WrappedComponent
            lastUpdated={this.state.lastUpdated}
            {...this.props}
          />
        );
      }
    };
  };
}

Clase SimpleStore

import AsyncStorage from '@react-native-community/async-storage';
import ee, {Emitter} from 'event-emitter';

interface SimpleStoreArgs {
  key?: string;
  defaultState?: {[key: string]: any};
}

export default class SimpleStore {
  constructor({key, defaultState}: SimpleStoreArgs) {
    if (key) {
      this.key = key;
      // hydrate here if you want w/ localState or AsyncStorage
    }
    if (defaultState) {
      this._state = {...defaultState, loaded: false};
    } else {
      this._state = {loaded: true};
    }
  }
  protected key: string = '';
  protected _state: {[key: string]: any} = {};
  protected eventEmitter: Emitter = ee({});
  public setState(newState: {[key: string]: any}) {
    this._state = {...this._state, ...newState};
    this.eventEmitter.emit('change');
    if (this.key) {
      // store on client w/ localState or AsyncStorage
    }
  }
  public get state() {
    return this._state;
  }
  public on(ev: string, fn:() => void) {
    this.eventEmitter.on(ev, fn);
  }
  public off(ev: string, fn:() => void) {
    this.eventEmitter.off(ev, fn);
  }
  public get loaded(): boolean {
    return !!this._state.loaded;
  }
}

Cómo utilizar

En el caso de anzuelos:

// use inside function like so
const someState = useStore(myStore);
someState.myProp = 'something';

En el caso de HOC:

// inside your code get/set your store and stuff just updates
const val = myStore.myProp;
myOtherStore.myProp = 'something';

// return your wrapped component like so
export default withStores(myStore)(MyComponent);

ASEGÚRESE de exportar sus tiendas como singleton para obtener el beneficio del cambio global de esta manera:

class MyStore extends SimpleStore {
  public get someProp() {
    return this._state.someProp || '';
  }
  public set someProp(value: string) {
    this.setState({...this._state, someProp: value});
  }
}
// this is a singleton
const myStore = new MyStore();
export {myStore};

Este enfoque es bastante simple y me funciona. También trabajo en equipos grandes y uso Redux y MobX y encuentro que también son buenos, pero muy repetitivos. Personalmente, me gusta mi propio enfoque porque siempre he odiado mucho código para algo que puede ser simple cuando lo necesitas.

Entonces, supongo que mi pregunta es: ¿los componentes de React deben tener un estado para volver a rendirse? ¿Hay alguna forma de obligar al componente a actualizarse a pedido sin cambiar el estado?

Las otras respuestas han tratado de ilustrar cómo podría hacerlo, pero el punto es que no debería . Incluso la solución hacky de cambiar la clave pierde el sentido. El poder de React es ceder el control de la gestión manual cuando algo debería renderizarse y, en cambio, solo preocuparse por cómo algo debería mapearse en las entradas. Luego suministre flujo de insumos.

Si necesita forzar manualmente la re-renderización, es casi seguro que no esté haciendo algo bien.

Hay algunas formas de volver a procesar su componente:

La solución más simple es usar el método forceUpdate ():

this.forceUpdate()

Una solución más es crear una clave no utilizada en el estado (nonUsedKey) y llamar a la función setState con la actualización de esta nonUsedKey:

this.setState({ nonUsedKey: Date.now() } );

O reescribe todo el estado actual:

this.setState(this.state);

El cambio de accesorios también permite volver a reproducir los componentes.

Puedes hacerlo de dos formas:

1. Utilice el forceUpdate()método:

Hay algunas fallas que pueden ocurrir al usar el forceUpdate()método. Un ejemplo es que ignora el shouldComponentUpdate()método y volverá a representar la vista independientemente de si shouldComponentUpdate()devuelve falso. Debido a esto, el uso de forceUpdate () debe evitarse siempre que sea posible.

2. Pasando this.state al setState()método

La siguiente línea de código resuelve el problema con el ejemplo anterior:

this.setState(this.state);

Realmente, todo lo que está haciendo es sobrescribir el estado actual con el estado actual, lo que desencadena una nueva representación. Esta no es necesariamente la mejor manera de hacer las cosas, pero supera algunos de los fallos que puede encontrar con el método forceUpdate ().

Para completar, también puede lograr esto en componentes funcionales:

const [, updateState] = useState();
const forceUpdate = useCallback(() => updateState({}), []);
// ...
forceUpdate();

O, como gancho reutilizable:

const useForceUpdate = () => {
  const [, updateState] = useState();
  return useCallback(() => updateState({}), []);
}
// const forceUpdate = useForceUpdate();

Ver: https://stackoverflow.com/a/53215514/2692307

Tenga en cuenta que el uso de un mecanismo de actualización forzada sigue siendo una mala práctica, ya que va en contra de la mentalidad de reacción, por lo que aún debe evitarse si es posible.

Podemos usar this.forceUpdate () como se muestra a continuación.

       class MyComponent extends React.Component {



      handleButtonClick = ()=>{
          this.forceUpdate();
     }


 render() {

   return (
     <div>
      {Math.random()}
        <button  onClick={this.handleButtonClick}>
        Click me
        </button>
     </div>
    )
  }
}

 ReactDOM.render(<MyComponent /> , mountNode);

La parte Element 'Math.random' en el DOM solo se actualiza incluso si usa setState para volver a renderizar el componente.

Todas las respuestas aquí son correctas y complementan la pregunta de comprensión ... como sabemos, para volver a renderizar un componente sin usar setState ({}) es usando forceUpdate ().

El código anterior se ejecuta con setState como se muestra a continuación.

 class MyComponent extends React.Component {



             handleButtonClick = ()=>{
                this.setState({ });
              }


        render() {
         return (
  <div>
    {Math.random()}
    <button  onClick={this.handleButtonClick}>
      Click me
    </button>
  </div>
)
  }
 }

ReactDOM.render(<MyComponent /> , mountNode);

Solo otra respuesta para respaldar la respuesta aceptada :-)

React desalienta el uso de forceUpdate()porque generalmente tienen un enfoque muy "esta es la única manera de hacerlo" hacia la programación funcional. Esto está bien en muchos casos, pero muchos desarrolladores de React vienen con un fondo de OO, y con ese enfoque, está perfectamente bien escuchar un objeto observable.

Y si lo hace, probablemente sepa que DEBE volver a renderizar cuando el observable "se dispara" y, como tal, DEBE usar forceUpdate()y en realidad es una ventaja que shouldComponentUpdate()NO está involucrada aquí.

Herramientas como MobX, que adopta un enfoque OO, en realidad están haciendo esto debajo de la superficie (en realidad, MobX llama render()directamente)

He encontrado que es mejor evitar forceUpdate (). Una forma de forzar la re-renderización es agregar la dependencia de render () en una variable externa temporal y cambiar el valor de esa variable cuando sea necesario.

Aquí hay un ejemplo de código:

class Example extends Component{
   constructor(props){
      this.state = {temp:0};

      this.forceChange = this.forceChange.bind(this);
   }

   forceChange(){
      this.setState(prevState => ({
          temp: prevState.temp++
      })); 
   }

   render(){
      return(
         <div>{this.state.temp &&
             <div>
                  ... add code here ...
             </div>}
         </div>
      )
   }
}

Llame a this.forceChange () cuando necesite forzar la re-renderización.

ES6 - Incluyo un ejemplo, que fue útil para mí:

En una "declaración if corta" puede pasar una función vacía como esta:

isReady ? ()=>{} : onClick

Este parece ser el enfoque más corto.

()=>{}

forceUpdate(); El método funcionará, pero es aconsejable utilizar setState();

Para lograr lo que está describiendo, intente this.forceUpdate ().

Otra manera está llamando setState, y conserva el estado de:

this.setState(prevState=>({...prevState}));

forceUpdate (), pero cada vez que escucho a alguien hablar de ello, se le ha hecho un seguimiento y nunca debería usar esto.