I know you’ve kinda gone on exploring from the first post, but 1 is how it should be done. The array of quotes is the state, and React is designed so as to map that state to visual representation. You probably also want 3, so you have an object with the array of quotes as one property, the current quote as another and so on. That is also part of the state. Redux is a way to keep all of the state insulated from the functional part of the app.
The issue with functional approaches is that every function should ideally be pure, so if you give it some thing it will always return the same result as long as that thing is the same. Which means, basically, state is difficult to deal with, because it often involves side effects, which are verboten. So there are different approaches, but they boil down to:
You move the state somewhere else, behind a safe interface, and you only interact with it via that interface[1]. In the case of Redux, you put all[2] the state in one object, the store
, and you interact with it via reducers. The reducers are just functions, they don’t have any state whatsoever. You could [almost] uninstall Redux, just leaving those reducers, replace the store entirely with a data structure of the same shape, and if you hand the reducer function that data they will still work (obviously there are a few helper functions that Redux provides that mean you’re unlikely to be able to do this in practice, but this is basically true).
The other major benefit of holding all the state in Redux is that Redux mandates that the data is immutable. This means in practice that you can go back and forth in history within the app because it becomes trivial to keep a record of every change that ever happened to the state.
[1] For example, in Haskell you use a construct called a monad, one that is designed to handle state - if you have used Promises in JS, those are essentially a type of monad, they work the same way. With monads for state, you wrap your data in a monad, which does the work, then you unwrap it to get a value - like with a promise, a fetch
request gets wrapped in a promise, and the value gets got (or not), then you unwrap the promise to get the value out.
[2] In practice, you don’t put all the state in the store, because this is a bit ridiculous - a good example is listening to characters typed into a search box. You could update the store with the new value every time a user hits the keyboard, but in practice what you do is have a component with state
, and you update the state of that component only. Then when, say, the user hits enter, then you save the full value they are searching for to the store.