(번역) 자바스크립트를 두 개의 언어로 분리해야 할까요? 구글이 주도하는 새로운 제안에 대해 의견이 분분합니다.

• (번역) JS0/JSSugar 제안에 대한 생각
• 최근에 자바스크립트를 두개로 분리한다는 😯 이야기가 들려왔다
• 대부분의 새로운 기능이 자바스크립트 엔진이 아닌 툴에 구현되도록
  • 실제로 내가 사용하게 될 가능성은 낮지만
  • 실제 런타임 엔진에 의해 구현되는 코어 JS0
  • 툴을 통해 구현된 언어 JSSugar
• 타입스크립트를 컴파일하여 자바스크립트로 변환되는데
  • JSSugar가 자바스크립트가 되고
  • 런타임 엔진은 JS0를 읽으면 되는 것이다
• 그럼 JSSugar 와 JS0 로 분리된다면
  • JSSugar 는 JS0 에서 지원하는 API 를 호출할 수 있도록
  • 각각의 환경 (컴파일 되었어야하는) 에서 적절히 구현해주어야한다
• 이러한 것들이 오히려 불편함을 초래할 수 있다
  • 어떠한 툴에서는 지원하지 못하는 JS0 API 가 있을 수 있기 때문이다
  • 지금은 컴파일을 어떻게 하느냐에 달라지지만
  • 이제 툴에 의존하게 되는 것
  • 런타임 엔진은 보안, 안정성을 잡을 수 있었으나 툴에 대한 의존성이 높아진다는 의견

[책] AI 트루스

• 이 책을 읽어볼까 관심을 가지고 있었는데
• 이 책을 읽어본 사람들의 글을 보니 읽어야겠다는 확신이 생긴다
  • 인간이 고속도로를 만들기 전에 동물에게 그래도 되는지 질문하지 않는 것처럼 인공지능은 가까운 장래에 고속도로와 비슷한 무엇을 인간에게 묻지 않고 만들 가능성이 높다.
  • 진짜 가치는 문제를 해결하는 것이다
  • 당신을 대체하는 것은 인공지능이 아니라, 인공지능을 활용하는 다른 사람이다.
• 내가 갖고 있지 않은 것
  • AI 를 활용하는 것
  • 그 이전에 AI 에 대한 관심
  • 인간의 생존을 위협하고 있는 건 AI가 아니라 인간 자신이다

BlackCandy - 셀프 호스팅 음악 스트리밍 서버

• 이런 방법이?!

[번역] useEffect를 남용하지 마세요!

• 부제: 리액트의 불필요한 리렌더링을 줄이기
  • 이 훅은 데이터 가져오기, 구독, 직접 변경 등을 포함한 외부 요인/서비스와 컴포넌트를 동기화시킬 수 있지만, **아주 쉽게 남용되기도 합니다.**
• 경쟁 상태 > 클린업 함수 사용하여 해결
• 데이터는 폭포수처럼 (부모에서 자식으로) 흐르도록 처리
• 한번 호출되어야하는 경우
  • 최상위 플래그나 앱이 마운트 되기 전에 미리 호출하도록
• 언마운트된 컴포넌트에서 상태 업데이트를 요청한 경우
  • 경고 문구가 노출되어 항상 언마운트 상태를 체크 할 수 있도록 했었는데
  • 제거 되었기 때문에 불필요하게 로직을 수정하지 않아도 된다

Flutter 클린 아키텍처: 작은 앱부터 대규모 프로젝트까지 맞춤 설계

• 클린 아키텍처라고 하면 벌써 어려운건 아닐까
• 무언가 도입하기 위한 장벽이 있지 않을까 고민되는데
• 나의 방식에 맞춰서 생각해본다
• 첫 번째 아키텍처
  • View 하나에서 단순하게 State, Model 모두 처리한다
  • 서버로부터 데이터도 가져오고 화면에 그리고 중간에 변경되는 상태도 반영해야한다
  • 로직이 복잡해질수록 관리하기 어려울뿐만 아니라
  • 변경된 화면을 테스트 하는데 데이터를 가져오는 것부터 테스트 되어야하는 문제가 있다
• 두 번째 아키텍처
  • 위에서 발생한 문제를 해결하기 위해 화면과 데이터를 분리한다
    • Component와 Container로 분리하였다
  • 화면이 많아질수록 중복된 기능이 생겨날수록
  • 데이터 동기화나 로직 관리에 어려움이 발생한다
• 세 번째 아키텍처
  • 중복된 로직, 데이터 동기화를 처리하기 위해 Repository 를 구현한다
    • useQuerySelector 처럼 데이터에 접근하고 처리하는 곳을 둔다
  • 구현체를 바꿔가면서 테스트해야하는 경우
  • Repository 를 필요에 따라 다시 작성해야한다
• 네 번째 아키텍처
  • Repository를 인터페이스와 구현체로 분리하여 변경사항에 대처한다
  • View 에서는 인터페이스를 참조할뿐
  • 구현체에서 실제로 어떻게 동작하는지 의존성이 줄어들기에
  • 이에 필요에 따라 구현체를 바꿀 수 있다
    • build 에서 처리한다
  • 하지만 도메인 레이어의 Entity 와 데이터 레이어 Model 이 달라진다면
  • 구현체에서 참조하는 모델을 바꿔야하기에 모두 재작성이 필요해진다
• 다섯 번째 아키텍처
  • 모든 사용처에서 수정하는 것보다 이를 일괄 처리할 수 있는 중간이 있도록 두는 것이다
    • select 에서 처리한다
• 여섯 번째, 최종 아키텍처
  • 이러한 Repository 가 많아지는 경우 어떤 것을 참조할지 헷갈리는 상태가 된다
  • 유즈케이스에 따라 사용되는 Repository 들을 묶어둔다
    • 커스텀 훅에서 처리한다
• 아키텍처 단계별로 문제점을 해결하기 위해 각각 다음 단계로 나아간다
  • 비즈니스 로직과 데이터 접근, UI 코드가 명확히 분리돼 각 모듈을 독립적으로 변경할 수 있고, 테스트 작성이 용이해진다