일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- Recoil
- augmentedDevice
- Failed to compiled
- Can't resolve
- rolldown
- dvh
- camera access
- react-native-dotenv
- animation
- electron-packager
- nextjs
- ffi-napi
- github 100mb
- react-native
- adb pair
- github lfs
- 티스토리 성능
- github pdf
- Git
- 이미지 데이터 타입
- silent printing
- npm package
- Each child in a list should have a unique "key" prop.
- ELECTRON
- camera permission
- device in use
- adb connect
- custom printing
- html
- vercel git lfs
- Today
- Total
목록Javascript (57)
Bleeding edge
https://dalaranl.github.io/react/redux-mobx-context/ 상태관리 라이브러리의 장단점 정리 상태관리 라이브러리는 여러가지가 있다. 각 라이브러리의 장단점을 알아보자. dalaranl.github.io

사용하게된 이유 사용자에게 원하는 타입의 값을 받아서 처리를 한다고 하면, 두 가지 방법이 있다. 1. validator를 이용해서 원하는 값이 나오지 않는다면 사용자에게 다시 값을 입력하라고 알린다. 2. 원하지 않는 값이 나온 경우에 input에 값의 입력을 받지 않는다. 이번에 적용해야할 기능은 2번이었다.(물론 1번도 부분 적용..) 이번에 적용해야하는 것은 숫자와 %였다. input vs contentEditable View적인 차이 input은 value의 하나의 textNode에 대한 스타일링을 적용할 수 있지만 contentEditable은 innerHTML을 이용하여 다양한 태그를 감쌀 수 있기에 다양한 스타일링이 가능하다 코드에서의 차이 input은 type을 입력하여 의도되지 않은 타..
onKeyDown, onKeyUp onKeyDown은 키를 누르고 있을 때, onKeyUp은 키를 누르다가 뗐을 때의 키보드 이벤트 함수이다. 이렇게 누르고 있을 때와 누르다가 땠을 때로 구분하니 종종 둘이 언제 사용해야하는지 헷갈리는 경우가 많았다. 그래서 순서로 생각을 해보기로 했다. 순서 키를 누르고 => 키를 뗀다. 즉 onKeyDown 이벤트가 먼저 발생하고, onKeyUp 이벤트가 발생한다. 또 다른 차이점은 onKeyDown은 여러번 발생하고, onKeyUp은 한번 발생한다라는 차이점도 있지만, 이런 횟수적인 차이보다는 순서적이 차이로 구분하는게 기억하기 좋았다. 언제 구분해야할까? 사실 위에서 무시한 횟수 때문에 구분해서 사용되는 경우도 있지만, 이 같은 경우에는 횟수에 따라 둘 중 하나만..
고민한 이유 최근에 회사에서 채팅로그를 새로고침을 한 경우에는 저장을 하고, 창을 끄는 경우 없애자는 이야기가 나왔었다. 평소에 이런 비슷한 케이스가 있으면 window addeventlistener에서 beforeunload를 이용해서 해결했는데, 문제는 이 방법은 새로고침과 창을 끄는 경우 모두 포함한다. 검색 결과 reload와 close에 대해 검색하다보면 꺼질 때의 position에 따라 처리해라 이런 다양한 글들이 보였었는데,안될꺼같아서 우선 다 제외하고, 둘의 차이에 대해 검색을 하다가 다음과 같은 글을 보았다 https://stackoverflow.com/questions/568977/identifying-between-refresh-and-close-browser-actions Ident..
고민한 이유 Single Page Application을 만들다가, 서버에서 모든 Single Page Application에 대한 초기 정보를 저장하는 것이 너무 부담되어서, Local Storage에서 초기 State를 관리하기로 하였다. 이 문제를 해결하기 위해 만났던 문제들 nextjs에서 localStorage is not defined 이 문제는 nextjs에서는 window가 undefined인 순간이 있을 수 있는 nextjs에서 나올 수 있는 케이스로 해결 방법은 심플하다(단지 언제 undefined 인지 시점을 지정하는게 타이트할수록 번거로울 수 있다..) function App(){ if(typeof window==="undefined") return //...localStorage에..

이 주제를 공부한 이유 개발자 커뮤니티 슬랙에서, 브라우저에서 txt나 zip와 같은 파일을 open할 수 있는 지에 대한 질문이 올라왔다. 이 질문을 읽었을 때 브라우저에서는 로컬에 파일이 접근이 안되지 않나..? 근데 어떤 웹들을 보면 또 접근이 가능하게 구현한 것 같은데? 재밌어 보여서 시작했다.. 접근 방법 1. 파일을 어떻게 열까? 가장 먼저 생각나는 방법으로 window.open을 사용하였다! Not allowed to load local resource: 역시 브라우저에서는, load local resource에 대해 접근을 막고 있었다.. 2. Mdn에서 정의하는 window.open을 보자 MDN의 window.load를 보면 첫 번째 파라미터가 URL or path라는 것을 볼 수 있다..
오늘 문제를 풀다가 queue를 구현해야 풀 수 있는 문제를 만났다. 평소에 queue라는 것을 생각하면, FIFO에 대해서만 생각하고 생각을 끝냈던 것 같다. 먼저 들어가면 먼저 나온다. 그래서 오늘 백준에서 문제를 풀이할 때 queue의 구현성을 먼저 생각하지 못했던 것 같다. queue 언제 쓸까? 아니, queue의 특징을 조금 더 나열하는게 좋을 것 같다. FIFO search bigO(n) insert bigO(1) delete bigO(1) 탐색이 적고, enqueue dequeue가 많은 경우에 사용하기 좋다. 이전에 스택 문제를 풀 때 스택을 구현하여도 불편하지 않았던 이유는 배열을 이용하여 pop을 이용하여도 손쉽게 풀리며 배열을 사용하면, search도 1, pop도 1 push도 1..
이 글은 Vue와 Pinia를 사용하면서.. 시행착오가 많았었는데, 제가 다시 읽고 Pinia를 다시 사용할 때 편하기 하기 위해서 작성한 글입니다. 1. Pinia 생성 main.js import { createApp } from "vue"; import { createPinia } from "pinia"; import router from "./routes"; import App from "./App.vue"; import "./assets/styles/tailwind.css"; const app = createApp(App); app.use(createPinia()); app.use(router); app.mount("#app"); main.js에, router 앞에 createPinia를 사용한다..

요약: 1. 검색 가능한 이름을 써라 2. 함수명은 반드시 동사를 써라 3. 함수의 인수는 3개 혹은 그 이하로 사용해라 4. Boolean 값을 함수에 인수로 보내는 것을 최대한 방지하자 5. 짧은 변수명이나(아무도 이해못하는) 축약어 쓰는 것을 피하자 출처 : https://www.youtube.com/watch?v=Jz8Sx1XYb04&t=51s 1. 검색 가능한 이름을 써라 코딩을 하다보면 랜덤하게 값을 추가해야할 때가 있다. const SECONDS_IN_A_DAY = 86400; //하루의 시간이 몇 초인가 setInterval(functionName, SECOND_IN_A_DAY) 다른사람 혹은 미래의 내가 읽었을 때 특정 변수가 무엇인지를 알게되며, 그 함수가 무엇을 하는지 이해하기 쉽다...