crabLab

날짜를 읽어올때(with TZ) 이렇게 서버로 보내준 날짜는 읽을 때 tz형식으로 들어온다. tz는 timezone의 약자로 YYYY-MM-DDTHH:mm:ss.00Z 2023-02-12T16:00:00.000Z 이런 형태이다. 이렇게 읽어온 데이터는 이벤트 목록에서 이벤트 수정에서 두 번 쓰이게 된다. 여기서의 문제는 한국의 시간은 GMT+09:00인데 서버에서 데이터베이스에 한국 표준시(GMT+09:00)를 insert해도 GMT로 insert 된다는 점이다. 따라서 프론트에서 나라에 맞는 시간으로 변경하여 표시해야 한다. 이 말뜻은 프론트에서 3시로 보내고 서버도 3시로 보내지만 막상 moment를 이용해 date객체로 만들면 서버로부터 받은 데이터는 (+9)되어 12시가 된다. 이벤트 목록의 경우..

추가로 disabled 속성 응용 공식문서에도 적혀 있지만 disabled속성이 있다. 이 속성은 true일때 이 input을 비활성화하는 것인데 이 기능을 이용하면 날짜가 정해지기 전에 시간을 먼저 정하는 것을 방지할 수 있다. 그래야 하는 이유는 datepicker는 원래부터가 과거도 선택할 수 있게 되어 있고 나의 경우 기획상 날짜가 당일 날짜일때만 현재시간보다 이전 시간을 선택하지 못하게 해야한다. 이 부분을 datepicker의 자체기능을 찾고 구현하기에는 시간의 소요가 많이 걸릴 것으로 예상되었다. 처음에는 어떻게 해야할까 많은 삽질을 했지만 삼항연산자의 중요성과 활용도를 점점 느끼면서 이번에도 같은 방법으로 해결하게 되었다. 여기까지 오기에 많은 경험이 있었지만 결과는 사실 단순하다. dis..

요구 사항들이 다 정리가 되었기에 우선 이 날짜 기능을 어떻게 구현할지를 정해야 했다. 직접 구현할 것인지 아니면 라이브러리를 쓸 것 인지 전에 패x에서 달력을 바닐라 자바스크립트로 만드는 강의를 본 기억이 있었지만 그 강의는 단순히 달력기능까지만 나왔으며 이번에는 복잡하게 날짜 데이터들을 가공해야하며 무엇보다 시간제한이 걸려있기에(없었다면 바닐라 자바스크립트로 했었을 것 같다.. 실력향상에도 좋고 확장성도 좋고) 라이브러리를 선택하기로 했다. 라이브러리는 크게 react-calendar 와 react-datepicker가 있었는데 나는 react-datepicker의 레퍼런스 코드가 어느정도 있음 공식사이트의 설명이 직관적임 의 이유로 react-datepicker를 사용하기로 결정했다. 순서대로 구현..

달력기능이 추가된 게시판이다. 이번에 이 기능을 만들면서 그리고 이 글을 쓰는 와중에도 끊임없이 계속 버그를 픽스하는데 꽤나 요구사항과 기능들이 복잡했기 때문이다.(라이브러리를 써서 그런 것 일지도 모른다..) 우선 요구사항만으로 이번 포스팅을 마무리 해본다. 요구사항 게시판을 만든다. 게시판에는 이벤트들이 목록으로 나오고, 각 이벤트에는 날짜가 지정되어 있다. YYYY-MM-DD HH:mm AM - HH:mm AM 이벤트를 등록할 수 있는데 이 게시판은 달력을 이용해 날짜를 지정해야 한다. input창 3개 1개는 클릭하면 달력이 나와야한다. 2개는 시간이 나와야한다. 처음에 날짜를 오늘로 했다면 처음 시간 input에는 현재시간 이전은 선택하면 안된다. 시작시간을 정하기전에는 끝시간을 정할 수 없으며..

서브도메인을 하는 이유 example.com이라는 하나의 서비스 도메인을 가지고, 개발과 운영으로 분리된 AWS 계정에서 각각의 Route 53으로 도메인을 관리하기 위해서는 하위 도메인을 위임해야 한다. 이때, 필요한 것은 네임 서버 설정이다. 이를 통해 해당 도메인이 어떤 호스트 영역에서 관리되는지 확인이 가능하다. 하위 도메인 위임에 대해서, DNS 동작 원리와 연관 지어 알아보도록 하자. 도메인 규칙 필자는 이번 포스팅에서, 하나의 메인 도메인 southouse.com을 발급받았다고 가정하고 진행한다. 개발 환경은 *.dev.southouse.com이라는 규칙을 가지고 서비스에 따라 app.dev.southouse.com 등으로 지정하고, 이를 개발 도메인이라고 부르기로 했다. 운영 환경은 *.s..

