우분투의 패키지매니저 apt 를 이용해서 Nodejs를 설치 할 수 있기는 하다. 그러나 최신 버전이 아니라 우분투 팀에서 마지막으로 테스르를 완료한 버전(현재 글 작성 시점에서는 8.x.x)을 설치돼서 자바스크립트에서 Optional Chaning으로 짠 코드가 컴파일 되지 않는 문제가 있었다. 그래서 apt 말고 다른 방법으로 설치해야한다.
여러가지 방법이 있겠지만 가장 좋은 방법은 nvm(node version manager)를 쓰는 것 같다. nvm을 사용하면 다양한 노드 버전에서 설치가 가능한데 최신 버전도 물론 설치가 가능하다.
여기서 추가한 jitpack 주소는 추가하려는 오픈소스 라이브러리를 저장하고 있는 저장소다. jitpack은 안드로이드, JVM 형태의 오픈소스 라이브러리 배포 플랫폼이다. 추가하려는 오픈소스 라이브러리 뿐만 아니라 깃허브 프로젝트에 올라온 오픈소스 프로젝트들을 저장하고 있으며 프로젝트에서 사용할 수 있게 jar, aar 형태로 빌드한 상태로 받을 수 있다. 깃헙으로 오픈소스를 배포하고 싶은 개발자 입장에선 쉬운 배포 툴이고 깃허브뿐만 아니라 BitBucket, GitLab, Gitee, Azure 같은 저장소에서 올린 오픈소스 프로젝트도 연동이 가능하니 개발한 라이브러리르 전세계 유저한테 배포하고 싶을땐 jitpack이 가장 좋은 옵션이 될 것 같다.
안드로이드 개발중 Gson과 Retrofit을 이용해 Json 데이터를 주고 받을 때 이런 에러를 보게 되는 경우가 있다
Caused by: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BEGIN_ARRAY at line 1 column 15 path $.documents
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:224)
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129)
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220)
이 에러는 서버로 부터 전달 받은 타입과 내가 예상한 타입이 맞지 않아서 발생하는 문제다. 특히 위 에러는 나는 Object가 올것으로 기대 했는데 실제 데이터가 배열인 경우다. 아래 코드를 보면 나는 검색 결과에 대한 클래스에서 documents 인자를 하나의 오브젝트로 받고 있다.
그런데 실제 서버로부터 응답은 documents는 하나의 오브젝트가 아니라 배열로 날라온다. 클라이언트에서 기대한 데이터 타입이 달라서 발생하는 에러다.
{
"documents": [
{
"authors": [
"전석"
],
"contents": "주식투자의 성공 요소 중 중요한 것은 바로 수익을 낼 수 있는 종목을 볼 줄 아는 눈을 갖는 것이다. 지금 상승하거나 혹은 상승을 준비 중인 종목들이 본격적으로 상승하기 전에, 세력은 어쩔 수 없이 흔적을 남기게 된다. 『개미대학 세력의 매집원가 구하기』는 그런 종목을 구별해 낼 줄 아는 능력을 키울 수 있게 한다. 처음 기술적 분석을 공부하다가 힘들다고 포기하는 부분이 바로 '캔들과 거래량'인데, 이것을 실전에 적용하려면 암기가 아닌 원리의 이해가",
"datetime": "2017-0
네트워크 디버깅으로 Stetho 라이브러리와 chrome://inspect 를 이용하곤 하는데, 안드로이드 스튜디오의 Profiler를 사용해도 동일하게 네트워크 디버깅을 할 수 있다. Stetho를 오래 사용하는 경우에 안드로이드 스튜디오랑 연결된 디바이스가 끊기는 문제가 있었는데 이 방식을 이용하면 끊길 염려 없이 사용할 때 더 간편하다. 이번 포스트에서는 Profiler를 이용한 네트워크 디버깅 방법을 간단히 소개한다.
1. Profiler 실행
View -> Tool Windows -> Profiler 로 Profiler를 실행한다.
2. 프로파일링할 프로세스 선택
현재 연결중인 디바이스에서 디버깅할 앱 프로세스를 세션으로 추가한다. 당연한 얘기지만 앱은 debug 모드로 빌드해야 프로파일링 할 수 있다. 선택을 하면 프로세스의 CPU, Memory, Network, Energy 사용량을 시간 순서로 볼 수 있다.
3. 네트워크 프로파일링 선택
그래프에서 네트워크를 선택하고 앱에서 네트워크 요청을 보내보면 아래 그림처럼 파란 직선 그려진 트래픽을 볼 수 있다. 마우스를 이용해 파란색 직선 영역을 블록처리해보면 해당 구간에서 주고 받은 네트워크 요청 목록을 볼 수 있다.
4. 네트워크 디버깅
디버깅하려는 네트워크 요청을 클릭해보면 오른쪽 탭에 상세 요청과 응답을 볼 수 있다. Body가 Json 형태인 경우 깔끔하게 그려준다. chrome://inspect에 비해 좋은 점은 Body에서 에디팅이 쉽다. chrome의 경우에는 복사를 하는 경우 디버깅 화면이 꺼지는 버그가 있었는데 Profiler를 사용하면 이런 버그가 없이 일반 코드에서 에디팅 할 때랑 똑같다.
현재 서버 애플리케이션 플랫폼의 큰 두 축은 Spring Boot 와 Node.js 인것 같다. 각각의 플랫폼마다 고유한 장점이 있을 텐데 정작 나는 '일하고 있는 곳에서 사용중이다', '요새 이게 트렌드라고 한다'는 이유로 본질을 망각한채 공부만 해왔던 것 같다. 그래서 이번 포스트에서는 spring boot와 nodejs 각각의 장점과 단점을 늦었지만 다뤄 보고자 한다.
Node.js
Node.js하면 자바스크립트로 짤 수 있는 서버 애플리케이션을 가장 먼저 떠오르는데 사실 Node js는 Non-blocking I/O를 처리하는데 최적화된 플랫폼이다. Non-blocking I/O는 다른 작업이 처리되는 걸 기다리는 도중에 다른 작업을 하는 것을 말하며 이러한 형태는 짧은 시간에 여러 작업을 처리할 수 있어 효율적이다. 다른 언어에서도 이런 형태로 구현은 가능하지만 코드가 너무 지저분해지고 구현이 어려운 단점이 있었는데 Node js에서는 비동기식 함수를 통해 코드 상에서 이 작업을 구현하기 간편하게 만들어줬다. 실제로 최근에 만든 사이드프로젝트에서 Non-blocking I/O를 구현하는게 정말 간편했다. 그리고 내부적으로는 하나의 Thread를 이용해서 구현했기 때문에 메모리를 크게 잡아 먹지도 않아 효율적이다. 똑같은 애플리케이션을 돌려도 다른 프레임워크보다 Node.js가 소모하는 메모리의 크기가 적다.
단점은 JavaScript 언어를 사용한다는 점이다. JavaScript가 배우기는 참 쉬워서 적은 시간을 투자하고 금방 숙달을 할 수 있으나 프로젝트 규모가 커지면 커질수록 Type Safe 하지 못하는 점이 한계점으로 작용한다. 언어가 Type Safe 하지 못하면 내가 짠 코드가 별것도 아닌 에러로 런타임에 죽을 수도 있다. 대부분 이 에러는 Java나 C언어 를 사용했다면 빌드 중에 발생하는 컴파일 에러 종류인데 JavaScript는 빌드하는 과정이 없기 때문에 실행 전에 잡아 주질 못한다. 구현하고 서버 실행까지 매우 빠르다고 좋아 할지 모르나 이 사이에 컴파일 오류는 없을 지 꼼꼼히 봐야한다. 그리고 Type Safe하지 못해서 IDE에서 자동 완성이 잘 되지 않는다. 프로젝트가 커지면 커질수록 리팩토링을 하거나 기존 코드를 써먹어서 확장해야 할 때 자동완성 기능이 핵심인데 JavaScript를 쓰면 자동완성이 잘 안돼서 큰 애를 먹게 된다. 프론트엔드 프레임워크 React에서는 TypeScript를 도입해서 어느정도 보완하고 있는데 Node.js에서도 TypeScript를 도입하는 시도가 있다고 들었는데 어느 정도 진행됐는지 모르겠다.
Spring Boot
SpringBoot는 Java로 만든 서버 애플리케이션이다. Java는 유구한 역사를 가지고 있고 지금도 많이 사용되는 언어라 스프링부트를 사용하면 Java 언어에서 있는 기능을 그대로 사용할 수 있다. Java를 개발해본 사람들은 쉽게 Spring Boot에 적응 할 수 있다. 그리고 역사가 오래 됐기 때문에 개발하는데 필요한 왠만한 라이브러리는 모두 Spring Boot에 다 있다. 안드로이드 개발자가 사용한 자바 라이브러리들은 모두 Spring에서도 찾을 수 있다고 볼 수 있고 추가로 서버 개발자들이 어려움을 겪는 데이터베이스 관리도 스프링부트에서는 JPA라는 라이브러리를 통해 간소화 해둬서 손쉽게 다룰 수 있다. 그리고 Java이기 때문에 TypeSafe 하다. 리팩토링하거나 확장 할 때 IDE를 이용해서 수정할 점을 빠르게 체크 할 수 있는데 프로젝트 규모가 커지고 안정성이 중요해지는 시점부터는 큰 장점으로 다가온다. 내부적으로는 Multi Threading을 지원하는 구조로 짜여있어서 길고 반복적인 업무를 처리할 때 효율적이다. 많은 양의 컴퓨팅이 필요한 경우 잘 써먹으면 좋다.
한번 써보신 분들은 알겠지만 Spring Boot는 러닝 커브가 존재한다. Node.js는 처음 배우는 사람도 하루만에 서버 구동하고 api도 하나 만들 수 있는데 Spring Boot를 공부하면 Service, Controller, Repository 에 대해서 알아야하고 각 컴포넌트는 어떤식으로 채워야하는지 공부가 필요해 해야 할 게 많다. Spring Boot에서는 좋은 구조를 유도하기 위해 이런 형태의 디자인을 권장하는데 초심자한테는 러닝 커브가 좀 있다. 그리고 boilerplate 코드가 많다. 스프링에서 권장하는 구조랑 라이브러리들을 사용하려면 이런 저런 코드를 만들어야 하는데 처음에는 어려우나 숙달되면 귀찮아진다. 그래도 안쓰는 것 보다 낫긴 하지만. 내부적으로는 메모리를 좀 많이 쓴다. Multi thread 환경이기 때문에 여러개의 Thread를 띄우다 보니까 어쩔 수 없이 생긴 문제인 것 같다.
Spring으로 쿼리를 만들다보면 여러개의 테이블을 조인한 쿼리에서 다른 테이블 칼럼의 값까지 읽어올 필요가 있다. 예를 들면 글정보를 받아 오는 api가 있는데 내가 그 글을 좋아요 했는지, 안했는지 유무까지 알려주는 요구 사항의 경우 두 개의 테이블을 조인해야한다.
쿼리문을 짜면 다음과 같다. tb_post에 있는 모든 필드를 가져오고, 좋아요 유무는 liked 필드 이름으로 받아오는 것으로 뒀다.
select tb_post.*, when tb_post_user_like.post_id > 0 then true else false end as liked from tb_post
left join tb_post_like on (tb_post.post_id = tb_post_user_like.post_id and tb_post_like.user_id = :findUserId)
where tb_post.post_id = :postId
JPA에서 제공하는 CrudRepository 로는 이미 있는 테이블의 칼럼을 매핑해서 받아오는데 반해 이 방법은 임의로 liked라는 새 칼럼을 생성한 것이기 때문에 테이블과 1:1 매핑된 엔티티 클래스에서 했던 것처럼 칼럼을 자동으로 매핑하는게 안되고 다른 방법을 써야한다. 열심히 구글 검색을 해본 결과 세가지 방법을 발견했다.
1. Object형태로 받아오기
Query문에서 리턴 값을 Object로 받아오면 모든 필드 값의 리턴을 받아 올 수 있다. 가장 직관적이고 쉬운 방법이다.
@Query(value = "select tb_post.*, case when tb_post_like.post_id > 0 then true else false end as liked from tb_post \n" +
"from tb_post \n" +
"left join tb_post_like on (tb_post.post_id = tb_post_like.post_id and tb_post_like.user_id = :findUserId)\n" +
"where tb_post.post_id = :postId", nativeQuery = true)
fun findPostById(@Param("postId") postId: Long, @Param("findUserId") findUserId: Long) : List<Array<Any>>
하지만 이렇게 읽어오면 아래 그림처럼 필드 값이 생략돼서 날라오게 돼서 알아보기가 힘들다. 쿼리문에서 칼럼 필드 순서를 지정하는 방법으로 처리할 수 있으나 알아보기가 힘들어서 관리하기가 어려운 단점이 있어 추천하지 않는다. 위와 같은 형태로 읽어오는 클래스를 만든다면 더더욱 쓰지 않는게 좋다.
2. JPA New 명령어
JPA 쿼리의 New 명령어를 사용하면 리턴 값을 클래스로 줄 수 있다. 단 이 방법은 native query 문을 사용하지 못하고 jpa 쿼리를 사용해야 한다는 점이다. limit을 쓰는 구문에서는 사용할 수 없다.
data class Post(postId: Long, postTitle: String, postContent: String, liked:Boolean)
@Query(value = "select new com.package.Post(tb_post.post_id, tb_post.post_title, tb_post.post_content, case when tb_post_like.post_id > 0 then true else false end) from tb_post from tb_post left join tb_post_like on (tb_post.post_id = tb_post_like.post_id and tb_post_like.user_id = :findUserId) where tb_post.post_id = :postId")
fun findPostById(@Param("postId") postId: Long, @Param("findUserId") findUserId: Long) : List<Post>
3. SetQueryResultSetMapping
쿼리에서 읽어온 컬럼 필드를 클래스에 매핑 해줄 수 있는 어노테이션이다. ConstructorResult 어노테이션에서 칼럼 필드 값을 읽어와서 Post 클래스의 생성자로 만들 수 있다. 하단의 NamedNativeQuery 어노테이션에서는 쿼리의 이름을 정하고, ConstructorResult에서 참조하는 필드의 형태로 읽어 올 수 있도록 Select 문을 만들어 주고 사용할 mapping을 SqlResultSetMapping에서 지정한 이름과 동일한 값을 입력한다. 이렇게 하면 이 쿼리는 자동으로 Post 클래스 값을 출력하는 쿼리가 된다.
@SqlResultSetMapping(
name = "PostMapping",
classes = [
ConstructorResult(
targetClass = Post::class,
columns = [
ColumnResult(name = "post_id", type = Long::class),
ColumnResult(name = "post_title", type = String::class),
ColumnResult(name = "post_content", type = String::class),
ColumnResult(name = "liked", type = Boolean::class)
]
)
]
)
@NamedNativeQueries(value = [
NamedNativeQuery(name = "findPostByIdBaseOnUser", query = "select tb_post.post_id, tb_post.post_title, tb_post.post_content, case when tb_post_like.post_id > 0 then true else false end as liked from tb_post \n" +
"left join tb_post_like on (tb_post.post_id = tb_post_like.post_id and tb_post_like.user_id = :findUserId)\n" +
"where tb_post.post_id = :postId resultSetMapping = "PostMapping")
])
@Entity
data class Post(
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
val postId: Long,
@Column
val postTitle: String,
@Column
val postContent: String,
@Column
val liked: Boolean = false
): Serializable
아래의 코드로 쿼리 호출이 가능하다. 앞서 설저한 NamedNativeQuery의 이름 값과 동일하게 넣는다. 초반에 보일러플레이트 코드가 많지만 Post 클래스를 지속적으로 사용하고자 한다면 필드 값을 참조 할 수 있기 때문에 관리가 더 편리하다.
@Service
class PostService {
@PersistenceContext
lateinit var entityManager: EntityManager
fun postById(postId: Long, findUserId: Long): Post? {
return entityManager.createNamedQuery("findPostByIdBaseOnUser", Post::class.java)
.setParameter("postId", postId)
.setParameter("findUserId", findUserId)
.resultList
.firstOrNull()
}
}
디자이너와 협업하다보면 위 그림처럼 이미지의 꼭지점 부분에 radius를 넣어야하는 경우가 종종 생긴다. 아이콘으로 넣는 이미지의 경우에는 디자이너가 직접 아이콘의 radius를 먹일 수 있는데 뉴스피드처럼 외부에서 받아오는 이미지의 경우에는 매번 작업을 할 수 없어 코딩으로 처리해야한다. 이럴 경우 RoundedFrameLayout 라이브러리를 사용하면 쉽게 처리가 가능하다.
서비스 개발 하다 보면 위 그림처럼 recyclerview인데 아이템을 겹치는 형태로 만들어야 할 때가 있다. 먼저 쉽게 생각해 볼 수 있는 방법은 ItemDecoration을 이용해 item1을 제외한 item2, item3의 left 오프셋을 왼쪽으로 당겨주는 방법이 있다.
rv.addItemDecoration(object: RecyclerView.ItemDecoration() {
override fun getItemOffsets(outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State) {
val position = parent.getChildAdapterPosition(view)
if (position != 0) outRect.left = DimensionUtils.dp2px(requireContext(), 10f).toInt() * -1
}
})
그런데 이렇게 만들면 예상했던 것과 다르게 뒤에 있는 아이템이 앞에 있던 아이템 위로 올라가게 된다. 뒤에 있는 아이템을 우선순위를 높게 쳐서 발생하는 에러다.
처음에 계획했던 대로 만들려면 recyclerview 에 약간 트릭을 추가해야한다. 사용한 LinearLayoutManager에서 reverseLayout과 stackFronEnd 속성 값을 true로 설정한다. reverLayout을 true로 두면 아이템을 RTL에 맞춰서 오른쪽으로 쌓는 것이고, stackFronEnd는 recyclerview 영역의 끝부분부터 채우는 것이다. item을 역순으로 출력할 것이므로, 맨 앞에 있는 것은 맨 뒤로 가기 때문에 offset 설정 함수도 끝 부분이 이동하도록 바꿔준다.
이전 포스트에서 맥에서 파일의 대소문자 구분을 하지 않는 특성 때문에 크게 한번 삽질한 적이 있었는데 얼마 지나지 않아서 같은 삽질을 반복하고 말았다... 내 로컬 저장소에서는 아무 문제 없이 돌아가는데 리눅스 기반 heroku에서는 파일을 찾지 못하는 에러를 또 보고 말았다.. 부글부글.
이번에는 깃허브에서 관리하는 프로젝트도 아니라서 무슨 파일이 잘못됐는지 찾기도 어려웠는데 다행히 명령어 한줄로 긴 삽질을 막을 수 있었다. 깃에 올라간 파일 이름을 리스트로 출력할 수 있다.
예전에 쓴 Hilt 포스트에선 기존에 사용중인 프로젝트에 Hilt를 쉽게 적용할 수 없어 아쉽다는 점을 다루었다. 그래서 최근에 소소하게 시작한 사이드프로젝트에선 처음부터 Hilt를 도입해서 사용해봤다. 확실히 Dagger에 비해 자유롭고 사용하기가 간편했다. 이번 포스트에서는 어떤점이 좋았는지를 다뤄보고자 한다.
1. private val 변수 형태로 주입 가능.
Dagger로 의존성을 주입할 때는 @Inject 어노테이션과 뒤에 lateinit var 을 붙여줘야했다. 그런데 앞으로 바뀌지 않을 변수에 var 형태로 선언하는게 여간 찝찝한게 아니었다. 다행히 Hilt에서는 이런 찝찝함을 해결했다. 생성자의 인자로 추가해 의존성을 주입할 수 있어 값이 변경되지 않은 val 형태로 주입이 가능하다. 아래 코드는 @ViewModelInject 어노테이션을 이용해 module에서 선언된 객체들에 바로 의존성을 주입하는 코드다. private 변수로도 주입이 가능하다.
class AssetEditorViewModel @ViewModelInject constructor(
@Assisted private val savedStateHandle: SavedStateHandle,
application: Application,
private val assetRepository: AssetRepository,
private val assetTypeRepository: AssetTypeRepository
): AndroidViewModel(application) {
}
@Module
@InstallIn(ApplicationComponent::class)
class DatabaseModule {
...
@Singleton
@Provides
fun provideAssetRepository(appDatabase: AppDatabase) = AssetRepository(appDatabase.assetDao())
@Singleton
@Provides
fun provideAssetTypeRepository(appDatabase: AppDatabase) = AssetTypeRepository(appDatabase.assetTypeDao())
}
물론 activity, fragment 처럼 생성자를 customize 할 수 없는 클래스도 있다. 이런 경우 기존과 동일하게 lateinit var를 붙인 채로 주입이 가능하다.
@AndroidEntryPoint
class MainFragment : BaseFragment(R.layout.fragment_main) {
@Inject lateinit var assetRepository: AssetRepository
2. ViewModel 의존성 주입이 쉽다
Dagger에서는 ViewModel 을 공식적으로 지원해주는게 아니어서 별도의 Factory 클래스를 만들어서 주입을 해줘야 했다. 예로 Fragment를 만들면 이 Fragment Module에선 주입할 ViewModel을 팩토리 형태로 만들어줘야하고 ViewModelMap에 따로 등록도 해줘야하고 결과적으로 코드가 너무 늘어나 관리가 어렵다. Hilt에서는 ViewModel 의존성 주입을 공식적으로 지원해주기 시작했다.
ViewModel은 @ViewModelInject 어노테이션을 생성자 앞에 붙이고 ViewModel에서 사용하려는 의존성 주입 클래스를 선언만 하면 된다. Activity, Fragment 단에서는 코틀린 delegate 속성인 by viewModels(), by activityViewModels()를 통해 ViewModel을 받으면 평소와 동일하게 사용할 수 있다.
@AndroidEntryPoint
class MainActivity : BaseActivity() {
private val mainViewModel: MainViewModel by viewModels()
}
@AndroidEntryPoint
class AssetsFragment: Fragment(R.layout.fragment_assets) {
private val mainViewModel: MainViewModel by activityViewModels()
}
class MainViewModel @ViewModelInject constructor(
@Assisted private val savedStateHandle: SavedStateHandle,
application: Application,
private val accountRepository: AccountRepository,
3. Module 만들고 등록 할 필요가 없다.
Dagger에서는 어떤 Module을 만들면 Dagger에 등록해주는 Module에다가 추가해야했다. 그래서 열심히 Module을 만들어도 추가하는 작업을 빼먹어으면 런타임시 에러가 수두룩 뜨곤 했었다. 근데 Hilt에서는 따로 추가하는 작업 없이 @InstallIn 어노테이션만 추가해주면 된다. 귀찮고 빼먹기 쉬운 코드를 확 줄일 수 있었다.
@Module
@InstallIn(ApplicationComponent::class)
class DatabaseModule {
@Singleton
@Provides
fun provideAppDatabase(@ApplicationContext context: Context): AppDatabase {
return Room.databaseBuilder(context, AppDatabase::class.java, "database")
.build()
}
이외에도 편리한 점이 더 많을텐데 사이드 프로젝트 규모가 크지 않아서 아직 다 경험하지 못한 것 같다... 앞으로 쓰다가 괜찮으면 추가로 정리해서 올려야지.
하지만 아무리 눈 씻고 찾아봐도 내 프로젝트상의 코드에는 문제가 없다. 파일을 임포트 한 파일 명도 문제 없고 파일도 지정된 경로에 있다.
이럴때는 heroku app 의 터미널을 열어본다. heroku run bash 명령어로 나의 애플리케이션 프로젝트 폴더의 터미널을 열어 볼 수 있다. 문제가 된 파일이 있는 경로로 이동하니까 파일 이름이 Errors.js 라고 돼있었다. Errors.js는 errors.js 전에 설정한 파일 명이다. 파일 이름 변경사항이 heroku 프로젝트에 반영이 되지 않아서 그렇다.
user@kwony ~ % heroku run bash -a mytrot-dev
~ $ cd lib/utils/
~/lib/utils $ ls
Errors.js jwt-utils.js trot-response.js
heroku의 문제라기 보다는 mac + git의 문제라고 보는게 맞다. 문제가 된 파일(Errors.js, errors.js)은 대소문자가 바뀐 것 빼고는 변경 사항이 없는데 mac의 git에서는 이런 파일 이름의 변경사항을 놓치고 있다.
파일 이름을 index.js 에서 Index.js로 바꿨는데 git status에서는 변화 없는 것으로 나온다.
이럴때는 파일 이름을 대소문자만 바꾸는게 아니라 다른 변경 사항도 추가한다거나, 아니면 파일 이름을 한단계 더 거쳐서 바꾸거나 아니면 git mv 로 일일이 파일 이름을 바꾸면 된다. 번거롭고 실수하기도 쉬운 부분인데.. 왜 이렇게 만들어놨지
multer 라는 npm 라이브러리를 사용하면 nodejs로 쉽게 파일 업로드 api를 구축 할 수 있다. multer 라이브러리를 설치하고 내부 함수인 diskStorage 로 저장 받는 파일의 장소와 저장하게될 파일 이름을 설정하자. destination 필드에 파일 다운 받을 경로를 정하고 filename 필드에 다운 받는 파일 이름을 정한다. 그리고 정해둔 값으로 multer 오브젝트를 생성한다.
만든 객체로 s3 고유 함수를 호출 할 수 있다. 업로드의 인자에는 s3 버킷을 식별 할 수 있는 정보인 버킷 이름(Bucket), 권한 정보(ACL), 컨텐츠 타입 (ContentType), 보낼 파일 스트림 (Body), 파일 저장 경로(Key)를 입력한다. 아래 코드는 sync하게 호출하고자 promise() 함수까지 호출 했는데 원래는 비동기 함수라 .then, catch 함수도 호출이 가능하다.
node-cron 이란 라이브러리를 사용하면 몇 시간이나 몇 일을 주기로 특정 작업을 반복해서 실행 할 수 있지만 내가 원하는 시간대에 실행하는 것은 어렵다. 예로 매일 23시 55분에 실행하는 작업을 만드려면 cron 실행을 23시 55분부터 실행하도록 하거나 아니면 1분 주기로 재실행해서 23시 55분이 지났는지 확인해야하는데 이건 번거롭다.
이럴때는 node-schedule이란 라이브러리를 이용하면 된다. 이 라이브러리는 특정 작업을 언제 실행할 것인지 설정 할 수 있다. cron과 거의 비슷한데 내가 작업 시간을 설정 할 수 있다는 점에서 다르다.
아래 코드는 매시 42분 마다 실행되는 코드다. 2시 42분, 3시 42분마다 아래 코드가 실행된다.
var schedule = require('node-schedule');
var j = schedule.scheduleJob('42 * * * *', function(){
console.log('The answer to life, the universe, and everything!');
});
scheduleJob 첫번째 인자에 들어가는 위치별로 분, 시, 일, 월, 요일을 정해줄 수 있다. 모두 포함하고 싶으면 별표를 넣으면 된다.
node-schedule-tz 라이브러리는 time zone까지 설정할 수 있다. 그냥 node-schedule 라이브러리를 쓰면 서버 시간에 맞춰지는데 다른 국가에 서버가 있는 경우에는 맞지 않을 경우가 있다. 이때는 node-schedule-tz 라이브러리로 타임존까지 맞춰주자. 아래 코드는 서울 시간 기준으로 매일 23시 59분에 실행되도록 스케줄링 한 예다.
크롬 브라우저에서 chrome://inspect 주소를 쳐보면 그림 처럼 Remote Target 리스트에 현재 실행하고 있는 node js 프로세스가 보인다. inspect 버튼을 클릭해보자.
4. 디버깅 시작
Sources 탭에 들어가면 현재 실행하고 있는 코드가 라인별로 나온다. 오른쪽 상단의 more 버튼을 클릭하면 command 창을 열 수 있고 이거로 각 인자의 값을 볼 수도 있으니 조사식으로 적극적으로 이용하자. 또한 콜스택을 통해서 어떤 순서로 작업이 실행되고 있는지 알 수 있다.
useContext를 사용하면 하위 컴포넌트에서도 상위 컴포넌트에서 전달하는 값을 공유 받을 수 있다. props를 통해서 전달하지 않고 동일한 Context를 넘겨 받은 인자를 통해서 공유가 가능하다. 이 함수를 이용해 state 값과 이를 업데이트 하는 dispatch 함수를 컴포넌트끼리 공유 할 수 있다.
1. Context 만들기
하위 컴포넌트에서 공통적으로 공유할 수 있는 React Context를 만든다.
import React from 'react';
const NotesContext = React.createContext()
export { NotesContext as default }
2. Context 공유하기
공유를 시작하려는 가장 상위 컴포넌트에서 태그를 씌워준다. value 안에 넣어둔 값들은 하위 컴포넌트에서 접근 할 수 있게 된다.
useReducer는 useState랑 비슷하나 state 업데이트 작업을 담당하는 reducer를 직접 넣어 줄 수 있다는 점이 다르다. 아래 코드에서 주석으로 처리된 useState 코드는 두번째 인자로 state 값을 업데이트 하는 작업을 일괄 담당했는데, useReducer를 사용하면 커스텀 reducer를 추가할 수 있어 action의 타입에 따라서 다른 행동을 취하도록 할 수 있다.
useReducer도 useState처럼 리턴 값은 배열이며 첫번째 인자는 state 값이고 두번째 인자는 reducer에 액션을 보낼 수 있는 dispatch 함수다. 값을 업데이트 할 때는 dispatch 함수에 action 을 설정해서 업데이트 한다.
아래는 Note 를 추가하고 제거하는 작업의 코드다. useState를 사용할 때는 setNote를 이용해서 바로 업데이트 하는 코드를 넣었다면 useReducer에 넣어둔 Reducer를 이용해 action 과 인자를 전달해서 작업을 넘길 수 있다. 액션을 추가하는 코드는 useReducer에서 받아온 dispatch 함수를 사용한다.
리액트의 useEffect 라이브러리는 컴포넌트나 state에 변화가 생길 때 호출되는 함수다. 두개의 인자를 받는데 첫째 인자는 변경시 호출할 콜백함수고 두번째 인자는 상태를 변경을 감지할 state를 설정한다. state를 별도로 설정하지 않으면 componentDidUpdate, componentDidMount랑 동일한 역할을 하게 된다.
위와 같이 여러개의 useEffect 함수를 둘 수 있다. 첫번째 useEffect에서는 두번째 인자에 빈 배열을 넣었는데 이러면 최초 한번만 호출되게 된다. componentDidMount 콜백과 기능이 유사하다. 두번째 useEffect 함수에서는 notes 상태 값을 인자로 두었다. notes 상태의 값이 변경될 때마다 함수가 호출된다. 세번째 useEffect 함수는 전달인자를 따로 넣지 않아서 내부에 어떤 state가 바뀌더라도 새롭게 호출된다.
기존에는 setState를 이용해서 모든 오브젝트를 다시 초기화해야 했다면 useState에서 넘어온 setter 함수를 이용해 내가 업데이트 하고 싶은 state만 명시적인 함수로 호출이 가능하기 때문에 관리가 한결 수월해진 측면이 있다. 한 컴포넌트 내에서 관리할 state 인자가 많아질수록 유용해질 기능인 것 같다.
connect 함수는 리액트 앱의 하위 컴포넌트에서 redux store를 접근하는 것을 가능하게 해주는 역할을 한다. 이 함수를 이용해서 컴포넌트 단에서 redux store에 접근하고 액션을 호출 할 수 있게 된다. 이번 포스트에서는 간단한 예제로 connect 함수를 통해 redux store를 사용하는 방법을 다뤄보려고 한다.
클래스 형식 컴포넌트를 export 할 때 connect 함수를 사용하고 첫번째 인자에 mapStateToProps 함수를 넣었는데 redux store에 있는 값을 컴포넌트에 어떻게 넘겨줄지 세팅하는 작업이다. 넘겨 받은 값은 component의 props에 들어가서 호출 할 수 있다. 아래 사진은 render() 함수 안에서 console로 찍은 로그다. textReducer와 numberReducer가 출력되는 것을 볼 수 있다.
함수 형식도 크게 다르지 않다. 컴포넌트 내에서 호출 할 때 this를 부르지 않아도 된다는 점만 다르다. 위 코드로 호출하면 아래 그림처럼 화면 뷰가 그려진다.
3. Action
connect로 컴포넌트에 전달 할 때 store만 전달 하는것이 아니라 action을 넣을 수 있는 dispatch 함수까지 전달된다. react 디바이스 툴을 사용해보면 component의 props 안에 dispatch가 들어있는 것을 확인 할 수 있다.
실제로도 잘 사용할 수 있을 지 테스트 해보자. 방금 전에 사용한 BlogDetail 컴포넌트를 살짝 수정해서 현재 store에 저장된 text를 출력하고 버튼을 추가하고 클릭하면 text를 BlogDetail로 바뀌도록 했다.
import React from 'react';
import { connect } from 'react-redux';
import { setText } from './BlogActions';
const BlogDetail = (props) => (
<div>
<p>BlogTextDetail</p>
<p>current store text value: {props.text.text}</p>
<button onClick={() => {
props.dispatch(setText('BlogDetail'))
}}>Change text to BlogDetail</button>
</div>
);
const mapStateToProps = (state) => {
return { text: state.text};
};
export default connect(mapStateToProps)(BlogDetail)
함수를 실행하고 버튼을 클릭하니 화면이 아래와 같이 store의 text 값이 BlogDetail로 변경됐다.
4. 총평
코딩을 처음 하는 분이면 이걸 왜 이렇게까지 해야할지 이해가 안될 수 있을 것 같은데 이전에 mvvm, mvc 패턴을 경험해본 개발자들에게는 redux가 크게 어려울 것 같지 않다. 강의 들을 때는 헷갈렸는데 실제로 코드로 짜보니까 어떤 식으로 구조를 잡아야할 지 느낌이 온다. 물론 자바스크립트 언어 특성상 state 세부 이름을 관리할 때 꽤 귀찮음을 겪을 것 같긴 하다.
react 에서는 react-router-dom 라이브러리를 통해 들어 오는 주소 별로 별도의 페이지를 보여줄 수 있는 라우팅 기능을 제공한다. 리액트의 특성에 맞게 이 라이브러리는 어떤 페이지로 진입 했을 때 어떤 페이지를 보여 줄 것인지를 컴포넌트 단위로 뽑을 수 있다.
1. 라이브러리 임포트
리액트와 필요한 라이브러리를 임포트 한다.
import React from 'react';
import { BrowserRouter, Route, Switch, Link, NavLink } from 'react-router-dom';
2. Route
const AppRouterExample = () => (
<BrowserRouter>
<div>
<Switch>
<Route path="/" component={() => (<h2>This is DashboardPage</h2>)} exact={true} />
<Route path="/create" component={() => (<h2>This is Create Page</h2>)} exact={false} />
<Route path="/edit/:id"
component={ (props) => (<h2>This is Edit Page {props.match.params.id}</h2>)}
exact={true} />
<Route path="/help"
component={() => (<h2>This is help page</h2>)}
exact={true} />
<Route component={() => (<h2>This is not 404 page</h2>)} />
</Switch>
</div>
</BrowserRouter>
);
<BrowserRouter> 와 <Switch> 태그 내에 위치한 <Route> 태그로 관리하고 싶은 경로를 설정할 수 있다. 이렇게 두면 애플리케이션이 관리하는 경로를 설정 할 수 있게 된다.
2.1 path
라우팅할 경로를 정의하는 값이다. 위 페이지에서는 /create, /edit, /help 페이지를 경로로 뒀다. edit 페이지의 경우에는 수정하려는 데이터의 id를 인자로 받을 수 있고 이 값은 component에 전달된다. component 객체에 props로 전달되며 저장되는 필드는 컴포넌트에 있는 값과 같다.
2.2 component
해당 경로로 들어올 경우 어떤 component를 보여줄 것인지를 결정하는 곳이다. 직접 컴포넌트를 만들어서 넣을 수 있으며 이 예제에서는 component 필드 내에서 보여줄 수 있는 값을 넣었다. /edit 경로를 보면 props로 Route로부터 인자를 받아오는데 /edit에서 받아오는 id 정보를 확인 할 수 있다.
2.3 exact
exact는 이 경로를 명확하게 볼 것인지 말것인지를 설정한다. 평소 익히 쓰던 path와 다른 개념이라 와닿지 않을 것 같은데 exact값이 false면 앞에 부분만 맞아도 해당 페이지로 렌딩이 된다. 예로 /create 는 exact 값이 false이기 때문에 /create/34 로 접근하든, /create/edit 으로 접근하든 모두 create 페이지로 렌딩해준다.
react는 state를 이용해서 컴포넌트의 상태를 관리하는데 state 하나에 들어가는 element가 많아질수록 관리하기가 힘들어지는 문제가 있다. 그래서 react에서는 redux라는 라이브러리를 이용해서 state를 좀더 쉽게 관리할 수 있게 해줬다. 크게 state를 관리하는 store와 store 를 변경하려는 dispatch 그리고 변경 작업을 일괄 관리하는 reducer로 나뉘는데 이번 포스트에서는 각각에 대해서 간단히만 다뤄보려고 한다.
1. createStore
redux로 관리할 state 집합을 만드는 작업이다. 함수의 인자로는 reducer를 받는다.
const store = createStore(countReducer);
2. action
state를 바꾸기 위해 취하는 액션이다. 단 여기에는 액션이 들어가지 않고 액션에 필요한 데이터만 들어간다. 변수 이름을 자유롭게 입력할 수 있는데 type 필드에 액션의 종류를 정해주는게 일반적인 것 같다. dispatch 함수를 통해 액션을 실행 할 수 있다.
Syntactically Awesome StylesheetS 의 준말로 기존 css보더 더 편하게 스타일링 할 수 있는 언어다. css에 있는 모든 기능을 포함하고 여기에 더해 변수랑 내부에서 제공하는 함수도 사용할 수 있기 때문에 개발자들의 반복적인 작업을 확 줄여준다. 5년 전에 간단히 홈페이지 만들면서 css를 쓰고 불편하다고 느낀후 지금까지 손댄적이 없었는데 지금은 scss 라는 언어로 더 쉽게 스타일링 할 수 있게 된 것 같다. 이번포스트에서는 scss를 react에 적용하는 방법을 간단히 소개한다.
1. scss 로더 추가
scss는 확장 기능이므로 새로 css로 transformation 해주는 기능이 필요하다. 별도의 로더를 설치하고 스크립트를 실행할 수 있으나 여기선 webpack에 로더를 추가해서 정리하려고 한다. 먼저 아래 명령어로 필요한 라이브러리를 추가한다.
entry에 해당하는 파일에서 아까 추가한 scss 파일을 임포트 한후 간단한 코드를 넣어 봤다.
import React from 'react';
import ReactDOM from 'react-dom';
import './styles/styles.scss';
ReactDOM.render(<div><h1>This is selfish-developer blog</h1></div>, document.getElementById('app'))
webpack 은 자바스크립트로 짠 애플리케이션의 모듈 관리용 툴이다. 애플리케이션에서 필요한 모듈의 의존성을 관리하고 프로젝트용 코드를 만들어준다. 예로 리액트 자바스크립트에서 필요한 babel, style-loader, css-loader 같은 스타일용 로더, 애플리케이션의 시작위치를 정하는 entry, 디버깅용 devtool 설정, 서버 관리까지 모두 webpack을 이용해서 관리가 가능하다. 짜치는 일들을 하나로 묶어서 관리해주는 라이브러리니 배워두면 프로젝트 관리할 때 크게 도움이 될 것 같다.
1. Configuration
webpack.config.js 파일을 통해서 webpack에서 관리하고 싶은 설정을 추가할 수 있다. 아래 코드는 튜토리얼 프로젝트에서 추가한 webpack 설정 코드다. 공식 문서를 살펴보면 더 많은 설정을 추가 할 수 있다. 이번 포스트에서는 주요 설정에 대해서만 정리하려고 한다.
webpack이 어디에서 의존성 그래프를 그려갈 지 설정하는 곳이다. 어디서부터 프로그램을 시작할지 설정하는 작업이라고 봐도 좋다. c언어 프로그램으로 치면 main함수를 어디에 둘 지 설정하는 작업이라고 봐도 될 것 같다. 위 소스코드에서는 src 폴더에 있는 app.js를 시작점으로 두었다.
1.2 Output
webpack으로 만든 묶음(bundle)을 어디에 생성할 것인지를 설정한다. 일단 c언어라면 컴파일후 바이너리 결과물을 어디에 둘 것인지 설정하는 것과 같다.
1.3 Loaders
webpack 이 어떤 타입의 파일을 특정한 모듈로 변경하고 의존성 그래프에 추가할지를 설정하는 작업이다. 위 코드의 module 내부를 보면 test 속성과 use 속성이 있는데 test는 어떤 파일을 변형할 것인지를 설정하고 use는 어떤 loader를 사용할 것인지 설정한다. 여기서 test는 파일을 설정하는 작업이라고 했는데 파일 이름을 정규표현식으로 정하고 있다. 위 코드에서는 jsx 컨버팅용 babel-loader와 css 스타일링용 style-loader, css-loader, sass-loader 를 추가했다.
1.4 DevServer
webpack-dev-server 라이브러리를 이용해 빠르게 프로그램을 시작 할 수 있는 기능이다. devServer 값을 설정하면 리액트 프로그램을 시작 하는 주소나 포트번호 같은 값을 쉽게 설정 할 수 있다. 위 코드에서는 가장 기본인 시작 위치만 설정 했다.
2. 설치 및 사용
2.1 설치
npm을 이용해 global 하게 설치하는 방법도 있지만 꼬여버리면 답이 없으므로 프로젝트 단위로 yarn을 이용해서 설치한다.
리액트의 localStorage는 Android의 SharedPreference나 iOS의 UserDefaults 처럼 애플리케이션 단위로 key-value 값을 저장할 수 있는 라이브러리다. 아래 코드를 보면 getItem 함수에 key값을 넣어서 값을 받아오고 setItem 함수에 key 값을 넣어서 값을 업데이트한다.
아래 코드를 보면 JSON 라이브러리를 사용해 변환하는 과정이 있는데 이 이유는 localStorage에서는 string의 형태로만 저장이 가능하기 때문이다. 그래서 일반 텍스트를 사용하는 것이 아니면 모두 JSON을 이용해 값을 변환해서 저장해야한다. 배열 같은 값을 저장한다면 어차피 변환하는 과정이 필요하기 때문에 항상 써두는 것도 나쁘지 않을 것 같다.
componentDidMount() 와 componentDidUpdate() 함수는 리액트의 라이프사이클 관리 함수다. componentDidMount()는 리액트 컴포넌트가 처음 생성 될 때 호출되고 componentDidUpdate는 리액트 컴포넌트에 변화가 생겼을 때, 예로 state 값이 변화해서 UI가 바뀌었을 때 호출된다. 위 코드는 각 라이프 사이클에서 필요한 작업을 넣은 것이다. 주로 componentDidMount에서 기존 값을 가져오고(fetch) componentDidUpdate에서 값을 업데이트 한다
props는 리액트에서 상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달 할 때 사용하는 기능이다. 아래 그림처럼 Header가 App 안에 포함되어 있을 때 App에서 Header에게 title과 subtitle을 전달하게 되는데 이를 props를 이용해서 할 수 있다.
상위로부터 받아온 props 데이터를 확인해본다. props 데이터는 {this.props} 내에 있고 상위에서 보내준 key 값에 따라서 값을 확인 할 수 있다.
3. stateless function
함수의 형태에서도 props로 전달된 값을 받아 올 수 있다. 아래 코드에선 props 변수를 받는 함수를 만들고 return 값으로 props에서 받아온 이름으로 버튼을 만들었다. 상위 컴포넌트인 App에서는 Action 컴포넌트에 buttonName을 props로 전달했다.
props로 데이터 뿐만 아니라 함수도 전달 할 수 있다. App 컴포넌트에 알럿 메시지를 띄우는 handleClick이라는 함수를 만들고 생성자에서 바인딩을 한 다음 Action 컴포넌트에 데이터를 전달하는 것과 동일하게 함수를 전달한다. 버튼을 그리는 Action 함수에서는 button 의 버튼 클릭 콜백함수에 받아온 handleClick을 인자로 넣는다.
