El corazón de cualquier sitio web moderno o aplicación de navegador (ese SPA, ese PWA, que otras tres letras) es su Estado o estado.
Podemos discutir todo lo que queramos sobre lo que es mejor: React, Vue, Svelte, Angular, podemos seguir usando jQuery, pero en realidad no es tan importante. Esta es la parte de nuestra aplicación que vemos: sus "músculos" y "piel". Pero la forma en que piensas, con qué términos operas, qué mecanismos utilizas para visualizar incluso en tu cabeza cómo "fluyen" los datos en tu aplicación, todo esto proviene de su esqueleto. Del gerente estatal.
¿Recuerdas que hace un par de años estábamos cansados de JavaScript ? Ahora veo a un gran número de personas cansarse de los administradores estatales. Redux? Si , si y si . RxJS? Demasiado . MobX? Si es tan simple, maldita sea, ¿por qué tiene una página trap.html en la documentación ?
La respuesta "por qué es tan difícil para muchos" es, pero primero debe formular con precisión el problema.
Elegir un administrador del estado: elegimos una forma de pensar. Ahora hay muchas opciones, pero los enfoques más populares se dividen en 3 grupos:
Flux / Redux-like : un repositorio global con acciones y reductores. Hay muchos de ellos, pero yo mencionaría a Redux , Effector , Storeon , Unstated y Reatom . Estos no son "los mejores de los mejores", sino los "más diversos". Todas las soluciones de la lista tienen algo único e inusual, y puede obtener varias ideas interesantes de ellas.
Este enfoque es fundamentalmente imperativo (Thuring-complete) y global .
Observables y tuberías. Las soluciones más populares de hoy en este grupo son RxJS y MobX . De los menos conocidos: Kefir , Bacon , CycleJS . Svelte , por cierto, también cae en esta lista. Todos son muy diferentes en términos de experiencia del desarrollador, pero desde un punto de vista fundamental difieren solo en una cosa: MobX, Svelte y otros pueden describirse en términos de topología por el gráfico habitual "qué dispara qué", pero RxJS no lo es, su gráfico es multidimensionales y "bucles extraños" pueden aparecer en éltransmitir observables en observables. Esto lo hace más poderoso por un lado, y más complejo por el otro. Una historia similar fue con el guión. Descubrieron que su sistema de tipos es completo de Thuring. Lo único que siguió fue que podría congelarse en el paso de verificación, y agregaron un límite de tiempo al trabajo.
Esto puede sonar bastante extraño, pero en general esta clase de soluciones tiende a ser local, o ad-hoc y declarativa , pero sin cortar la capacidad de usar lógica arbitraria.
, - , , , , “” . , Lodash, Ramda, io-ts. - LISP JS, — -- “”, , .
GraphQL . Apollo Relay — , . Falcor — GraphQL Netflix, GunDB PouchDB. , Redux, MobX, RxJS . “” GraphQL. , . 100% ( )
, . — , ; , - . .
: “” “” 100% : redux- , , RxJS — . JS , , .
: - ID ID, — . (), — .
. - . , , , "state of js” .
.
.
, , . , — , . , .
— , , . , , — GraphQL . , , .
, - .
SPA , : , , SQL- ; .
Rails, , .
, , ( ) — API , .
:
- : . , , , .
- : statechart. — . — observables (RxJava, RxRuby, RxSwift, RxBrainfuck — ) . — - , , - .
. , , . — . , , , , — . , , - . — , .
— - , . - , . — , , , .
. , , , corrupted. : , DTO. . — LISP-. : , .
— . , — , , , — - , . , , . : - — , . , , CRDT-. — .
:
.
— , , — , , . , . , , . await getBlogPost(id), : @gql("blogPost(id){...}") class extends Component, — , .
. . ImmutableJS, Object.freeze, readonly Record & Tuple stage 1 proposal. . - shared worker.
, — , . XState , ( ), . , . .
Cualquier interacción entre los dos mundos debe ser explícita, distinguirse directamente en el código, para que no ocurra por casualidad durante la revisión del código, y lo más importante, que ocurra en el país de usuario y no en las bibliotecas.
No debe elegir soluciones específicas, pero para mi nuevo proyecto usaría GraphQL + Apollo para almacenar conocimiento y para la gestión del estado : Xstate + RxJS, afortunadamente, son amigos entre sí .
Deja de preocuparte por meter todo en una solución. No lo necesitas.