알다가도 모를

vi ~/.gitconfig [user] name = user1 email = user1@gmail.com [credential] # wsl 환경인 경우 helper = /mnt/c/Program\\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe username = user1 [includeIf "gitdir:user2"] path = ./user2.gitconfig # user2.gitconfig [user] name = user2 email = user2@gmail.com [credential] username = user2 지금까지 저장소마다 usehttppath로 삽질한 게 무의미해졌다. 커밋 저자 이름을 바꾸는 건 어쩔 수 없이 경..

Introducing Hooks(번역문)란 글이 있었고 반박으로 The Ugly Side of React Hooks(번역: React Hook의 어두운면)란 글이 나왔으며 그 번역문을 보고 작성했습니다. 훅에 관한 건 요새 뜨거운 감자로 보입니다. 이걸 도입하는 게 타당한 트레이드인지 따지기 어렵다는 방증으로 보입니다. 훅에 맘에 안 드는 점이 있긴 한데 까더라도 제가 까고 싶어서 올려봅니다. 글쓴이가 훅을 잘 서술했다고 생각하지 못했거든요. 언젠가 봤다가 언어장벽으로 반 정도 읽다가 말았는데 역자분의 고생을 생각해봅니다. 이유 1: 클래스는 헷갈린다 hook 함수는 클래스가 아니며, 함수와 클래스의 그 중간 어딘가에 있는 것이다 타당한 지적입니다. 훅은 그 자체로 필요한 제반 지식이 상당하고 언어 차원..

원문, 번역문 목mock이 안 좋다는 인식은 알고 있었어도 그게 단순히 목 라이브러리를 쓰지 말라는 이야기는 아닐 거란 생각에 제대로 알아보는 차원에서 검색해보았다. 그리고 나도 테스트를 제대로 활용하고 있는지 의구심도 들었기에. TDD로 더 나은 디자인을 이끌어내야 한다 DI는 목을 가져온다. 하지만 DI 없이도 분리된 코드를 짤 수 있다. 코드 커버리지를 무작정 늘리는 것은 프로그램 코드를 복잡하게 만들어 더 많은 버그를 도사리게 한다. 이 소제목 이전의 내용이 목이 필요하다는 건 추상화 표면, 즉 코드를 사용하기 위해 알아야하는 지식이 너무 많은 걸 의미해서 좋은 설계가 아닐 수 있다는 듯. 때문에 독립적인 유닛 테스트에 목킹이 필요하다는 건 사실 그 유닛이 독립적이지 않다는 걸 의미할 수 있다고...

로딩 스피너 컴포넌트를 만들 때 고려할 점, 가능한 방법을 생각해 보았다. 이중 제출 방지 submit 버튼을 두 번 눌러 요청을 중복하는 걸 방지해야 한다. div를 늘려 오버레이하는 게 가장 간단해 보인다. 더 철저하게 하자면 axios 사용 층에서 배타적으로 요청하는 유틸리티를 추가할 수 있을 듯하다. 서버도 결국엔 CSRF 토큰을 사용하게 될 텐데 이것도 이중 제출 문제를 완화할 수 있을 것으로 보임. 재활용 방법 비교 MobX 현재 사용 중이고 간단함 단점을 들자면 라이브러리 의존성 @inject('applicationStore') @observer class SubmitForm extends React.Component { showLoading() { this.props.applicationS..

최근 참여한 프로젝트에서 리액트를 사용하고 있고 관습으로 클래스 컴포넌트를 사용하고 있었습니다. 저는 리액트 훅을 최근에 알게 되어 그걸 사용하고 싶었고 그 장점을 소개할 기회를 얻었습니다. 훅Hook은 무엇인가? 상태와 생명주기에 엮인 부수효과를 관리하는 새로운 방법입니다. 즉 기존의 this.state와 componentDidMount()등의 사용을 대체합니다. 믹스인, HOCHigher order component를 대체할 수 있습니다. Redux, MobX와의 관계는? 거의 별개라고 할 수 있습니다. MobX와 Redux 둘 다 상위 컴포넌트에서 스토어라는 트리 범위의 상태를 관리합니다. 이건 리액트에선 컨텍스트를 통해 관리할 수 있고, 훅의 useContext를 통해 컨텍스트도 접근할 수 있으므..

https://gist.github.com/rambabusaravanan/1d1902e599c9c680319678b0f7650898 유용한 .gitconfig 파일을 발견했다. 내용인즉슨 IntelliJ의 diff GUI를 diff, mergetool로 쓰게 해주는 설정이다. IntelliJ의 diff 툴이 편리하다는 건 알고 있었지만, 곧바로 적용가능하다고는 기대하지 않았는데, 가능했다. 창을 띄우는 데까지 걸리는 시간이 상당하지만, 특정 상황에서는 감수할 만 하다. 번역 작업을 할 때, 원본 파일에 변경이 생기면 원본의 변경을 다시 번역해야 한다. 이 때 번역이 완전히 바뀌는 일은 별로 없으므로 바뀐 부분, 즉 C0 → C1으로의 차이점을 C2에 반영해 C3를 편하게 만들 수 있다.

찾은 곳 ListBox는 개별 아이템을 ListBoxItem으로 감싸는데, 그 ListBoxItem의 Template을 스타일로 건드려서 감싸는 부분을 수정할 수 있다. ItemsControl로도 가능할진 모르겠다. WrapPanel을 감싸려했는데 Template이 없다고 안 되고..

sequence { runBlocking { ... } }을 어떻게 못하나 싶어 왜 제한이 필요한지 찾아봤다. @RestrictsSuspension 등 설명은 이 링크만 보면 파악할 수 있다. 내 생각엔 스레드 전환같은 게 없이 Continuation 저장, 불러오기만 사용하고 싶을 때 쓰는 듯 하다. 이 목표를 사용할 수 있는 suspend 함수를 제한하고 원래 코루틴 문맥에서만 호출할 수 있게 해 달성한 것 같다. 같은 문서에서 찾은 대안으로는 suspendingSequence라는 게 있었지만... Channel로 대체된 듯 하다.