server response를 그대로 소화하는 Grid
그리드 사용성 고민
type
- server given columns, rows와 grid 컴포넌트에서 쓰기 위한 type의 적절한 네이밍 필요
- 분리하기가 약간 애매한 부분 있음. query 레이어에서 server given의 냄새를 다 지워버리면 좋은데, column definition의 과정에서 hook이 사용되면 server ↔ queries ↔ column definition 세 단계가 되어버려서 필요 이상으로 복잡해짐
- hook을 빼버리기?
- query 레이어에서 dynamic options를 resolve하는 구조가 구현 가능?
- 분리하기가 약간 애매한 부분 있음. query 레이어에서 server given의 냄새를 다 지워버리면 좋은데, column definition의 과정에서 hook이 사용되면 server ↔ queries ↔ column definition 세 단계가 되어버려서 필요 이상으로 복잡해짐
- 역할 분배가 불명확하게 된 것이 지금 grid type들의 혼란을 부추기고 있음
- GridRow, useGrid의 Grid, 컴포넌트로써의 Grid, 등등으로 너무 복잡스
schema
- 동적 타이핑에 zod를 활용하기 (data explorer 참고)
- 다뤄지는 value에 대한 처리를 grid 패키지로 지금보다 더 이관하자 (개별처리 복잡도 아직 많음)
기타
{ meta: {}, cells: {} }이 형태를 고집해야하나? cells에 key 기반으로 접근하는 게 너무 타입추론을 어렵게 하고, 고통스러움- column definition 단계까지만 cells에 대한 정의를 가져가고, row 단계로 내려오면 extract된 values로 가볍게 사용할 수는 없나? (동적 editable등 풀어야하는 사용예 있음)
- server에서 제공하는 meta가 예상보다 비일관적임 . 다시 풀어야