0720 OMP

[클라이언트]

1. 라이브러리 선정
   • 이 기능의 핵심 철학은 우리의 오더관리(혹은 그외 내부 데이터 관리)를 효율적으로 처리하기 위함
   • Cell Data 기반으로 기본적인 기능은 구현하되 엑셀 수준의 기능개발이 아님.
   • 엑셀 기능은 최소한으로 가지고 있어야 함(너무 엑셀에 가까우면 확장성이 떨어짐)
   • 클릭한 셀의 메타데이터(어떤 오더의 세부정보인지)를 알 수 있도록 커스텀할 수 있는 여지가 있어야 함

• 현재까지 찾은 적임자: ReactGrid(1.56MB)

2. 데이터 구조에 대한 논의

   • 원본 데이터에서 CRUD한 셀의 데이터만 상태관리할 수 있는 자료구조 필요 → 트리구조?

     • 트리구조를 채택하면 좋은 점:

     • 노드에 식별자(id)를 달면 수정한 셀의 정보를 2차원 배열보다 빠르게 탐색해 알 수 있음

     • 수정한 부분에 대한 상태관리를 해당 노드들만 들고 있다가 서버로 보내면 됨.

     • 노드에 추가적인 라벨을 붙이면 서버와 합의한 액션 관리 및 지정도 쉽게 할 수 있을 것

     • 그 외에 채택할 수 있는 방식:

     • 해시 테이블?

[연결부]

• FE 의 Cell Data의 action trigger를 BE에서 설계함
• 3차원 데이터를 렌더할 수 있어야 함(3차원 ↔ 2차원 변환기 제작 필요)
• FE는 템플릿화하여 데이터 흐름 제어를 BE로 넘김

[BE]

• 오더 변경 기록 및 롤백 기능 메커니즘

  • 오더 테이블 구조 수정

    • 기존에 오더 상세에 있는 내역들을 order_details 라는 테이블로 만들어서 매핑으로 수정

  • 오더 수정 메커니즘 수정

    • 기존에 오더 수정방식에서 신규 로우를 생성한뒤 기존 로우와의 매핑을 끊는방식으로 수정

  • 히스토리

    • 오더의 수정 내역의 index를 쥠

  • 롤백

    • 오더 수정시 기존 index를 체크해서 다시 이어주는 방식
    • 이렇게 진행하면 롤백 후에도 변경 이력이 남음

• 자동저장

  • 시스템의 특성 및 설계구조상 자동저장은 모두 서버가 처리

  • 기존 데이터와의 변경 내역과 search, filter, sorting의 조건들을 함께 서버에 저장

  • 절대 전체 값이 아닌 변경에 대한 특정값만 넘김

  • 저장 이력 등을 비교해 자동저장 내역이 있는지 판단해 사용성 개선

• Search, Filter, Sorting

  • 현재 개발된 Filter, Sorting에서 필터 갯수 확장 및 Only And조건에서 쿼리처럼 입력 가능하도록 필터 기능 강화

• Setting Custom Column

  • 화주별, 개인별 여러개의 column set을 만들고 관리 가능하도록 설정
  • 업무의 효율성을 높히는데 집중

• 그외

  • container, po 매칭 API 기능
  • etc.

[추후 논의 필요]

• 수정/삭제/추가 등 API 설계 필요

• 라이브러리 선정 후 서버-클라간 데이터 구조 확립 후

이제 내가 고민해야하는 것:

• 2차원 그리드에서 아무 셀이나 클릭했을 때 클릭한 셀의 메타정보를 인식하는 기능이 필요
  • 걸림돌: 그리드에 데이터를 펼칠 때는 데이터의 위계 정보가 해체된 채 각 셀이 동등한 지위의 위계를 가지는 1-level 데이터로 초기화됨. 단지 그리드에서 알 수 있는 유일한 정보는 해당 셀이 소속된 행의 정보.
  • 그렇다면 좌측부터 우측으로 데이터의 위계가 펼쳐지면서 모든 데이터가 최상단 위계의 정보를 필수적으로 가진다고 가정하면(첫번째 열이 PK), 셀이 소속된 행의 첫번째 열의 노드 정보만으로 클릭된 셀이 소속된 트리가 무엇인지 검색할 수 있음(O(n)).
• 여기까지는 완료.
• 그럼 서브 트리를 구별할 수 있을 때 이를 어떻게 그리드에서 시각화해줄거냐?
  • 서브 트리에 속한 자식 노드들에 모두 같은 Key를 삽입해야하나?
    • → 같은 key를 쥐어주면 그리드에서 하이라이팅할 땐 해당 키를 가진 셀들만 '계산'해서 칠해주면 됨.
    • → 근데, 서브 트리에서 위계에 상관없이 모두 같은 key를 가지고 있으면 수정할 땐 특정 노드의 메타정보를 어떻게 알지?
    • → 소속 트리뿐만 아니라 정확한 노드의 메타정보를 알려면 노드별 고유식별자도 있어야겠다. 이게 있어야 서버로 보낼 때 수정한 노드들만 보낼 수 있음
    • → 그러면 노드별 고유식별자는 어떤 규칙으로 생성해야하나?
    • → 레벨별로만 구분을 짓는건 부족한 것 같다. 아예 각 "컬럼 이름 + 레벨"의 나열로 키를 만들까?
    • → 이렇게 하면 나중에 오더기준이 아니라 PO나 Container 기준에도 대응할 수 있다
    • → 하지만 컬럼이름+레벨 은 컬럼 재정렬과 궁합이 좋지 못하다(컬럼 재정렬하면 레벨이 자주 바뀌니까 key를 자주 바꿔줘야함)