-
Notifications
You must be signed in to change notification settings - Fork 5
상태관리의 대상
Harry edited this page Nov 12, 2021
·
1 revision
기존구조 - 에픽 → 스토리 → 태스크의 위계구조를 가지는 구조이기 때문에 에픽 안에 스토리가 있고, 스토리 안에 태스크가 들어가 있는 중첩된 자료구조를 가질 수도 있고, 에픽, 스토리, 태스크를 따로 따로 가지고 있을 수도 있음
{
"project": {
"epics": [{ "stories": [{ "tasks": [{ ... }, { ... }, { ... }],}, { ... }, { ... }], }, { ... }, { ... }],
"anoterEpics": [{ "stories": [{ "tasks": [{ ... }, { ... }, { ... }],}, { ... }, { ... }], }, { ... }, { ... }]
},
"anotherproject": {
"epics": [{ "stories": [{ "tasks": [{ ... }, { ... }, { ... }],}, { ... }, { ... }], }, { ... }, { ... }],
"anoterEpics": [{ "stories": [{ "tasks": [{ ... }, { ... }, { ... }],}, { ... }, { ... }], }, { ... }, { ... }]
},
...
}
개선구조 - 에픽과 스토리를 따로 전역변수로 구조를 잡음
{
"projectName":[{epics}, {anotherEpics}],
"anotherProjectName":[{epics}, {anotherEpics}],
}
{
"projectName":[{stories}, {anotherStories}],
"anotherProjectName":[{stories}, {anotherStories}],
}
또 개선 구조 - 에픽과 스토리를 따로 전역 변수로 구조를 잡는데, projectName을 삭제함
[{epics},{epics},{epics},{epics},{epics]
[{stories},{stories},{stories},{stories},{stories},{stories}]
-
관리하기 번거롭다
- immutable 을 한 상태관리를 위해 중첩관리에서 각각을 분리
- 복잡해진다. 작업페이지와 홈페이지 간의 동기화가 번거롭다.
- 상태관리를 하지 않게 되면, DB 만 업데이트를 하고, 작업페이지에서도 칸반 아이템을 클릭됐을 때 업데이트하는 식의 최신화, DB 만 바꾸면 된다.
-
동기화를 굳이 진행할 필요는 없다
- 이 상태를 Task 를 보고 있으면 어떻게하냐? 실시간 동기화가 되지않는데? 큰 Risk 라고 생각하지 않는다.
- Task 는 Interaction 이 있어야 뜨는 부분이므로 그 때마다 DB에서 확인하므로 거의 최신화 가능.
- 오히려 상태로 갖고 있으면 상태변경마다 모든 접속자의 상태를 변경해야하므로 번거로움. 상태로 갖지 않으면 우리의 DB만 변경하면 됨.
-
SinglePage Application 에 맞지 않다.
- 사용자가 한 화면에 다 보이는게, Task 는 사용자의 Interaction 마다 뜨는 항목. 이걸 관리하기 보다는 Caching
- SPA 는 필요한 데이터가 있을 때 그 부분을 업데이트,
- 모든 데이터를 다 보여주는 것 아닌가.
- SPA 의 설계 의도와 어울리지 않지 않는다고 생각.
- 중첩구조를 해제하고 각각의 context 제작
- task의 경우 사용자의 interaction이 있어야만 뜨는 것이므로 context에서 제외
- 추후 task는 캐싱