주식 탭, 혜택 탭 >> 웹으로 구현

 

웹 서비스에서 가장 다루기 어려운 부분은 무엇인가?

>> 비동기 프로그래밍

- 순서가 보장되지 않는 상황에서

- 좋은 사용자 경험을 위해 필수 

 

자바 스크립트에서는

- Callback

- Promise

- RxJS

를 이용해 비동기적인 상황을 다루고 있다.

 

좋은 코드의 원칙을 알아보자

 

(1)

x.foo.bar.baz에 안전하게 접근하기 위한 코드

>> 함수가 하는 일에 비해 코드가 너무 복잡하다.

>>> 각 프로퍼티에 접근하는 핵심 기능이 코드로 잘 드러나지 않는다.

 

Optional Chaining 문법을 활용한 동일한 함수 ▼

- 코드가 간결하다

- 성공한 경우를 생각하는 x.foo.bar.baz와 문법적 차이가 크지 않다.

- 함수의 역할을 한눈에 파악할 수 있다.

 

(2)

자바스크립트에 Propmise가 없던 시절 비동기 처리를 하기 위한 코드

비동기 처리를 위해 callback 사용

- 성공하는 경우와 실패하는 경우가 나뉘어 있지 않다.

- 코드를 작성하는 입장에서 매번 에러 유무를 확인해야한다.

 

async/await을 사용한 같은 함수 ▼

- 성공하는 경우만 다룸

- 실패하는 경우에 대한 처리는 외부에 위임 가능

 

좋은 코드의 특징

성공하는 경우와 실패 경우를 분리해 처리할 수 있다.

비즈니스 로직을 한눈에 파악할 수 있다.

 

 

 좋지 않는 코드

 

실패하는 경우에 대한 처리를 외부에서 위임하게 만들어보자

 

 

복잡한 상황

 

2개의 비동기 리소스를 가져올 떄의 상태

 

 

성공하는 경우에 집중하여 코드의 복잡도를 낮춘다 

일반적으로 작성하는 동기 로직과 큰 차이가 없다.

 

리액트가 비동기 처리가 어려웠던 이유

 

이에 대한 해결책으로 리액트 팀이 제시한 것이 바로

 

목표로 하는 코드 

- 컴포넌트는 성공한 상태만 다룬다

- 로딩 상태와 에러 상태가 분리되어 외부에서 다룬다.

- 동기와 거의 같게 사용할 수 있게 된다.

 

React Suspence는 위와 같은 useAsycnValue 같은 hook을 쉽게 만들 수 있도록 Low-Level API를 제공한다.

 

로딩 상태와 에러 처리를 컴포넌트가 사용되는 곳에서 쓴다.

 

비동기 호출을 하는 함수나 컴포넌트를 가운데 두고, 실패하는 부분을 처리하는 부분을 감싸게 만든다. 

 

fallback으 무엇인가?

 

사용하는 방법

 

runPureTask의를 통해 비동기 함수를 동기적으로 작성할 수 있다.

 

 

 

 

Recoil과 Suspense 사용해보기

 

 

Hooks를 사용하면서 얻은 이점

 

Suspense의 이점

 

 

 

를 이용한 사용자 경험 향상

'기초부터 다시 > SLASH' 카테고리의 다른 글

SLASH 21 - 실무에서 바로 쓰는 Frontend Clean Code  (1) 2024.01.29
SLASH 21 - TDS로 UI 쌓기  (1) 2024.01.28

클린코드 >> 명확한 이름, 중복 줄이기

 

1. 실무에서 클린 코드의 의의

안좋은 코드 : 흐름 파악이 어렵고, 도메인 맥락 표현이 안 되어, 동료에게 물어봐야 알 수 있는 코드 

 

실무에서의 클린 코드의 의의 == 유지 보수 시간의 단축

 

2. 안일한 코드 추가의 함정

타당하고 자연스러운 코드 추가도 나쁜 코드일 수 있다 

>> 하나의 목적인 코드가 흩뿌려져 있기 때문이다.

>> 하나의 함수가 여러가지의 일을 하고 있다.

>> 함수의 세부 구현 단계가 제각각이다.

 

리팩토링 

>> 함수의 세부 구현 단계를 통일한다. 

>> 하나의 목적인 코드는 뭉쳐두자.

>> 함수가 하나의 일만 하도록 쪼개자

 

클린코드 != 짧은 코드

== 원하는 로직을 빠르게 찾을 수 있는 코드

 

- 원하는 로직을 빠르게 찾는 방법은? 

1. 응집도 : 하나의 목적을 가진 코드가 흩뿌려져 있으면 안된다.

2. 단일 책임 : 함수가 여러가지 일을 하면 안되고 하나의 일만 해야한다.

3. 추상화 : 함수의 세부 구현 단계가 통일되어야 한다.

 

 - 응집도

무조건 한 군데로 뭉치는 것이 좋은 것은 아니다 >> 예를 들어 커스텀 훅으로 목적이 같은 코드를 묶어 그 커스텀 훅만 부른다면, 어떤 팝업을 띄우는지 바로 파악하기 힘들기에 오히려 코드 파악이 어려워진다.

 

--> 그렇다면 뭉쳐야 하는 것은 무엇일까 >> 당장 몰라도 되는 디테일이다. 

즉 코드 파악에 필수적인 핵심 정보는 뭉치면 안된다.

 

읽기 좋게 응집하는 법

- 남겨야할 핵심 데이터와 숨겨도 될 세부구현 기분을 잘하기

- 핵심 데이터는 밖에서 전달 나머지는 뭉치자

