ddfridley
commented
1 year ago @Boyuan-Yu Here is a way to evaluate the state management issue I am talking about. In use-methods-history/stories/use-methods.stories.js is the simplest test I could think of for the deep state management problem.
You can install the repo and run storybook and interact with it.
The story draws a component. I'm sorry it's not well documented so here's a little bit:
- If you click on the component, it will create a new version of the component as a child with a random size and position.
- If you double click on a component, it will change the color (an internal state).
- After you click on things for a while, you can use the browser's back and forward buttons to go back and forward through the steps you have gone through.
The investigation into state management that I think we need is to compare how this simple test case would be implemented with different state management solutions.
Also, the useMethodsHistory tool does not support updating the url path - meaning that after I click a bunch of times, after I refresh the page, but we want to be able to put state into the url path so that when we hit refresh we will get back to the same place.
Also a bit on the high level. With discussions, there is breadth and depth. Someone might say several things, and the discussion might go into depth on some of them, where someone might say several things, and then go into depth on some of them. It's a recursive process.
Anyway, think about this and lets talk. Thanks.
Currently this project is using react-action-state-path a custom build state and history management system for this project.
This task is about investigating using an existing state management system, or creating a new one.
Here are the user level requirements:
Internal requirements:
Components, like the item component or the point component in the new ui, will get used in many places and often as children of other point components. Their 'state' will need to be preserved and restored if the user goes backward and forward.
Some components need to learn about actions in their children. For example, the RankPoints component shows a list of Points, and users are asked to decide which components are most, neutral, and least important. The parent component needs to get the information from the child of the point component that is selecting most/neurtal/least so it can count them, and limit the number of most/least, and also send the rankings to the database/api. These types of actions were part of RASP and could be part of the new system, or could be done separately.
This code runs on the server side, and then rehydrates and runs on the browser side.
One of the challenges of RASP is that we have to pass a unique key to each child, it would be nice if we didn't have to. And the the challenge is that the unique key needs to by unique even though the component is nested somewhere within other instances of the same component, and other components using the state management system. Generally, the key incorporates a path where each child's key is the parent key with something appended to it. And then that key is passed down to children.
Design/coding philosophy requirements
Related code should be in the same place, ideally the same file. For example we use react-jss so our react components have their code and css in the same file. The state/action code for components that have state and actions should also be in that file.