I just woke up realising my mental model for state on front-end is filesystem trees — folders and files. Components are like folders. State is like files. “Single source of truth” just means “Pick a folder for that Excel report instead of putting copies of it into five folders”.

Then when you have a second system like Redux or Vuex it’s like a USB stick and you create shortcuts to folders in it. So you get both the benefits and the downsides of a second hierarchy to think about. This disk’s folder layout is completely different from the main one.

“Lifting state up” means that if your London visiting guide PDF is related to both Trips/London/Summer and Trips/London/Spring, you should just move it up into Trips/London. But you shouldn’t put it unnecessarily high up (Trips) because that loses some meaning about its purpose.

If you haven’t guessed yet, keys are folder names. (If you don’t specify a key, it’s implied from the order in the parent — 0, 1, 2, and so on.)

People commonly misunderstand keys as some performance optimization but they’re really segments of the “folder path” to your state.

This analogy doesn’t explain props so some important properties are lost (no pun intended). Such as it doesn’t make clear why deriving state from props or forgetting a key can lead to problems.