Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • S survey
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 12
    • Issues 12
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • students
  • survey
  • Issues
  • #26

Closed
Open
Created Aug 19, 2022 by Yoon, Daeki@dyoon😅Owner

설문 수정 논리 고려할 사항

설문 수정할 때 각각의 문제들이 수정될 때마다 백엔드에 적용을 해서 동기화 된 것을 사용할 것인지, 아니면 프론트쪽에서만 수정을 적용한 것을 최종 제출할 때 서버에 적용할 것인지를 고려해야 합니다.

동기화 할 때 문제점

  1. 매번 통신을 하는 부담
  2. 매번 디비 테이블 수정 부담
  3. 설문 수정을 하다가 취소 버튼을 누르면 기존 업데이트 된 문제들을 어떻게 서버에 적용할 것인지 문제. 즉 이미 각각의 수정된 문제가 서버에 적용되었기 때문에 취소할 때는 원래 문제로 어떻게 복구하는냐가 문제이다.
    • 해결책: 취소 버튼을 빼는 방법이 있습니다.
  4. 수정하기 버튼을 클릭하지 않고 나갔을 때 이미 적용된 문제들을 어떻게 처리하나?

프로트 쪽에만 적용한 후 제출할 때 서버에 적용

  1. 서버쪽에서는 새로 추가된 문제는 아이디가 임의로 설정되었기 때문에 디비 문제(question) 테이블 수정할 때 에러가 발생합니다.
  2. 서버쪽 처리 로직이 복잡해 집니다.

다른 제안

  1. 제목과 설명 항목에 대해서도 각각 수정 버튼을 포함시키는 방법도 있을 것입니다. 그렇게 되면 1번 문제점 들 중에 3, 4번은 없어질 것 같습니다. 즉, 설문에 대한 취소 자체가 없어지게 되는 것이죠.
Edited Aug 19, 2022 by Yoon, Daeki
Assignee
Assign to
Time tracking