But in React it is such a huge issue, and there are multiple competing solutions. There must be something wrong with the design of React that is causing this.
Its a huge issue in all of those also. It just presents itself differently. JSP -- every click has to post or query param change re-renders the page. This gets hugely cumbersum with tree stateor anything other than basic switches. In a lot of ways its the one way data flow we all want in react. For a lot of pages its easy. Same with React, However complex state is so difficult to do in JSP you really can't write the apps we write today.
I would say React's state management is its great success, rather than its `functionalness` or its reactivity. No other UI framework (QT|WinForms|MOTIF|GTK) really ever handled state well.
Don't have experience with ASP or JSP, but managing state in React is vastly superior than iOS. Having a defined place to keep your data, and your view automatically refresh when it changes is the gold standard in user interface design. iOS does not easily have this kind of functionality, forcing people to use all sorts of messy techniques that are hard to follow and maintain.
The main "Apple approved" tools for user interface and state management are CoreData and UIKit. Both are imperative, mutable, and overall difficult to work with. This might be subjective, but I always notice just how poorly Apple's own apps work. There is always some button that is stuck in the wrong state, some feature that doesn't do what its supposed to, and some broken animation when views reload (I'm looking at you Podcast app). I can't know why, but my hunch is that Apple engineers are forced to use unwieldy patterns and technologies like CoreData, MVC, and UIKit, and are drowning in a sea of unmaintainable code.
As a response to the inadequate tools Apple provides, big industry leaders have stepped up and rolled their own declarative solutions. IGListKit from Instagram is a prime example of a declarative user interface solution thats vastly superior to Apple's. Going even further, Facebook basically ported React into iOS with ComponentKit.
It took Apple a good decade, but they are finally giving us these types of tools as well with SwiftUI. However, judging from its low adoption, so far they have not managed to fully get things right.
> Having a defined place to keep your data, and your view automatically refresh when it changes is the gold standard in user interface design.
First, in most frameworks there is only one place to keep your data. This can be your App object or session state.
Having view automatically refresh is overrated. Given the amount of work you have to do (actions, reducers, dispatch and whatnot) it is easier to just update the view yourself.
You don't need any of that if you just use React. All you need is `setState()`. All of those extra things you are thinking about are part of Redux, not React. I love Redux, but even just pure React is a huge improvement over UIKit.
UIKit kind of reminds me of Backbone.js - it has some infrastructure but its up to you to build a lot of the tools yourself. You might prefer that personally, but I think the movement of the frontend community from Backbone to React shows that most developers prefer a more full feature solution.
> You don't need any of that if you just use React.
You do need it if you use ReactRouter. Otherwise your state will be spread (or duplicated even) across multiple components, and it will be a nightmare to deal with.
Whats stopping you from just importing a plain javascript module that has mutable data on all your screens? You can even write it to local storage on every update to preserve it across app refreshes.
Thats essentially what you have in iOS with your AppState example. There is no need to use a Reactive Store if you just want to share some state between screens.
React is not a complete framework more of a templating engine and nothing more, it allows you to use any state management you want. It also makes it easy to add to existing projects without requiring rewrite of everything from the ground up.
The downside of this is that it's often the complete wild west when building and doing maintenance. It's not uncommon to end up with wildly different state management solutions in every project because the prevailing winds change so frequently. This can have a big effect on productivity and morale. It's one of the main reasons I'm trying to get out of programming for my profession. I'm so fucking tired of having to chase the flavor of the month.
> What is it about React that state management is such a such a hassle?
I'm not sure it's a hassle, just different schools of thought.
> This is not the case in other frameworks.
None of the examples you mention are reactive AFAIK. The point of React is that the UI is a function of the state. How exactly that is accomplished is where those different schools of thought come into the picture.
React has fantastic tools for state management built-in. The difficulty is a particular flavor of state management: data that lives in the "global" scope but can be used locally in components in a reactive fashion. We have some good tools for doing this but they all have drawbacks, hence the experimentation.
FWIW I've never seen a really great solution for this in any JavaScript framework. I read it as a sign of React's maturity that this is a focus.
I would say React's state management is its great success, rather than its `functionalness` or its reactivity. No other UI framework (QT|WinForms|MOTIF|GTK) really ever handled state well.