본문 바로가기

Frontned Development

 (34)
[WebApp] WebView [학습 키워드]1. React-Native2. WebView3. CodePush (올해 3월 31일 삭제 예정)WebView란?네이티브 앱에서 웹 페이지를 불러와서 iframe 처럼 사용하는 것Native 기능(알림, 카메라)을 직접 사용하지는 못하고, bridge를 이용하여 간접적으로 앱 기능 사용 가능WebView 구조bridge : superApp 마냥 Native와 Web을 통신시켜주는 도구WebView 선택 이유(상대적으로) 빠른 MVP 개발 속도특히, 웹 개발자들이 바로 앱을 만들 수 있음MVP 단계에서 성능 저하가 크지 않을 것으로 예상Next.js로 개발한 부분은 바로 web으로 배포하여 크로스플랫폼 지원유지보수가 편리함 (심사없이 수정 가능)네트워크 의존성RN은 버그가 많음장기적으로는 r..
[React 공식문서] React의 이벤트 객체 (synthetic event) 합성 이벤트란? 정의 : React에서 사용하는 이벤트 객체로, 합성 이벤트(synthetic event)라고도 불립니다. 필요한 이유 : React가 브라우져마다 다르게 작동하는 브라우져 불일치 문제를 해결합니다. 특징 : 1. React는 Dom의 native 이벤트를 사용하지 않고 합성 이벤트를 사용합니다.- native 이벤트 핸들러 처리 및 캡쳐링/버블링이 완료한 후, react 이벤트 핸들러가 처리됩니다.- 대부분의 이벤트는 버블링 단계에서 호출됩니다. Capture 단계에서 필요하다면 이벤트 뒤에 Capture를 붙여서 호출하면 됩니다. 2. event의 표준 properties와 methods를 일부 가지고 있습니다.boolean bubblesboolean cancelableDOMEvent..
이벤트 캡쳐링, 이벤트 버블링, 이벤트 위임 (with react) 이벤트 캡쳐링 / 버블링정의 : - 이벤트 버블링 : 이벤트가 클릭한 하위요소에서 전파되어 부모까지 전달되는 현상- 이벤트 캡쳐링 : 이벤트가 클릭한 대상의 하위요소로 전파되는 현상, 기본적으로 off 상태로 사용되기 위해서 명시해야함 필요한 이유 : DOM의 특정 요소를 선택했을 때, 그 요소는 부모 내부에 있기에 이벤트를 상위와 하위로 전달하는 방법이 필요하다. 이 때, 사용되는 것이 이벤트 버블링과 캡쳐링이다. 이벤트 전파 순서 : (캡쳐링) -> 타겟 -> 버블링 캡쳐링과 버블링 중단하지만, 반대로 캡쳐링과 버블링으로 원하지 않는 요소에 이벤트가 전파되고 실행되어서 곤란할 수가 있다. 이를 해결위해서는 알맞게 이벤트를 전파하거나 이벤트의 흐름을 관리해야한다. 다음 요소들은 그를 위한 속성과 메서드..
[화이트보드 동시편집 프로젝트] 4. 마무리 그마지막으로 소소하게 배운 점과 하고 싶은 일들을 남겨두려한다. 웹 접근성웹 접근성과 인클루시브 디자인에 대해서 처음 배웠다.여러가지 차이점을 없애고 모두가 같이 편하게 사용할 수 있도록 만드는 디자인은 정말 가치있는 일이라는 생각이 든다.또, 수많은 태그들이 모두 이런 접근성에 기여한다는 점이 신기했다.오직 div로만 모든 걸 만들었던 과거를 좀 반성하고 있다. 크로스 브라우져 / 기기 호환성제일 걱정했던 부분인데 생각보다 로직은 멀쩡했고 css가 소소하게 깨져서 귀찮았을 뿐 할 말했다. 하지만, apple 제품들과 safari는 정말 힘들었다.iOS 정책 때문에 안 된적도 많았고, 아직도 모르겠는 사파리 이슈가 있다.그리고 두 개 겹쳐지니 뭐가 문제인지 찾는 것도 진짜 힘들었다. 하고 싶은 일들 도전..
[화이트보드 동시편집 프로젝트] 3. 파트장 역할 수행기 (feat. 소통) 나는 이번에 파트장 역할을 수행해서 배운 점과 실수한 점들에 대해서 서술하고자 한다. 내가 맡은 일은 당연히 제품을 기간 내 성공적으로 개발하는 것이었고, 이 문제점을 해결하기 위해서 다음 역할이 필요하다 생각했다. 1. 정보를 잘 정제해내는 것.- 이번 일은 다른 기업과 다른 팀, 다른 본부랑 하는 큰 사업이였다. 그리고 규제가 굉장히 많은 사업이였다. 외부 내용을 내가 잘 정리해서 필요한 지식과 합의된 내역을 문서로 팀원들에게 전달하는 것이 내 역할이라 생각했다. 2. 프로젝트 관리를 하는 것.- 마감은 있지만, 상세한 일정관리는 없었다. 이 부분이 나는 중간점검이 어려우며, 실패에 대한 대책이 없다는 것으로 들렸다. 그래서 큼직한 중단점들을 잡아서 이를 기반으로 일정을 세분화하였다. 위 두 개를 잘..
[화이트보드 동시편집 프로젝트] 2. 문서화 문서화를 도전한 이유코드에 대해서 클린 코드에서 배웠다면, 좋은 개발 문화에 대해서는 "구글 엔지니어는 이렇게 일한다"에서 배웠다.굉장히 많은 충격을 받았지만, 그 내용 중 일개 팀원인 내가 도입할 수 있는 건 별로 없었다. 대부분은 C레벨이나 팀장 이상이 되어야 가능한 일이라 생각되었다. 그래도 할 수 있는 일이 문서화였다.짧게 문서화가 중요한 점을 설명하면, 버스 팩터의 값을 최소화 하는 것이다. 인수인계 없이 프로젝트에서 담당자가 사라졌을 때, 누군가 이 프로젝트를 이어서 진행할 수 있는 가?  난 현재 상황에서는 불가능하다 생각했다. 당시 파트에 프론트엔드 개발자는 오직 나 하나였어서, 기획/ 개발/ 디자인 정보를 공유할 대상이 없었다. 또한, 해당 프로젝트에서 몇 가지 조건이 엉켜있었다. 그 조..
[화이트보드 동시편집 프로젝트] 1. '클린 코드' 의 적용과 그에 따른 변화 실험적인 프로젝트이번 프로젝트를 시작할 때, 기존 프로젝트에 대해서 몇 가지 개선안을 적용하는 실험을 하기로 하였다. 1. 함수명을 길고 명확하게 짓기 : 기존 프로젝트는 깔끔한 네이밍을 많이 선호하였다. 하지만, 코드에서 가끔씩 너무 짧은 단어라 이해가 가지 않을 때가 있었다. '클린 코드'에서는 길더라도 깔끔하고 명확한 네이밍을 심사숙고해서 지으라 추천하였고 이를 적용하기로 하였다. 2. 함수를 최대한 작게 나누기(단일 책임 지향) : 클린 코드에서는 단일 책임을 추구하라하였고, 이 부분이 유지보수에 매우 유용하다 적혀있었다. 이 부분에서 공감되는 부분이 있었기에 적용하기로 하였다. 추가적으로, 신문을 읽듯이 추상화하여 작성하기도 목표에 있었다. 3. barrel 방식을 버리고, 모든 폴..
[화이트보드 동시편집 프로젝트] 0. 회고 시작 1월부터 시작한 이번 프로젝트가 1차 종료되었다. 이번에 내가 진행했던 프로젝트는 화이트보드 동시 편집 프로젝트로, 다른 유저와 동시 편집이 되는 필기 어플을 만들었다. 대중적인 예시를 들면 실시간 동시편집이 되는 굿노트를 만들었고, 정말 심하게 많이 과장하면 만들면 피그마 / 구글 슬라이드와 비슷한 제품을 만들었다. 피그마의 발 끝에도 못 미치지만, 점 하나 정도는 따라갔다 해도 되지 않을까? (점이라도 찍었으니, 반은 한 거아닌가..) 사이트 링크 하나 올려두면 진짜 멋있을텐데, 이 프로젝트는 회사 내부 사정으로 한 동안은 공개되지 않는다. (당연히, 제품의 이미지도 공개할 수가 없다 ㅠㅜ) 하지만, 정말 많은 일이 있었고 너무 많이 배웠기 때문에 이에 대한 회고를 지금 꼭 남겨야겠다는 생각을 했다...

티스토리툴바