사용자:Jundyo/개발일지?_(r7)

나무마크 파서를 만들고 있음.

옟날에는 오픈나무, 병아리 엔진(?)이라 불리는거 처럼 정규식을 이용하였는데, 컴파일 언어랑[1] 인터프리터 언어[2]의 성능이 비슷한 것을 보고 갈아 엎음.[3]

두 번째 파서는 토크나이징을 하고 파싱을 하려 했는데
]]랑 ]를 구분 못하는 문제가 발생해서 갈아 엎음

세 번째 파서는 파싱 과정을 총 3단계에 걸처서 진행함[* 원래 이러고 싶지 않았는데 우선순위서열정리를 할 마땅한 방법이 생각나지 않음. 성능이 정규식만큼 구려지면 접자. 안되 내 7개월

아 그리고 갑자기 프론트 삘이 돌아서 잠시 버림.

아 그리고 누가 CRATES.IO에서 namumark 먹었던데 뭘 먹어야할까난...

그리고 if문. Namumark에 비해 파싱이 쉬울듯. 파서를 따로 만들어서 하는 것이 좋을듯함. [4]

AST만 뽑는 크레이트로 만들 생각이기 때문에 렌더링은 Fe에서 할 예정.

오늘 Forge 모드를 처음 만들어봤는데[5] 친구랑 자원낭비 마크 모드를[6] 1.18.2로 포팅 한 버전을 원활하게 진행하려 쇼츠에서만 보던 엔더막대랑 피스톤으로 복사하는거 만듦.[7] 쇼츠에서만 보던거를 실제로 보는데, 이질감이 안들었음.

그래서 결론:오늘은 게임만 하였다.

어... 웬지 모르겠지만 리버티, 부마에서만 정상작동함.

Wiklim[8]에서는 작동 안하는 버그 발견 plugin이 <Nuxt>를 리버티, 부마는 <Nuxtpage>로 치환하는 과정이 일어나서 그런듯. 그런데 Wiklim을 쓰면 Nuxt3 대응하니까 플러그인 레벨에서 치환을 안함. => 뭔가 랜더 시 데이터의 부족으로 문제 발생?으로 추정.[9]

Middleware 단에서 하면 안되는 이유:스킨이 먼저 반응함 + page 다운로드 중에 바뀌면 기존 UI가 고장남.

plugin에서는 router.afterEach로 구현. 분명 리버티에서는 잘 됐음.신계념 스킨얶까 위키엔진 내 생각에는 page가 store를 접근하기 전에 실행해야 함. 그 타이밍 전에 적용시키는 것이 중요함

Lifecycle hooks를 후킹해서 page:start에 추가하면 됨

UI재탕함