The heart of any modern website or browser application (that SPA, that PWA, that any other three letters) is its State, or state.
We can argue arbitrarily about which is better - React, Vue, Svelte, Angular, we can continue to use jQuery, but in reality it is not so important. This is the part of our application that we see - its “muscles” and “skin”. But the way you think - with what terms you operate, what mechanics you use to even visualize in your head how the data "flows" in your application - all this comes from its skeleton. From the state manager.
Remember, a couple of years ago, we were tired of JavaScript ? Now I see a huge number of people getting tired of state mangers. Redux? Yes , yes and yes . RxJS? Too . MobX? If it’s so simple - damn it, why does it have a trap.html page in the documentation ?
The answer "why is it so hard for many" is, but first you need to accurately formulate the problem.
Choosing a state manger - we choose a way of thinking. There are many options now, but the most popular approaches fall into 3 groups:
Flux / Redux-like : a global repository with actions and reducers. There are quite a lot of them, but I would mention Redux , Effector , Storeon , Unstated , and Reatom myself . These are not “the best of the best,” but rather the “most diverse.” All solutions from the list carry something unique and unusual, and you can grab various interesting ideas from them.
This approach is primarily imperative (Thuring-complete) and global .
Observables and pipes. Today's most popular solutions in this group are RxJS and MobX . Of the less known - Kefir , Bacon , CycleJS . Svelte , by the way, also falls into this list. They are all very different in terms of developer experience, but from a fundamental point of view they differ only in one thing: MobX, Svelte, and others can be described in terms of topology by the usual “what triggers what” graph, but RxJS is not, its graph is multidimensional and “strange loops” may appear in ittransmitting observables in observables. This makes it more powerful on the one hand, and more complex on the other. A similar story was with the script. They found out that his type system is Thuring-complete. The only thing that followed was that it could freeze at the verification step, and they added a time limit to the work.
This may sound rather strange, but in general this class of solutions tends to be local, or ad-hoc and declarative - but without cutting off the ability to use arbitrary logic.
, - , , , , “” . , 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 , ( ), . , . .
Any interaction between the two worlds should be explicit, directly distinguished in the code, so as not to happen by chance during the code review, and most importantly - to happen in userland, and not in libraries.
You should not choose specific solutions, but for my new project I would use GraphQL + Apollo for storing knowledge , and for state management - Xstate + RxJS, fortunately, they are friends with each other .
Stop worrying about stuffing everything into one solution. You do not need it.