본문 바로가기

반응형

PROJECT

(10)
[fe] setting3 기간을 여유롭게 잡았으며 최대한 기존에 알고있는 언어, 프레임워크에서 차근차근 넓혀가는 방식의 공부를 택했으므로 마음에 안들면 갈아엎는 방식으로 진행할것이며 이번에 한번 갈아엎으려고 한다. 다음과 같은점을 중심으로 잘 생각한뒤에 다시 구조를 만들어보자 1. ui 2. 홈페이지 기능 3. mobile first 엎어진 branch github.com/dbstpwlsWork32/whwtopia-fe/tree/__pending
[fe] setting2 1. lit-html lit-html을 패키징한 lit-element도 안쓰고 lit-html만 사용했으므로 사실상 렌더링 엔진만을 사용하고 나머지는 생각하면서 구조를 짜야해서 구조짜는데에 거의 80%의 시간만 든거 같다. 구조짜기전의 컨셉은 대강 다음과 같다. 1. custom element 적극 활용 2. 관심사의 집중 ( lib, view, app, component의 샅샅이 흩어지는 구조 수정 ) 3. life cycle없이 실 렌더도 언제해줄지도 직접 제어 4. dom기존의 네이티브한 기능 그대로 이용 폴더 구조 *x: import X, 자체상태 O, 1급함수 X *O: import O, 자체 상태 X *L: import O, 자체 상태 O /App *x - root rendering /comp..
[fe] setting BASE SETTING 무조건 wsl2기반으로 작업할거다 windows로 작업하면 mac등 다른 os에선 충돌이 있을수도 있기 때문이다. ide는 ms가 만들었고 wsl2에도 최적화 되어있는 vscode를 사용한다. project folder는 /project/whwtopia/fe 에다 할거다. root로 접속안해도 수정 가능하게 chmod도 잡아준다. git ssh는 귀찮으니까 window에 설정되어있었던 ssh 가져오고... ( 주의할건 root가 아니라 ${USER}에도 가져오게 하려면 해당 ${USER}에도 알아서 .ssh 복붙하도록... ) branch 구조는 다음과 같다 1. master => real server staging 2. dev => dev server staging 3. feat..
[design] 디자인 초기 www.figma.com/file/aMlWdbRTneaL6UehNmTsuA/whwtopia_prototype?node-id=47%3A2 Figma Created with Figma www.figma.com
[DAY1] (DESIGN) 툴은 figma를 사용할거고 어려서부터 예술쪽에는 손도 안댔기 때문에 미적감각이라곤 쥐뿔도 없다 간단한 틀만잡고 세부적인 디자인은 figma의 커뮤니티 기능을 이용해서 공유된걸 찾아서 갖다 붙여버릴것이다 www.figma.com/file/aMlWdbRTneaL6UehNmTsuA/whwtopia_prototype?node-id=0%3A1 Figma Created with Figma www.figma.com prototype은 이렇고... 전체적인 컨셉?은 예쁜거 막 갖다가 붙여야지
lit-html 을 사용하려는 이유 vue, react 둘다 엄청 편하고 생산성을 높여주는 것은 분명하다. 하지만 현재 프로젝트를 진행하며 가장 중요하다고 생각하는 것이 spa를 위한 router, state management 등을 사용하며 "라이브러리를 사용하기 위한 라이브러리", "라이브러리를 사용하기 위한 프레임워크" 에서 벗어나는 것이다. 이로인한 장점은 다음과 같을 것이라고 생각한다. 1. 지나치게 고도화된 라이브러리의 프레임워크화 탈출 2. 깊은 수준까지 제어 가능 3. 개발을 위한 lib docs api 탈출 하지만 나는 개발 생산성 또한 중요하게 생각하는 요인중의 하나다. 일단 현재 구상중인 아키텍쳐를 직접 시도해보며 이전 개발구조와 현재 개발구조의 생산성 또한 면밀하게 검토할 것이다. lit-html 같은 경우엔 docs..
parcel 을 사용하려는 이유 12/09 (수) 11: 25 이전 cra, vue-cli는 webpack 기반 이며 심지어 vue는 거기에 한술 더떠서 vue-loader를 붙여가지고 webpack공식문서에서 하라는대로 하면 안될때가 많다. 결국 프론트엔드 개발할때 다음과 같은 것들이 표준아닌 표준이 되었는데 1. hot module replace ( webpack에서 이거 설정하다가 속만 태웠다... ) 2. dev, prod, local 분리 (환경변수) 3. 에셋 컨트롤 4. 그외 ( vue, react, sass?, typescript?, xx-router, xx-store... ) 붙여주기 물론 각각의 xx-router, xx-store등은 알아서 붙여야 하지만 그외 1, 2, 3은 webpack보다 훨신 쉽다. plugin..
docker를 사용하려는 이유 mac os에서 작성되있던 serverless 기반의 아키텍처에 백엔드 코드를 추가해줘야될 일이 좀 있었다. 당시 사용하던 os는 window wsl2에다 ubuntu로 끌어와서 작성되어 있던 readme를 찬찬히 읽으며 세팅을 했따 환경이 달라서 문제점들이 있었따. 작게는 window wsl2에서와 mac os에서의 basch script를 사용할때 줄바꿈 처리인 \n를 window wsl2에서는 \n\d이었나 어쨌든 줄바꿈 문자가 달라서 실행이 안된다. 크게는 테스트 모드가 따로 없다보니까 api요청 header에서 ip를 로컬 아이피로 인식해서 로컬 환경에서 테스트 불가능 한다던지... 그때는 시간이 급박해서 울며 겨자먹기로 auth처리하는부분을 주석처리하거나 로컬에다가 nginx로 proxy처리해..

반응형