Bleeding edge

1. 업데이트를 한 이유create-convention는 작년에 회사에서 새로운 프로젝트를 자주 시작하다보니, 일일이 convention을 적용하는 것이 너무 번거로워서 이를 줄이기 위해 만든 라이브러리이다. (코드를 보니 그 당시에 라이브러리 만들고 코드 정리도 못하고 올렸었던 것 같다.. 회고가 없음이 그를 보여주는 증거..!) 코드 자체가 js로 작성이 되어있었고, 파일이 하나로 작성되어 있어서 가독성도 너무 떨어져서 수정하였다.2. TS로 변환하면서 추가한 사항들2-1. entry 포인트 수정모든 기능을 index.js에 넣다보니, 기능 구분과 문제가 생겼을 때 원인 파악이 힘들었으며, 함수를 분리하여보기 힘들었다. 그래서 main.ts를 기준으로 기능을 분리하여 수정하였다.2-2. main.ts..

아직 완성된 것은 아니지만.. electron-builder와 github action 을 이용하여 배포 세팅을 마치면서, 이전에 electron-forge로 거의 2~3주정도 시간을 썼던 것이 기억나면서, 이전보다 정말 많이 늘었다는 생각도 들었고, 이 프로젝트를 만들면서 이전에 타입스크립트로 리팩토링을 진행하려고 했었지만, 실패했었던 것이 기억났다. 아무래도, 이전에 react-wai에서 파일 번들링을 이해를 못하고 사용해서 그런지 tsc에 대해서도 제대로 이해를 못하고 수정을 잘못했던 것 같다(+타입에 대해서도 잘 못다뤘던게..) 지금 일단은 태그로 업데이트를 해두었지만, 아마 3개정도를 업데이트하고 augmentedDevice 레포는 readable로 돌리고 새로운 레포로 다시 시작할 것 같다. ..

간만에 Notion Prettier를 업데이트 하였다. 이번에 새로운 기능을 추가를 위하여 테스팅을 하면서 나도 모르는 버그를 찾았고 이 버그도 같이 수정하였다. (이번 기회에 텍스트 노드에 대해서도 공부할 수 있었다, 이것도 나중에 정리를 해야겠다) 이번에 신규 기능은 백준 에드온이나 다른 사이드에서 사용하지 않았던 contextMenu를 사용하는 부분이 있었고, contextMenu는 내가 생각하던 것과 다른 아키텍쳐를 가지고 있어서 내가 생각했던 시간보다 2시간 정도 더 소모하였다. #1 권한 설정 우선 contextMenu을 사용하기 위해서는 우선 extension의 manifest에서 권한을 열어야한다. { //manifest.json "permissions": ["contextMenus"], ..

벌써 메셔에 들어온지 5달이 지났다. 첫 프로젝트를 마쳤을 때는 굳이 프로젝트에 대한 후기나 회고를 쓸 필요가 없는 것 같아서 노션에만 간단히 메모를 남겼었다. 하지만 두 번째 프로젝트가 끝났을 때 첫 번째 프로젝트가 끝났을 때 내가 부족했던 것과, 어떤 것을 더 개선할지를 메모하고 이전 프로젝트와는 다르게 잘한 것에 대해 메모할 필요가 있다고 생각했다. 첫 번째 프로젝트 Swalo 1. 개인적으로는 Nextjs가 익숙하지 않아서, Nextjs에서 지원하는 메서드들을 제대로 사용하지 못했었다고 생각한다. 2. 피그마대로 컴포넌트를 설계하다가 폴더관리에 실패했다. 3. DTO 변경이 생겼을 때 수정하는데 시간이 너무 오래 걸렸다. 2번은 리팩토링을 통하여 개선을 하였고 1번 같은 경우에는 처음는 부족했었지..

