[TIL/React] 2023/08/17

Validation에 대해 알아보자 🟠

1. 어디에서 🟢

전역 상태 관리와 유사하게, 유효성 검사 자체에 대한 독립된 directory가 필요하다고 판단했다. utils가 바로 그것이다.

2. src/utils/LogInValidation.js 🟢

LogInValidation.js는, 세 개의 함수(isValidLogIn, isValidEmail, isValidPassword)를 export한다.

2-1. isValidLogIn Fn 🟣

email이 입력되지 않았거나 password가 입력되지 않은 경우에, alert으로 '모든 필드를 입력할 것을 요구'하는 함수이다. 당연히 parameter로 email과 password를 받고 있다. email과 password라는 로그인의 모든 요소를 주관하는 함수이기에, 함수명을 isValidLogIn으로 지정했다.

2-2. isValidEmail Fn 🟣

isValidEmail 함수는 철저하게 email에 집중하는 함수이다. parameter로 email만 전달받는다. '@'가 포함되었는가, 이메일 주소에 대문자가 포함되었는가 따위의 유효성 검사를 진행한다. 여기에서 처음으로 if 문의 본질이 무엇인가에 대해 고민했다. 후술할 예정이다.

2-3. isValidPassword Fn 🟣

isValidPassword 함수에서는 '패스워드의 최소 길이와 복잡성 충족'에 관한 논의가 이어진다. || 연산자(or 연산자)를 적극 활용했고, alert을 띄우는 것은 이전 함수들과 동일하다.

3. if 문에 관한 고찰 🟢

if 문은 조건문으로서, 유효성 검사와 같이 수많은 조건을 나열하는 상황에서 주로 사용된다. 문제는 '조건'과 '나열'이라는 단어가 만나면 depth를 고려하지 않을 수 없게 되는데, 결국 '가독성을 어떻게 handling할 것인지'가 if 문의 본질과 연결된다.

프로그래밍은 글쓰기와 같아서, 호흡이 짧으면 이해하기 수월한 것이 사실이다. 하지만 depth가 얕다고 해서 반드시 좋은 코드인가? depth가 깊으면 마냥 '클린코드알못'이라고 비난하는 것에 정당성이 부여되는가?

공통적인 속성을 갖는 코드를 하나의 '문'으로 구성하는 탕평책이 필요하다. 이러한 논리는 비단 조건문에서만 유효한 것은 아니다. validation에 대한 함수를 하나에 파일에서 관리하고자 한 것, login과 email과 password로 함수의 성격을 구분한 점 등, 구현 자체를 관통하는 논리이다.

4. 회고 🟢

반복이 패턴을 만들고, 패턴이 패터슨의 일상을 견딜 만한 것으로 만든다. 패턴은 일상의 행동에 작은 전구를 일정한 간격으로 달아놓는 일이기에, 삶은 패턴으로 인해 조금이나마 빛나게 된다. (중략) 자기 안에서 무엇인가 정처 없이 무너져내릴 때, 졸렬함과 조바심이 인간을 갉아먹을 때, 목표 없는 분노를 통제하지 못할 때, 자기 확신이 그만 무너져내릴 때, 인간을 좀 더 버티게 해줄 것이다.

-인생의 허무를 어떻게 할 것인가 中