Skip to content

상태관리의 대상

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}]

Task를 전역 context로 관리해야될까?

  1. 관리하기 번거롭다

    • immutable 을 한 상태관리를 위해 중첩관리에서 각각을 분리
    • 복잡해진다. 작업페이지와 홈페이지 간의 동기화가 번거롭다.
    • 상태관리를 하지 않게 되면, DB 만 업데이트를 하고, 작업페이지에서도 칸반 아이템을 클릭됐을 때 업데이트하는 식의 최신화, DB 만 바꾸면 된다.
  2. 동기화를 굳이 진행할 필요는 없다

    • 이 상태를 Task 를 보고 있으면 어떻게하냐? 실시간 동기화가 되지않는데? 큰 Risk 라고 생각하지 않는다.
    • Task 는 Interaction 이 있어야 뜨는 부분이므로 그 때마다 DB에서 확인하므로 거의 최신화 가능.
    • 오히려 상태로 갖고 있으면 상태변경마다 모든 접속자의 상태를 변경해야하므로 번거로움. 상태로 갖지 않으면 우리의 DB만 변경하면 됨.
  3. SinglePage Application 에 맞지 않다.

    • 사용자가 한 화면에 다 보이는게, Task 는 사용자의 Interaction 마다 뜨는 항목. 이걸 관리하기 보다는 Caching
    • SPA 는 필요한 데이터가 있을 때 그 부분을 업데이트,
    • 모든 데이터를 다 보여주는 것 아닌가.
    • SPA 의 설계 의도와 어울리지 않지 않는다고 생각.

결론

  • 중첩구조를 해제하고 각각의 context 제작
  • task의 경우 사용자의 interaction이 있어야만 뜨는 것이므로 context에서 제외
  • 추후 task는 캐싱
Clone this wiki locally