Por lo que entendí, cada parte del código que está relacionada con cualquier estado se cambiará (recompondrá) con cambios de estado →
Y cada estado es un observable y la parte de la interfaz de usuario dependiente observa ese estado y está suscrita a él (el estado) y cada vez que el estado cambia, se le notificará (redibujando esa parte de la interfaz de usuario) y se producirá una recomposición.
Pero aquí, en este artículo de Google Thinking in compose , dice que la recomposición ocurre al cambiar la entrada, por lo que estoy confundido.
La recomposición es el proceso de volver a llamar a sus funciones componibles cuando cambian las entradas . Esto sucede cuando cambian las entradas de la función. Cuando Compose recompone en función de nuevas entradas, solo llama a las funciones o lambdas que podrían haber cambiado y omite el resto. Al omitir todas las funciones o lambdas que no tienen parámetros modificados, Compose puede recomponer de manera eficiente.
Además, aquí en otra muestra de compose-roadmap , anime a elevar el estado para hacer que la función componible no tenga estado para evitar recomposiciones
Entonces, sería genial, si alguien puede dejar en claro que las recomposiciones ocurren solo con cambios de estado o cambios de entrada que también causan.
Gracias de antemano por su ayuda
La recomposición ocurre cuando los valores de los parámetros cambian o se actualiza una variable de estado mutable dentro de la función componible.
Una función sin estado, a veces denominada función "inmutable", es aquella en la que no se almacenan datos en la función. Esto significa que si llamas a la función repetidamente, sería lo mismo que si la hubieras llamado por primera vez. La función no retiene memoria de ninguna variable cada vez que se llama.
Elevar el estado de un componible significa que las variables de estado se mantienen fuera del componible y los valores de esas variables de estado se pasan al componible como parámetros normales. Esto le permite reutilizar el componible. Esto es especialmente importante si está creando una biblioteca de componibles que desea reutilizar de un proyecto a otro. Los usuarios de la biblioteca pueden estar seguros de que no hay dependencias de estado que requiera el componible. Si desea un componible verdaderamente sin estado, evitaría hacer cosas como pasar modelos de vista. Un modelo de vista depende en gran medida de la aplicación en la que reside y tendrá un código que es muy específico para la aplicación. Un componible sin estado no depende de la aplicación y, por lo tanto, se puede reutilizar en otro lugar.
Eso no significa que no puedas usar modelos de vista en tus componibles. Inicialmente, Google estaba en contra de esto cuando apareció Compose por primera vez, pero se dio cuenta de que era muy incómodo para los desarrolladores. Si un desarrollador no tenía ninguna razón para hacer un componible reutilizable fuera de la pantalla en la que aparece, elevar el estado de cada componible se convierte en un dolor que resulta en un código repetitivo innecesario. Entonces, la regla general es que si su componible no se va a reutilizar en otro lugar y necesita acceso a los datos del modelo de vista, puede pasar el modelo de vista como un parámetro o acceder a él dentro del componible a través de otros medios.
Además de los modelos de vista, es posible que aún desee hacer un estado componible incluso cuando necesite reutilizarse. Un buen ejemplo de esto es si está utilizando un TextField. A medida que escribe el texto, desea que aparezca el texto. Sin utilizar una variable de estado para conservar los caracteres escritos, no verá la actualización de TextField. Por esta razón, es aceptable usar una variable de estado local para almacenar los caracteres ingresados. Si bien esto no hace que el componible no tenga estado, aún es algo que debe implementar. Sin embargo, incluso en este ejemplo, aún puede hacerlo sin estado pasando los caracteres escritos nuevamente a la función izada y almacenándolos en una variable de estado de modelo de vista que a su vez activa la función izada para recomponer el componible y pasar el texto que el necesidades de TextField. Pero esto es bastante complicado y un gran viaje de ida y vuelta solo para obtener los caracteres que se muestran en TextField y, por lo tanto, no se recomienda. Sin embargo, es posible que desee hacerlo si tiene un TextField componible muy complejo y necesita procesar los caracteres en su modelo de vista a medida que se escriben, como podría ser el caso de hacer una búsqueda de sugerencias para una URL.
Entonces, incluso si su componible no tiene estado pero su modelo de vista tiene una variable de estado mutable que la función izada está observando, si el estado mutable de esa variable cambia, la función izada se recompondrá. Pero si el componible al que llama el componible izado se recompone depende de si los valores del parámetro para ese componible cambian. Si cambian, se producirá una recomposición.