개요프론트엔드 개발을 막 접했을 시점에 VScode에서 이런 경고 문구를 보게 되었다. ▼ JS에 대해 잘 모르기도 했고, 애초에 ES 모듈이 뭔지 그리고 CommonJS 모듈이 뭔지도 몰랐기도 하고 잘 동작하기에 그냥 넘어갔었다. 그런데 이런 사소한 것들을 그냥 지나치면 나중에 큰 문제가 될 수 있을 거 같아 한 번 찾아보면서 정리를 해봤다. CommonJSCommonJS란 CommonJS는 Node.js의 초기 모듈 시스템으로, 모듈을 로드하고 관리하기 위해 설계된 시스템이다. 주로 서버사이드에서 사용이 된다. 상당히 레거시한 느낌이 강하지만 Node.js 생태계 전반에서 사용되고 있으며 많은 라이브러리에서 지원이 된다. (개요에서 필자가 뭔지도 모르고 썼음에도 동작할 수 있었던 이유다.) Commo..

문제 상황 TabBar를 이용하여 한 페이지에 여러 개의 뷰를 보여주는 UI는 거의 대부분의 앱에서 사용될 정도로 흔하다. 일반적으로는 고정된 개수의 TabBar를 사용하기에 스크롤 할 일이 없는데, 때로는 여러 개의 TabBar를 두어 스크롤이 들어가기도 한다. 그런데 스크롤을 넣기 위해 `isScrollable`을 `true`로 바꾸면 사진과 같이 왼쪽에 의문의 Padding이 들어가게 된다. ▼ 왜 이 빈 공간이 생기는 것이고, 어떻게 하면 제거할 수 있을까?  원인과 해결원인 원인은 `TabAlignment`에 있다. 사진의 설명에 나와있듯, 만약 TabBar의 `isScrollable`이 `true`가 되면 TabBar는 기본적으로 52pixel의 offset을 갖게 된다.  정확히는 `isSc..

📖 오늘의 학습계기 메소드 안에 메소드를 작성하는 문법은 요즘 대부분의 언어에서 지원하는 문법이다. 하지만 일반적으로 이를 사용하지 않아도 대부분의 기능들은 충분히 구현이 가능하며, 이를 잘못 사용했다가 가독성만 안좋아지고 소통이 안 될 가능성이 있어서 그동안에는 잘 사용하지 않았다. 그러던 도중 이를 유용하게 사용할 상황을 마주했다. 유용하게 사용할 수 있는 상황 작업이 끝난 뒤, 작업에 사용된 오브젝트의 id와 state를 다른 컴포넌트들과 동기화를 시켜야하는 상황이 있었다. 모든 컴포넌트들이 listen하고 있다가 알아서 바뀌면 좋겠지만, listen을 설정해주는 작업을 해주는게 더 크기에 순회로 비교하며 값을 바꿔주기로 했다.  내가 바꿔줘야하는 데이터 리스트는 총 4개, 모두 같은 타입이다. ..

📖 오늘의 학습  현재 프로젝트는 클린 아키텍쳐로 진행이 되고 있다. 클린 아키텍쳐에서 원하는 모든 것을 따르진 않지만, 전체적인 틀은 지키려고 한다. ▼ 현재 구조는 대략 이렇다. entities(request dto, response dto) -> api repository -> usecase -> controller -> presenter 모델을 먼저 선언하고 레포지토리에서 이를 사용하여 API를 호출하는 메소드를 정의한다. 그리고 이를 usecase화 시켜 컨트롤러에 뿌리고, 컨트롤러는 이를 사용하여 데이터를 받아온 다음 프레젠터로 전달한다. 굉장히 이상적인 구조로 프로젝트가 설계되어있는데, 여기에 몇가지 문제점이 존재했다. 바로 response, request dto의 통일성 문제와 useca..

📖 오늘의 학습JSON의 배열 원소로 null이 온다면 JSON 파싱을 할 때, 일반적으로 리스트에 `null`값이 들어올거라고 생각을 안한다. 애초에 `null`이라는 값이 없다는 것인데, 없으면 안보내면 되는걸 굳이 보낼 이유가 없다. 그렇기에 대부분 배열 자체가 `null`로 오는 것을 체크하지, 배열 내부의 원소가 `null` 인걸 체크하지 않는다. 일반적인 경우 연산 낭비이기 때문이다.  그런데 `null`이 배열 원소로 온다면? '뭐 `null`이니까 적당히 공백 데이터로 파싱한 뒤 넘어가지겠지' 라고 생각했었는데, 아예 예외를 날려버렸다. 그 이유는 형변환 에러. `null`을 `String`이나 `int`, 혹은 내가 정의한 타입으로 변환할 수 없기에 생기는 예외다. `null`은 그 어..

📖 오늘의 학습제목에는 괴랄한이라고 적어놨지만, 사실 그렇게 괴랄한 구조는 아니다. 하지만 보통은 예상하기 어려운 구조로 전달을 받았다. 일반적으로 생각하고 그리고 바라는 JSON 구조는 약간 이런 식이다.{ "key" : value} 그러나 이번에 내가 받은 구조는 이런 식이었다.[ "string", "string", "string"]  이런식으로 들어오지 않는다고 암묵적인 약속을 받고, 전체적인 시스템을 짜놓고 개발을 하고 있었는데 이렇게 약속과 다른 형태로 넘어오니 조금 당황스러웠다. 이래서 백엔드랑 소통을 잘해야한다고 하는거구나를 정말 뼈저리게 느꼈다. (근데 저번에 이렇게 주지 말라고 했는데 계속 이렇게 주면 내가 뭘 할 수 있는게 없다...)  원래 시스템에서는 json을 `Map`으..

📖 오늘의 학습이번엔 구글 지도를 연동해 주변 정보를 가져오는 기능을 만들어봤다. 지도 API는 몇 번 써보긴 했는데, 사용자가 지도를 움직일 때 마다 근처의 장소 정보들을 패칭해 오는 것은 처음 해보는 터라 걱정이 좀 있었다. 그러나 패키지를 사용하니 별 거 아니게 되었다... 우선 전체 코드는 아래와 같다. notifier(컨트롤러)에 대부분의 로직이 담겨있어서 대략적인 기능만 알 수 있다. ▼더보기GoogleMap( initialCameraPosition: const CameraPosition( target: LatLng(37.56, 127.0001), // 초기 위치 (서울 중심 좌표) zoom: 16.0, ), ..

📖 오늘의 학습개발을 하던 도중, Html을 렌더링을 해야하는 상황이 생겼다. 이 부분은 flutter_widget_from_html이라는 패키지를 이용해서 큰 힘을 들이지 않고 구현을 했으나, 문제가 하나 있었다. 바로 CustomScrollView의 Lazy Loading이다. Lazy Loading은 화면에 보이는 영역에 가까운 위젯만 동적으로 생성하고, 화면에서 벗어난 위젯은 자동으로 폐기시킨다. 문제는 html 패키지가 html을 파싱 하고 태그에 맞게 위젯으로 변환하여 보여주는데, 거기에 있는 사진들도 새롭게 렌더링을 한다는 것이다. 사진이 몇 개나 있을 지, 그리고 사진 크기가 어떻게 될 지는 해당 패키지 입장에서 전혀 모르기 때문에, 높이는 전부 렌더링 한 뒤에 정확한 값을 갖게 된다. ..

📖 오늘의 학습 오늘은 RestAPI 명명법에 대해 생각을 해봤다. 회사에서 백엔드 팀과 논의하는 과정에서 RestAPI URL은 어떻게 할 지가 안건으로 나왔다. 사실 그동안에는 프론트엔드 입장에서 RestAPI 명세는 헷갈리지만 않으면 되는 문제라고 생각을 했었는데, 오늘 다시 생각해보니 그러면 어떻게 해야 안 헷갈리게 할 수 있을까 하는 생각이 들었다.  뭐든 그렇겠지만 각자의 입장에서 편한 부분이 존재한다. 백엔드는 백엔드의 관점에서 편한 부분이 있고, 프론트엔드는 프론트엔드의 관점에서 편한 부분이 존재한다. 너무 한쪽이 편한대로만 하는 것도 문제인데, 그것보다 더 큰 문제는 서로서로 괜찮다고 상대의 요구만 들어주는 것이다. 일종의 배려라고 할 수 있지만, 이게 반복된다는 것은 주관이 없다는 것..

📖 오늘의 학습지금까지의 개발: View 레벨의 상태관리 지금까지의 Flutter 개발을 할 때에는 View 단위로 개발을 하곤 했었다. 상태관리를 View 레벨로 정의를 하여, 내부의 위젯들에 변화가 생기면 전체를 리로드 하는 방식으로 개발을 했다. 이게 권장 사항은 전혀 아니지만, 나름의 장점이 존재한다. View 레벨 상태관리의 장점 View 레벨로 상태관리를 할 때의 장점은 개발이 굉장히 빠르고 간편해진다는 것이다. 그도 그럴 것이, 위젯 각각이 상태를 가지는 것이 아니라 페이지 하나가 상태를 가지고 그 상태를 해당 페이지 내에서 공유를 하는 방식이기 때문이다. 중앙 집중 방식이기에 이해도 쉽고 코드 짜는 것도 간편해진다. 일종의 MVC 패턴의 성격을 보인다. View 레벨 상태관리의 단점 그러..