https://allwais.tistory.com/2 로컬에서 npm 패키지 배포하기 서론 react-wai를 보면 이게 배포하면 문제없나? 라고 테스트하기 위해 package.json에서 몇 가지 변경사항만 수정해서 다시 재배포를 한 적이 있다. 사실 이런 설정만 건드리는 것은 publish가 되어서는 allwais.tistory.com (allwais에서 react-wai에 참여한 다른 분들의 개발자 노트도 보실 수있습니다!) 서론 react-wai를 보면 이게 배포하면 문제없나? 라고 테스트하기 위해 package.json에서 몇 가지 변경사항만 수정해서 다시 재배포를 한 적이 있다. 사실 이런 설정만 건드리는 것은 publish가 되어서는 안된다고 생각이 되었지만, 방법을 몰라서 접어두었었다. 최..

이전에 Context API를 선택했던 이유 전역상태를 관리하는 파일을 최대한 가볍게 하고 싶어서, 이미 내장되어있고, 자주 바꾸지 않기 때문에 Context API를 사용 했었는데 지금 고민해보니 굳이 Context API에 대해 다시 한번 고민을 하게 되었다. 다시 고민하게 된 이유 1. 내정되면 가벼운가? 번들링을 이용하면 필요한 함수만 불러 오기 때문에 Context API가 리액트에 있다고 하더라도 Context API를 사용하지 않는다면 Context API는 사용되고 있지 않았을 것이다 즉 Context API를 사용한 것과 만일 바꾸게 될 새로운 전역 변수 함수에 대해서 고민해보면 React(ContextAPI를 제외한 일부) + Context API + BOJ React(ContextAP..

프로젝트를 시작하게 된 계기 Notion prettier는 현재 진행하고 있는 오픈소스 프로젝트 팀원이 노션에 코드를 작성하면서 텝이나 스페이스바를 연타하는 것을 보면서, 노션에 프리티어를 적용하면 어떨까요? 라고 내가 팀원에게 물어보면서 그런게 있으면 당장 쓸 것 같아요 라는 이야기를 듣고나서 시작했다. 프로젝트 이름 정하기 Markdown helper 처음에는 이름이 Markdown helper라는 이름으로 프로젝트를 만들었는데, 다른 사람에게 프로젝트를 설명할 때 프로젝트 이름만으로는 프로젝트를 설명하는 것이 어려워서, 이름으로 프로젝트를 쉽게 설명하는 이름이 없을까 고민하다가 Notion에서 Prettier를 사용하니 Notion Prettier로 하는게 어떨까 하고 변경했다. (지은게 아니라 그..

문제점 자동완성의 keyword의 symbol을 나타내는 폰트에 문제가 있었다. 문제 원인 자동완성이 뜨기 이전까지는 볼 수 없는데.. 이 현상은 con와 같이 자동완성이 가능한 keyword가 있을 때 폰트를 request하면서 문제가 생긴다. 해결책 평범한 web에서는 아마 이러한 문제가 생기지 않았겠지만, chrome extension에서는 내가 웹주소에 폰트를 올릴 수 없기 떄문에 이러한 문제가 생길 수 있다. 이 문제를 node module에 있는 monaco editor에서 찾는다는 것은.. 잘못된 방법이고, 최종적으로 생성되는 파일의 e.exports=n.p+"b797181c93b3755f4fa1.ttf" 이 부분을 수정할 필요가 있었다. 이 파일이 실행될 경로에 자동으로 생성될 텍스트 파일..

리팩토링 기간 2022.10.31 - 2022.11.13 리팩토링을 시작하게 된 계기 얼마 전에 완성한 플로팅 브라우저와 백준의 폴더구조를 비교하였다. 플로팅 브라우저는 기능 별로 파일을 분리하였지만, 백준의 폴더구조는 main.js 단 한개의 파일로 자바스크립트를 가지고 있기 때문에 파일을 수정하기 힘들었다. 그래서 깃허브에서 스타가 많은 크롬 익스텐션을 검색하여 파일을 어떻게 관리하는지 검색하였다. 크롬 익스텐션의 파일 관리 다른 크롬 익스텐션에서는 필요한 manifest.json, styles.css, main.js가 root 폴더에 있는 것이 아니라 src를 기준으로 웹팩 번들링을 하였다. 그리고 필요한 파일을 컴포넌트 별로 분리하여 관리하였다. 리팩토링 목표 및 계획 리액트를 이용하여 컴포넌트 ..