>>> 이렇게 핵심 데이터만 전달받고 세부 구현은 뭉쳐 숨겨 두는 개발 스타일이 "선언적 프로그래밍"이다

선언적 프로그래밍을 사용한다면, 재사용에 용이하고 무엇을 하는 함수인지 빠르게 이해할 수 있다

 

뭉치지 않은 것은 "명령형 프로그래밍"이라고 한다. 세부 구현이 모두 노출되어 있어 커스텀이 쉽지만 바로 어떤 함수인지 파악하기 힘들고 재사용이 어렵다.

 

- 단일 책임

하나의 일을 하는 뚜렸한 이름의 함수를 만들자

 

함수의 세부 구현으로 생성된 기능이 함수명을 통해 바로 파악할 수 읶게 해야한다.

>> 한 가지 일만 하는 명확한 이름의 함수를 만들자

>> 한 가지 기능만 하는 리액트 컴포넌트를 만드는 방법도 있다.

 

조건이 많아진다면 한글도 유용하다.

 

 - 추상화

 

로직에서 핵심개념 뽑아오기

 

프론트엔드 코드의 추상화 예시

컴포넌트

 

함수

 

 

상황에 따라 적절하게 추상화하면 된다.

 

추상화 수준이 섞여 있으면 코드 파악이 어렵다

 

>> 비슷한 수준의 추상화들로 변경

 

 

클린 코드를 하기 위한 액션 아이템

1. 담대하게 기존 코드 수정하기

2. 큰 그림 보는 연습하기 : 그 떄는 맞고 지금은 틀릴 수 있다.

3. 팀과 함께 공감대 형셩하기 : 명시적으로 이야기를 하는 시간이 필요

4. 문서로 적어보기 : 이 코드가 향후 어떤 점에서 위험할 수 있는지와 어떻게 개선할 수 있는 지 생각해보자

TDS : Toss Design System

- 토스 제품 구성에 공통적으로 사용하는 디자인 시스템  

- 보다 효율적으로, 아름답고 일관된 UI 개발

- 반복되는 코드를 작성하는 시간 절약

- View, 색상, 글꼴, 인터렉션과 애니메이션 등

별도 모듈로 관리하고 있기 때문에 다른 제품을 개발할 때도 쉽게 적용 가능

 

TDS를 구성하는 것들

- 컬러 & 리소스

Color

컬러 팔레트화 하여 사용 ex) 파란색 >> blue_진한정도표시

> 색상 코드를 직접 찍지 않고 이름으로 커뮤니케이션 가능하도록 관리

Day와 Night 모드 대응 

> 같은 이름의 색상을 night 리소스로 별도 관리

 

규칙화된 팔레트의 힘

- 토스팀에서 개발되는 모든 플랫폼 > 같은 TDS 색상을 바라보고 있음

> 서버로부터 UI를 그리기 위한 색상을 전달 받을때 Color Hex Code가 아닌 TDS 색상의 이름 내려받음

> 모두 공통된 이름을 기준으로 색상 파싱하여 적용 >> 다른 팀원과의 커뮤니케이션 증가와 색상 값의 자연스러운 최신화 가능

 

TDS 팔레트 색상 값 원격 서버에 존재 > 빌드 타임에 다운로드 받아 앱 리소스에 generate

 

Resources

토스 제품들의 이미지 리소스는 4가지로 구분됨

토스 리소스 센터에 정의

경우에 따라 벡터 이미지와 비트맵 이미지 혼용

- Icon

- Lottie

- Logo

- Illustration

 

로고와 일러스트 이미지 원형 그대로 사용

아이콘 로띠 이미지는 TDS에 정의된 이미지 리소스에 tint 사용하여 활용

 

 

- 스타일

컴포넌트화된 각종 스타일(UI에 활용되는 스타일 및 인터렉션까지 개별적인 컴포넌트처럼 사용)

 

TDS에서 Button. BottomSheet 등에서 원의 호로 처리하고 있는 둥근 모서리

> 베지어 곡선을 그려내는 방식으로 구현

 

*베지어 곡선 : 곡선으 최소 2개의 제어점 세트로 정의되며 두 개의 가상 선을 그리고 첫 번째 도우미 선의 시작점과 두 번째 도우미 선의 마지막 점으로 이동하는 가상의 세번째 섬을 따라가며 그어지는 곡선

 

TDS의 ScrollView 

어떤 View가 어떤 위치에 배치되어 있는지에 따라 상단과 하단의 Fading Edge를 다르게 적용해야 하는 일이 있음

(파란색 : Fading Edge 적용/ 붉은색 : 적용 x)

ScrollVIew 상속 받은 후 각 방향의 Fading Edge를 enum으로 받음 >> TDSScrollView

(기존의 동작하던 코드를 최대한 손대지 않고 문제를 해결하는 것을 중요시 여김 >> Custom Inflater 사용 > inflate 시점에 TDSScrollView로 대체 될 수 있도록 설계)

 

 

- 인터렉션

TDS가 유저에게 직접적으로 피드백을 주는 햅틱 피드백

햅틱 피드백

 

 

- 컴포넌트

UI 컴포넌트

택스트 이미지 등 여러 가지 작은 단위로 쪼개어 구성한 TDS 컴포넌트들을 연결하고 조합하여 만든 최종 결과

 

추가 요소 혹이니 기능이 필요할 경우 디자이너 개발자 구분 없이 자유롭게 추가 가능

단지 쌓아가는 것으로 옆의 디자인을 만들 수 있음

 

 

TDSL

 TDS 자체로 하나의 완성된 기능을 수행하기 때문에 DSL화해 간단하고 반복되는 UI를 구성한

+ Recent posts