Why I decided to refactor @knovigator #react UI to use a si…

Problem

the UI works by splitting the screen into 3 panels:left panel has your history so you can easily switch between quests.middle panel is where your work is done, reading or writing quests.right panel shows a comment thread, or sub-quests related to your current answer/note.

at the moment each Panel component manipulates its own state but what happens if I leave a comment, and then want to move the !comment quest into the center panel to continue working on it there...

because each Panel maintains its own state the middle Panel doesn't know anything about the fact that a particular quest has added an answer in another panel and when I access the comments in the middle panel it comes up empty.

Possible Solutions

one solution is to "lift" the state into a common parent component which passes it down to the 3 panels. the problem with this is the panels must pass down a bunch of data and state setters in the component props - known as prop drilling in #react. a tedious practice

another solution is to wrap the components in a Context Provider which passes down data that its child components subscribe to.

What are the downsides of react context

You could also break up your state into multiple Context Providers which wrap each other but this looks and feels ugly similar to callback hell.

another solution is to use a state management library like redux which allows any component in the component hierarchy to reach out and access the application state it needs in some central location.

This seems like the correct approach but having refactored into redux for @cryptograf I have painful memories of writing a ton of boilerplate code including actions, reducers, and tons of decorators like mapStateToProps.

refactoring @knovigator to use @0xca0a zustand state manager