¿Es posible sin Redux?

Hoy puede encontrar muchas posiciones donde se requiere reaccionar / reducir. Reaccionar es genial, no se hacen preguntas. La pregunta para Redux es si es posible sin él. Si buscas un poco en Google, hay un artículo sólido sobre Habré , donde el autor hace la misma pregunta. En un artículo con un ejemplo simple (todoList), el método this.updateViews () se llama con demasiada frecuencia (de siete a ocho veces) y parece más fácil de hacer.

La idea principal aquí es modelos observables, reaccionar es responsable de observables, lo único que queda es crear un modelo.

Antes de crear el modelo, algunas palabras sobre el diseño (arquitectura) del cliente:

índice - datos sin procesar
historia - matriz [modelo]
observador - modelo
vista - errores, foco, banderas

index.jsx: punto de entrada del programa para la pantalla del usuario. Index procesa todos los componentes con datos predeterminados, realiza consultas asincrónicas, vuelve a dibujar componentes con datos nuevos.

// index.jsx <History> <Observer> <HeaderView /> <MainView /> </Observer> </History> 

Observer.jsx es responsable de sincronizar el modelo para múltiples vistas. Por ejemplo, Petya completa un formulario de oferta y ve una vista previa en tiempo real en el encabezado de la página. Observer almacena el objeto modelo, proporcionando api: onModelChange (campo, valor) a los componentes secundarios.

History.jsx es una pila de objetos modelo, donde api: commit y rollback.

Model.js es lo que el usuario puede ingresar con bolígrafos, es decir, el más valioso. No es necesario almacenar otros datos en el modelo. El modelo no es un componente de reacción, sino una clase js regular.

 class Model { constructor(other = {}) {} // copy constructor (and default too) isEqual(other) {} // operator == less(other) {} // operator< swap(other) {} hash() {} fieldNameConstrains() {} //see below please } 

El constructor de copia es al menos necesario para la Historia. El método isEqual es para cambios emergentes no guardados (que es mucho más conveniente que el indicador en estado). El método fieldNameConstrains es para campos dependientes.

En términos generales, si hay campos dependientes, deben cambiarse todos seguidos.

 class Model { // constrains // distance <== velocity * time velocityConstrains(newVelocity) { this.velocity = newVelocity; this.distance = this.velocity * this.time; } timeConstrains(newTime) { … } distanceConstrains(newDistance) { this.distance = newDistance; this.time = this.distance / this.velocity; } } 

Por experiencia personal, algo como model.field.onchange no funciona, ya que a veces es necesario llamar al constructor de copias y los eventos onchange no son necesarios en absoluto.

View.jsx

 class View extends React.Component { state = { errors: {}, focus: {}, … } render() { … <input value={this.props.model.title} onChange={e => this.props.onModelChange('title', e.target.value)} /> … } } 

Validación La validación no necesita hacerse en el modelo. Debe hacerse a la vista (no olvide que la vista es la pantalla del usuario y que no se puede mostrar todo el modelo en la pantalla). Los validadores son un conjunto de predicados. Solo hay dos algoritmos para la validación: 1) encontramos todos los errores en el formulario o 2) encontramos el primer error. Por ejemplo

 class View extends React.Component { onClickSaveButton() { const mapper = { title: () => model.title.length && !maxLenValidator(model.title, 25), price: () => !(model.price % 40 == 0), url: () => !urlValidator(model.url), … } const errors = map(mapper, (validator, key) => { return validator() ? key : undefined; }).filter(Boolean); } //       

Derechos de acceso. Lo principal aquí es quedarse y no usar la herencia. La idea es que el modelo contiene todos los campos y recortamos los campos para los roles. Es decir, es una lista blanca, los campos restantes en el modelo permanecen por defecto. Se agrega un paso para la validación: hacemos una proyección del objeto de validación (también es mapeador, ver arriba), es decir, validamos solo los campos necesarios.

Sobre producción. Este enfoque ha estado girando en producción durante un año, es una interfaz para crear campañas publicitarias, incluidos banners. Formas de diversa complejidad: desde un modelo hasta la pantalla, que terminan con muchos modelos de diferentes tipos. Aquí puede agregar que al backend le gusta enviar estructuras anidadas, no debe ser tímido y almacenar solo estructuras planas en la vista.

Sobre el método del modelo isEqual. En algún lugar de utils.js habrá métodos isEqual e isEqualArray:

  function isEqual(left, right) { return left.isEqual(right); } isEqualArray(v1, v2) { if (v1.length !== v2.length) { return false } for (var k = 0; k != v1.length; k++) { if (!isEqual(v1[k], v2[k])) { return false; } } return true; } 

Debe intentar no hacer modelos anidados. No olvide que el modelo son datos de usuario, no una estructura de datos.

Referencias

→ Tiempos
→ dos