CloudFront이란? AWS CloudFront란 AWS 제공하는 CDN 서비스이다. CDN은 Contents Delivery Network의 약자로 콘텐츠 제공자와 사용자 간 지리적으로 떨어져 있는 환경에서 콘텐츠를 빠르게 제공하기 위한 기술이다. CloudFront는 전 세계에 분포된 엣지 로케이션이라고 하는 데이터 센터의 엣지 서버를 사용해 콘텐츠를 캐싱하고, 사용자가 위치한 곳에서 가장 가까운 엣지 로케이션에서 콘텐츠를 제공받을 수 있도록 해주는 역할을 한다. 또 CloudFront는 SSL 인증서를 이용한 HTTPS 호스팅을 지원한다. 사실 이번에 우리가 CloudFront를 이용하는 이유는 HTTPS 호스팅 때문인데, S3로 배포한 앱은 SSL 인증서 적용이 불가능하다. 따라서 우리는 Cl..

Route53과 SubDomain 보통의 경우는 Route53에서 도메인을 사면 일사천리로 다른 레퍼런스들을 따라하면 해결되겠지만 나의 경우 SubDomain을 통해 기존의 웹사이트가 아닌 내가 지금 만든 s3버킷이 들어갈 곳을 만들어야 하기에 새롭게 진행해본다. 따로 서브도메인의 경우를 작성할 예정 물론 나의경우는 이미 도메인이 있었지만 여기서는 처음 즉, Route53에서 도메인을 사는것부터 할 것 이다. 또한 이후에 진행할 CloudFront와 ACM같은 경우 사실 순서는 크게 중요하지 않은 것 같다. Route53이란? Route53이란 AWS에서 제공하는 DNS 서비스이다. 우리는 Route53을 통해 도메인을 구매하고 호스팅 영역을 생성 및 NS(네임서버) 구축을 통해 DNS에 요청을 처리할 ..

Github Action을 통한 자동배포 GitHub Action이란? 이번에는 Github Action을 살펴보자! Github Action은 Github 저장소를 기반으로 소프트웨어 개발 Workflow를 자동화 할 수 있는 도구로, Github에서 직접 제공하는 CI/CD 도구이다. github action은 Workflow를 기반으로 동작하며, Github 저장소에서 발생하는 build, test, package, release, deploy 등 다양한 이벤트를 기반으로 사용자는 직접 원하는 Workflow를 만들 수 있다. 즉 우리는 Workflow를 만들고, 이를 통해 빌드 및 배포 프로세스를 자동화 할 수 있다!😎 각각에 이벤트에 대해 더 자세한 내용이 궁금하신 분은 공식문서를 읽어 보시는 ..

들어가는 글 이번에는 개발환경에만 있던 서버리스 페이지를 https로 배포하는 업무를 진행했다. 단, 우리회사에는 기존에 도메인이 이미 있었고 그래서 서브도메인으로 진행하게 되었다. 서브도메인이란 예를 들어 www.naver.com이라는 도메인이 있다면 www.admin.naver.com으로 들어오게 하는 도메인을 파는 것이다. 나도 이번에 처음 알게 된 것 이지만 이미 도메인을 가지고 있다면 저 방식으로 다른 s3 bucket을 연결할 수 있다. 또한 이번과정에서 github actions를 이용한 자동배포 또한 적어볼 생각이다. 이걸 이용해서 다음에는 꼭 CI/CD라는 이름에 걸맞는 코드를 짜고 싶다. 어떤 순서로 진행되나요? 배포할 프로젝트 준비 프로젝트 구현 및 배포용 빌드 S3 버킷에 올리기 g..

들어가는 글 게시판에는 글을 보여주는 방식에 크게 두가지가 있다. 무한스크롤 페이지네이션 둘 다 모바일과 데스크탑에 사용해도 상관이야 없지만 보통은 모바일에는 무한스크롤 데스크탑에는 페이지네이션을 사용한다. 그리고 항해 실전프로젝트때 나름 무한스크롤을 꽤나 파봤고 이번에는 페이지네이션을 좀 파봤다. 그래서 정리해본다. 페이지네이션을 위해 우선 알아야 할 것들 우선 내가 이번에 사용한 라이브러리는 react-paginate이며 이유는 나에게 레퍼런스가 이게 많았기 때문이다. react-js-pagination가 다운로드수와 지속적인 업데이트면에서 더 좋으므로 이것을 사용해도 괜찮다. 메소드명만 다르고 기본적인 원리는 같다. 우선 구현사항을 정의해보자. 처음 로딩되면 게시물의 개수에 맞춰 페이지의 숫자들이 ..