라이브 작성 블록 렌더링과 발행 시각 보정
This commit is contained in:
@@ -1,5 +1,13 @@
|
||||
# 의사결정 이력
|
||||
|
||||
## 2026-07-02 v1.10.19 — 구조 블록 안의 기본 마크다운도 작성 화면에서 보여 준다
|
||||
|
||||
인용·콜아웃·토글은 문서 안의 보조 구조지만, 내부에 선택지 목록이나 강조 링크가 들어가는 경우가 많다. 공개 화면과 라이브 작성 화면의 차이가 커지면 작성자는 저장 후 결과를 다시 확인해야 하므로, 기본 굵게·링크·색상뿐 아니라 불릿/번호 목록까지 라이브 표시와 저장 왕복을 맞춘다. 다만 복잡한 중첩 블록 편집기는 별도 구조가 필요하므로 이번 범위는 기본 목록과 인라인 문법에 한정한다.
|
||||
|
||||
기본 목록을 라이브 편집용 HTML로 바꾸면 브라우저 DOM의 커서 위치와 실제 저장되는 `- 항목` 원문 줄의 길이가 달라진다. 방향키 이동과 줄 삭제는 원문 줄 기준으로 작동해야 하므로 contenteditable offset 계산도 목록 마커와 항목 사이 줄바꿈을 포함하도록 맞춘다. 공개 토글은 닫힌 상태에서 chevron만 눌러야 하는 구조가 명확하지 않으므로 제목 클릭도 펼침·접힘 트리거로 포함한다.
|
||||
|
||||
게시물을 비공개나 초안에서 공개로 직접 바꿀 때 발행 시각이 비면 공개 정렬과 예약 판별이 불안정해진다. 발행 모달 경로뿐 아니라 상태 셀렉트와 API 직접 요청에서도 같은 결과가 나오도록 클라이언트와 서버 양쪽에서 빈 발행 시각을 현재 시각으로 보정한다.
|
||||
|
||||
## 2026-07-02 v1.10.18 — 미디어 관리는 API 응답부터 나눠 받는다
|
||||
|
||||
v1.10.16에서 관리자 미디어 화면 렌더링은 50·100·200개 단위로 나눴지만, API는 여전히 전체 미디어 배열을 내려줄 수 있었다. 미디어가 수백 개 이상으로 늘면 화면 렌더링을 나눠도 네트워크 payload와 클라이언트 메모리 부담이 남는다. 따라서 미디어 관리 화면은 `paged=1` 응답을 사용해 탭·폴더·종류·미사용·검색 조건이 적용된 현재 페이지 항목과 전체 개수 메타만 받는다. 글쓰기 이미지 선택과 대표 이미지 선택은 원본 전체 선택 흐름이 아직 필요하므로 기존 배열 응답을 유지해 호환성을 우선했다.
|
||||
|
||||
Reference in New Issue
Block a user