If you want to experiment, my advice would be to start by just using React as a template-rendering system that lets you conveniently build larger and more complex components by composing smaller and simpler ones and that can automatically change whatever is already in your DOM to whatever new DOM content you come up with when rerendering. At this stage, you can take advantage of React’s greatest strengths, but you don't need any bells and whistles like Redux or Immutable or MobX or whatever other state management libraries you’ve come across.
One thing I would recommend right from the start is storing your application state somewhere outside your React components, even if it’s just in plain JavaScript objects. When you’re ready to render a DOM tree, pass that data into the top-level React component via props. Have that top-level component in turn pass any relevant part(s) of its input data to any child component(s) that need that data for their own rendering.
Likewise, I would recommend defining the functions to handle any interesting events outside your React components. You can then pass any callbacks you might need in via props on your components as well.
If you try that sort of design out a few times with non-trivial apps, you’ll soon start to see common patterns where introducing other tools might be helpful, and at that point you’ll have a better understanding of what some of those other libraries do and which combinations of related libraries might be useful for your particular needs.
I’d like to repeat here that React doesn’t require that you use that particular style of architecture, and there are plenty of reasonable alternatives. However, hopefully those examples should suffice to demonstrate that separation of underlying state from UI rendering and responding to interactions makes as much sense with React as in other contexts and is widely employed in practice.
If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the React component via `props` so it knew what to render, and the callback function to handle a form submission would also be passed in via `props`, and the React component would have no dependencies on anything else in your system. It’s actually one of the simplest, cleanest and most completely specified interfaces of any modern JS UI library or framework, in my experience.
It is true that a React component can also hold its own state and can use that data in addition to the supplied props when rendering. However, that state is normally reserved for UI-related data that isn’t part of the underlying data model, such as keeping track of a selected item or which page is currently active on a paginated table view. Toy examples like to-do lists sometimes use React component state to hold more general data, because that is simpler in a trivial demonstration than writing separate MVC components or the equivalent, but that’s not how you write idiomatic React code in production systems, and it never has been.