728x90

누군가 내게 이런 질문을 해주었고,

다시 한번 고민해보고 공부해볼 좋은 기회가 되었다.

(보다 정확한 공부를 위해 React Docs를 살펴보았다.)

 

useEffect

둘을 비교하기 위해서는 useEffect를 먼저 이해할 필요가 있다.

 

useEffect를 이렇게 설명할 수 있을것 같다.

1) 특정 조건이 발생할 때(인자),

2) 지정된 명령을 수행하라(실행함수).
3) 컴포넌트가 제거될때 수행할것이 있다면 return을 작성하라.

 

(구조)

useEffect(실행 함수, 인자);


(사용 예시)

useEffect(() => {

}, [])

useEffect(() => {
  return () => {
  }
}, [])

useEffect(() => {
  return () => {
  }
}, [state.user])

 

 

useEffect의 동작 기준

1. 인자가 빈 배열인 경우: 모든 레이아웃 배치와 그리기를 마친 후 실행됨

2. 인자가 빈 배열이 아닌 경우: 배열의 state나 props가 변경될 때 실행됨

 

 

모든 레이아웃 배치와 그리기를 마친 후 실행된다고 했는데,

이 부분에 대해서 더 자세히 살펴보자.

 

useEffect 상세 실행순서

1) component render가 시작됨

2) rendered component가 화면에 그려짐

3) useEffect가 실행됨

 

자, 여기까지 살펴보고아래의 코드가 동작했을 때

사용자가 어떤 경험을 하게될지 예상해보자.

const [username, setUsername] = useState('')
useEffect(() => {
  setUsername('홍길동')
}, [])

return (
  <p>{username || '비회원'}</p>
)

사용자 경험에 어떤 문제가 있었을지

대충 눈치챘을 것이다.

 

사용자는 비회원이 아님에도

비회원을 목격한 뒤 홍길동이라는 이름이 보여지는 것을

목겨하게 될것이다.

 

 

useLayoutEffect

이러한 상황을 위해 useLayoutEffect가 존재한다.

 

useLayoutEffect 상세 실행순서

1) component render가 시작됨

2) useLayoutEffect가 동기적으로 실행됨

3) rendered component가 화면에 그려짐

4) (useEffect가 실행됨)

 

실행 순서 덕분에 위와 같은 상황에서는

useLayoutEffect를 쓴다면

조금 더 좋은 사용자 경험을 제공할 수 있다.

 

 

 

그렇다면 언제 useEffect를 써야할까?

일반적으로는 useEffect를 쓰는것이 퍼포먼스 면에서 유리하다.

 

왜냐면 위에서 언급했듯이 useLayoutEffect는

동기적으로 동작하기 때문에 퍼포먼스면에서는

권장되지 않기 때문이다.

 

일반적으로 useEffect를 사용하도록 하며

특히나 구독이나 이벤트 핸들러의 설정 등의 상황에서는

useEffect를 통해 필요한 시점에서만 실행되도록 하고

메모리 누수 방지를 위해 return을 통해 구독 해지시키는 것이 좋다.

 

 


(번외)

그 외에 react를 처음 사용하다보면

한번쯤 useEffect로 인해 겪게되는 이슈가 있다.

 

"어? 왜 자꾸 상태 값이 초기값으로 나오지?"

 

Docs를 자세히 보면 위 문제의 원인을 확인할 수 있다.

원인은 바로 useEffect에서 다루는 state, props가 인자에서 누락되었기 때문이다.

(useEffect에서 변경된 state,props를 확인하려면 인자에 useEffect에서 다루는 모든 state,props가 있어야함)

 

이것을 달리 말하면,

useEffect에서 인자로 빈 배열을 받았다면

useEffect에서 다루는 state나 props는 항상 초기값을 갖는다는 뜻이다.

 

심지어 이 사항은

useEffect에서 호출하는 함수에도 모두 적용되는 사항이니

명확히 알고 사용해야한다.

 

 

 

(수정할 사항이 있다면 제발 알려주세요. 저에게 큰 도움이 됩니다.)

728x90
반응형
728x90

css를 수년간 써왔지만

처음 공부할때를 제외하고는

실무 사용과 관련해 정리해보지 못했다.

 

너무 일상적으로 사용해

체득되어 "당연하다"라고 생각하고 썼기때문.

 

분명히 이러한 사용법은

훗날 문제를 야기할것이라는 생각이들어

반응형 작업과 Flex에 대해 정리해본다.

 

1. Viewport

반응형의 시작은 Viewport이다.

Viewport는 웹페이지에서 사용자에게 보여지는 영역에 대한 속성을 말한다.

<meta name='viewport' content='width=device-width; initial-scale=1'>

웹개발을 했다면 누구나 봤을 위 코드.

vscode에서 기본 자동 생성 될만큼 핵심적인 meta 속성이라고 볼 수 있다.

 

Viewport의 요소들을 짚어보자

1. width: 브라우저 스크린의 기본 넓이를 말함

2. device-width: 디바이스의 가로 넓이를 말함

3. initial-scale: 페이지 접속시 보여질 화면 배율을 말함

4. maximum-scale: Viewport 최대 배율을 말함

5. minimum-scale: Viewport 최소 배율을 말함

 

2. media query

다음은 media query이다.

media query는 css 반응형 코드를 작성할 때, 기준을 잡는 역할을 한다.

미디어 유형 / 논리 연산자 / 특성
@media (max-width: 768px) & (min-width: 1024px) {
}

@media only screen (max-width: 768px) and (min-width: 1024px) {
}

@media only screen (max-width: 768px) and (min-width: 1024px) and (orientation: landscape) {
}

위와 같은 방식으로 쓸 수 있다.

그런데 보통 가장 위에 형태로 많이 쓰인다.

 

모바일에 작업의 중점을 둘것이냐

데스크탑에 작업의 중점을 둘것이냐에 따라

min-width, max-width 둘 중 하나만 사용하는게 일반적이다.

 

<-- 데스크탑 베이스 -->

// 랩탑 이상 (기본)
.content {
}

// 랩탑
@media (max-width: 1024px) {
  .content {
  }
}

// 태블릿
@meida (max-width: 768px) {
  .content {
  }
}

// 모바일
@media (max-width: 430px) {
  .content {
  }
}
<-- 모바일 베이스 -->

// 태블릿
@media (min-width: 431px) {
  .content {
  }
}

// 랩탑
@media (min-width: 769px) {
  .content {
  }
}

// 랩탑 이상
@media (min-width: 1025px) {
  .content {
  }
}

// 모바일 (기본)
.content {
}

 

차이점을 분명 알수있을것이다.

max-width: 화면 크기가 이것보다 작으면 적용하라

min-width: 화면 크기가 이것보다 크면 적용하라

 

이정도면 실무에 별 문제가 없지만

그래도 각 구성요소에 대해 알아본다.

 

* 미디어 유형

screen: 화면을 대상

all: 모든 디바이스를 대상

print: 인쇄 결과물, 인쇄 미리보기 문서를 대상

 

* 논리 연산자

and: 모든 쿼리가 참이면 적용

not: 모든 쿼리가 거짓이면 적용

,: 어느 한 쿼리라도 참이면 적용 (or)

only: 미디어 쿼리를 지원하는 대상만 적용

 

* 특성 (상태)
width: 너비

height: 높이

aspect-ratio: 가로/세로 비율

orientation: Viewport 방향

 

 

3. flex style

마지막으로,

최근 작업에서는 컴포넌트 배치 관련된 css는

항상 flex로 적용하고 있다. 그 만큼 편리하고 강력하다.

각 속성에 대해서 정확히 짚어놓고 가자.

display: flex;

 

display 속성중 하나인 flex.

flex를 적용하면 해당 태그는 방향에 대한 특성을 갖게 된다.

웹에서 flex의 기본 방향성은 가로축이다.

display: flex;
flex-direction: row; // 가로 배치에 대한 특성을 갖음
flex-direction: column; // 세로 배치에 대한 특성을 갖음

즉, 웹에서 flex의 기본 direction은 row라는 이야기이다.

 

 

그럼, 아래의 문제를 풀어보자.

1,2,3은 어떻게 배치될까?

<div>
  <ul style="display: flex;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

 

맞다

1 2 3

가로로 배치된다.

 

<div>
  <ul style="display: flex; flex-direction: column;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

이렇게 했다면

1
2
3

세로로 배치되었을 것이다.

 

 

여기까지 했으면

flex의 25%정도 이해했다고 보면된다.

지금까지 "방향성"이라는 특성에 대해 공부했다면

이번에는 내부 요소들을 "어떻게" 배치할 것인지에 대해 알아볼 차례이다.

 

내부 요소에 대한 배치 메인 특성으로는 2가지가 있다.

1. justify-content: flex-start / flex-end / center / space-between / space-evenly / space-around

2. align-items: flex-start / flex-end / center / stretch

 

justify-content부터 하나씩 알아보자.

먼저, 가로축 상태에서의 justify-content 참고

<div>
  <ul style="display: flex; justify-content: flex-start;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면
[123       ]
<div>
  <ul style="display: flex; justify-content: flex-end;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면
[       123]
<div>
  <ul style="display: flex; justify-content: center;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면
[   123    ]
<div>
  <ul style="display: flex; justify-content: space-between;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면
[1    2    3]
<div>
  <ul style="display: flex; justify-content: space-evenly;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면 - 전체 여백이 균일하게
[  1  2  3  ]
<div>
  <ul style="display: flex; justify-content: space-around;">
    <li>1</li>
    <li>2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면 - 요소간 여백이 균일하게
[ 1   2   3 ]

 

세로축 상태에서의 justify-content는

가로로 적용되던 속성이 세로로 적용된다고 보면 정확하다.

 

가로축 에서의 align-items도 알아보자

<div>
  <ul style="display: flex; justify-content: flex-start;">
    <li>1</li>
    <li style="height: 100px;">2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면 - 요소간 여백이 균일하게 (실제로는 2가 길게 세로 전체를 덮고 있다고 보면 되겠다)
|123       |
|          |
|          |
<div>
  <ul style="display: flex; justify-content: flex-end;">
    <li>1</li>
    <li style="height: 100px;">2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면 - 요소간 여백이 균일하게
|          |
|          |
|123       |
<div>
  <ul style="display: flex; justify-content: center;">
    <li>1</li>
    <li style="height: 100px;">2</li>
    <li>3</li>
  </ul>
</div>

* 예상 화면 - 요소간 여백이 균일하게
|          |
|123       |
|          |

 

세로축에서의 align-items는

가로축에서의 align-items에 적용되던 속성이 세로로 적용된다고 보면 정확하다.

728x90
반응형
728x90

React 개발을 하다보면

state, props로는 depth가 너무 깊어지는

props drilling문제가 발생하는 시점이 온다.

 

또한,

단계별 진행이나 페이지 변경 후에도 상태를 유지해야 하는 List뷰 등에서

어려움을 겪게된다.

 

이러한 문제들을 해결해주는 것이

global state관리를 도와주는 라이브러리들이다.

그 중에서 local global state라고 부르도록 하겠다.

 

주요 상태관리 라이브러리

1. Context API

2. Recoil

3. MobX

4. Redux

 

위 4가지 정도가 있는데,

1에서 4로 갈수록 러닝커브가 높다고 생각하는 바이다.

그럼에도 각 장,단점이 있으니 알아보도록 하자.

 

1. Context API

ContextAPI는 4가지 중에 유일하게
React 내장 상태관리 기능이다.

즉, 별도의 라이브러리 설치 없이 사용 가능하다는 말이다.

 

Docs를 보고 처음 사용 하는 사람도
쉽게 적용할 수 있는 수준이니

러닝커브 또한 낮다고 할 수 있다.

 

ContextAPI가 처음 나왔을때는

언어설정이나 색상테마 등

잘 변경되지 않는 상태를 관리할때 쓰였다.

 

그러나 지금은

전역상태 관리로 사용하던

지역상태 관리로 사용하던

개발자의 자유일뿐

상태 관리 기능으로써 충분한 지원을 하고있다.

 

참고

 

그럼에도 다른 라이브러리들을

추가 설치해 사용하는 이유가 있다.

 

 

2. MobX

언급할 내용은 MobX뿐 아니라

Redux, Recoil등 다른 라이브러리들을

사람들이 사용하는 이유이다.

 

4가지 모두 상태관리라는 컨셉을 가지고 있지만 그 안에서 나뉘는 개별 특징들이 있다.

그중에 내게 맞는 특징을 갖는 라이브러리를 택하면 되는것이다.

 

MobX는 전역상태관리 기능을 제공한다.

뿐만 아니라 상태 업데이트 로직을 View Component 밖에서(코드 분리) 할 수 있도록 도와준다.

Redux에 비해 적은 보일러 플레이트 코드, 직관적인 코드를 갖는다는 특징도 있다.

 

다만, MobX에서는 여러개의 Store를 둘 수 있는데

그로인해 예상치 못한 업데이트 등이 발생할 수 있다는 단점아닌 단점이 있다.

 

3. Redux

Redux도 MobX와 마찬가지로

전역상태관리 + 상태 업데이트 로직 분리를 돕는다.

 

하나의 Store를 갖는 특징으로

상태가 업데이트 될때 정확하게(직관적으로)

해당하는 상태를 갖는 컴포넌트들만 업데이트 된다는 장점이 있다. (유지보수의 편안함)

 

다만, Redux는 비동기 처리를 위해

thunk, saga 등 추가적으로 라이브러리들이 붙게되고

보일러플레이트 코드가 너무 많아진다는 단점을 가지고 있다.

 

4. Recoil

최근 각광받고 있는 Recoil은

react를 개발/운영하고 있는 Facebook(Meta)에서 개발한 만큼

가장 react 친화적이라는 장점을 가지고있다.

뿐만 아니라 매우 사용 방법이 매우 간단하고 직관적이다.

 

ContextAPI가 상태를 일일이 만들어야 하는 과정을 가진데 반해

Atom을 통해 매우 간결하게 상태관리를 할 수 있다.

캐싱을 통한 최적화 기능은 보너스이다.

 

 

 

최근,

이직 준비를 하며 많은 기업들에서 Recoil을 도입하고 있는것을 보게되었다.
사이드 프로젝트에 적용해 공부중인데 매우 합리적인 선택지라는 생각이 든다.

 

현직 개발자들은 대부분 현명하고, 최선의 선택을 하기위해 노력하는 만큼

Recoil이 사랑받는데는 분명히 이유가 있다.

 

 

 

(수정할 사항이 있다면 자유롭게 알려주세요. 저에게 큰 도움이 됩니다.)

728x90
반응형
728x90

MVC 패턴

구성

1. Model: 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 로직을 담당

2. View: 사용자에게 보여지는 UI 담당

3. Controller: 사용자의 입력을 받고 처리하는 부분

 

동작 방식

View에서 사용자가 액션

-> Controller에 액션이 전달됨, Model이 처리해야될 일이면 Model로 액션을 전달

-> Model이 데이터를 처리

-> Model이 View로 업데이트된 데이터를 전달

 

특징

1. Controller는 여러개의 View를 선택할 수 있는 1:N 관계를 갖음

2. Controller는 View에 직접 데이터를 전달하지는 않음

 

장점

가장 단순하고 많이 쓰이는 보편적인 패턴

 

단점

View와 Model 사이의 의존도가 높음 -> 앱이 커지고 복잡해질수록 유지보수가 어려워짐

 

 

------------------------------------

 

 

MVP 패턴

구성

1. Model: 어플리케이션에서 사용되는 데이터와 데이터를 처리하는 로직을 담당

2. View: 사용자에게 보여지는 UI를 담당

3. Presenter: 사용자의 요청을 처리하고 View와 Model을 연결

 

동작 방식

View에서 사용자가 액션

-> Presenter에 액션이 전달됨, Model이 처리해야될 일이면 Model로 액션을 전달

-> Model이 데이터를 처리 후 Presenter로 응답

-> Presenter가 Model의 응답을 View로 전달

 

특징

1. MVC와 달리 Model과 View과 분리됨

2. 오직 Presenter를 통해서만 상태나 변화를 알려줄 수 있음

3. Prenseter와 View가 1:1 관계를 갖음

 

장점

View와 Model의 의존도를 없앰

 

단점

View와 Presenter의 의존도가 높아져, MVC 패턴의 문제를 그대로 가지고 있음

 

 

------------------------------------

 

 

MVVM 패턴

구성

1. Model: 어플리케이션에 사용되는 데이터와 데이터를 처리하는 로직을 담당

2. View: 사용자에게 보여지는 UI를 담당

3. View Model: View를 처리하기 위해 만든 View를 위한 Model, View를 나타내기 위한 데이터와 데이터를 처리하는 로직을 담당

 

동작 방식

Model을 가지고, Command Design Pattern을 통해 View를 위한 ViewModel을 생성

-> ViewModel 인스턴스를 View에 props로 넘겨줌

-> View와 Model이 Data-binding됨

-> View에서 사용자가 액션

-> View Model에 액션이 전달됨, Model이 처리해야될 일이면 Model로 액션을 전달

-> Model이 데이터를 처리 함

-> Presenter가 Model의 응답을 View로 전달

 

특징

1. Command Design Pattern과 Data-Binding, 두가지 패턴을 사용하여 구현됨

2. View와 View Model, View와 Model 간의 의존도 문제가 위 두가지 패턴으로 해소됨

 

장점

의존성이 사라져 각 부분을 모듈화하여 개발할 수 있음

 

단점

View Model을 잘 설계하는 것이 어려움

728x90
반응형
728x90

개발을 시작할때 한번쯤 공부하지만
세월이 지나면서 잊게되는 HTML 로드 순서.
그치만 웹 개발자라면 잊어서도 안되고 계속해서
공부해야한다.
브라우저는 계속 발전하기 때문에 새로이 업데이트 되는 사항들을 놓치지 말자.

--------------------------------

HTML이 브라우저에 의해 호출되면
기본적으로 위에서 아래의 순서로 파싱된다.

<html>
  <head></head>
  <body>
    <div>
      <p>Hello world</p>
    </div>
  </body>
</html>

위와 같다면 문제없이 위에서 아래로 파싱되며
끝이 난다.

문제는 script 태그를 만났을때다.
브라우저는 HTML을 읽다가 script 태그를 만나면
파싱을 중단하고 script태그를 다운로드 및 파싱한다.

여기서 두가지 문제가 발생한다.

[ 브라우저가 script 태그를 만났을 때, 발생할 수 있는 두가지 문제 ]
1. script 태그가 다운로드 되고 실행되는 것을 기다리느냐, 페이지 로딩이 지연된다.
2. script 태그가 하단의 dom 요소들 보다 먼저 파싱되기 때문에, 
   script 태그에서 dom요소에 접근하여 이벤트 핸들러를 등록하는 등의 행위가 불가능하다.


2번의 문제로 HTML, Javascript를 처음 배울때면
body 가장 밑쪽에 script태그를 배치하라고 배우게된다.


하지만, 그것만으로 모든 문제가 해결될까?
그것은 아니다.
페이지에서 핵심적으로 작용하는 script가 최하단에서 다운로드 및 파싱된다면
사용자가 끔찍한 화면을 본다거나,
에러상황을 마주하게 될 수 있다.

그리고 최신 웹사이트들은
써드파티 라이브러리를 많이 사용하다보니
script 태그를 예전보다 더 적극적으로 많이 사용하게된다.

혹은, 번들러를 통해 빌드하게되면
html에 상당히 많은 script 태그가 자동으로 추가된다.

페이지에 필수적으로 적용되는 script태그를
계속해서 페이지 최하단에 위치시킬것인가?


--------------------------------


그래서 script 태그에는 defer와 async라는 속성이 존재한다.
먼저, defer를 알아보자.

<html>
  <head>
    <script defer src="cdn-subway-tastgood.js" />
  </head>
  <body>
    <div>
      <p>Hello world</p>
    </div>
  </body>
</html>

위 처럼 defer가 적용된 script가 있을때
HTML의 로드 순서는 어떻게될까?

script는 완전히 독립적으로 실행되게 된다.
브라우저는 HTML을 읽다가 script를 만나도
파싱을 중단하지 않고 계속해서 아래로 파싱해나간다.

HTML을 읽다가 script 태그를 마주친 순간부터
script는 백그라운드(Background)에서 다운로드 된다.
defer script의 실행은 domContentLoaded 직전에 실행된다.
(* domcontentloaded 이벤트는 초기 HTML 문서를 완전히 불러오고 분석했을 때 발생하는 이벤트이다.)

따라서, 어느정도 실행 순서가 보장되며
페이지 로딩 속도를 지연시키지 않기 위한 방법이라고 볼 수 있다.


그렇다면 async는 어떨까?

<html>
  <head>
    <script async src="cdn-lotteria-tastgood.js" />
  </head>
  <body>
    <div>
      <p>Hello world</p>
    </div>
  </body>
</html>

async가 적용된 script를 만났을때 역시
파싱이 중단되지 않고 진행된다.
마찬가지로, 백그라운드에서 script가 다운로드된다.

async는 defer와 실행순서에 있어 차이가 있는데,
defer가 domcontentloaded 직전의 실행 시점을 갖는 반면
async는 백그라운드에서 다운로드가 완료된 순가 실행된다.
따라서, async는 그 실행순서가 보장되지는 않는다.

그래서 async는 써드파티 스크립트 중에서도
페이지의 핵심 기능과 독립적인 기능으로 동작하는..
예를들어, 광고나 페이지 방문자수 카운터 등에 사용된다.

728x90
반응형
728x90

에러상황

[!] The following Swift pods cannot yet be integrated as static libraries:

The Swift pod `FirebaseCoreInternal` depends upon `GoogleUtilities`, 
which does not define modules. To opt into those targets generating module maps 
(which is necessary to import them from Swift when building as static libraries), 

you may set `use_modular_headers!` globally in your Podfile, 
or specify `:modular_headers => true` for particular dependencies.

새프로젝트에서 위 같은 에러가 발생했다.

use_frameworks를 주석처리하니

dyld: Library not loaded
...

이와 같은 실행 오류가 발생했다.

많은 시행착오를 걸쳐 발견한 해결법은 아래와 같다

 

해결책

 

0) react-native version
version >= 0.70 인 경우 < 0.7 로 변경 (ex 0.65)

 

1) 맥 os 기분, 아래 경로에서 프로젝트 폴더 제거

/Library/Developer/Xcode/DerivedData

 

2) Podfile 확인/수정

require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

use_frameworks! :linkage => :static

platform :ios, '12.4'
install! 'cocoapods', :deterministic_uuids => false

target 'myapp' do
  config = use_native_modules!

  # Flags change depending on the env values.
  flags = get_default_flags()

  use_react_native!(
    :path => config[:reactNativePath],
    # to enable hermes on iOS, change `false` to `true` and then install pods
    :hermes_enabled => flags[:hermes_enabled],
    :fabric_enabled => flags[:fabric_enabled],
    # An absolute path to your application root.
    :app_path => "#{Pod::Config.instance.installation_root}/.."
  )

  target 'myappTests' do
    inherit! :complete
    # Pods for testing
  end

  # Enables Flipper.
  #
  # Note that if you have use_frameworks! enabled, Flipper will not work and
  # you should disable the next line.
  # use_flipper!()

  post_install do |installer|
    react_native_post_install(installer)
    __apply_Xcode_12_5_M1_post_install_workaround(installer)
  end
end

 

3) pod 갱신

Podfile.lock 제거
Pods 폴더 제거

pod install

 

 

4) 실행 및 확인

npm run ios
728x90
반응형
728x90

Cocoapods version 1.9+ allows linking of Swift static libraries, add the following command to your Podfile:

use_frameworks! :linkage => :static

 

전체 코드르 확인

require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

use_frameworks! :linkage => :static

platform :ios, '12.4'
install! 'cocoapods', :deterministic_uuids => false

target 'testApp' do
 
end
728x90
반응형
728x90

테스트 코드를 어떻게 작성해 나갈지에 대해 공부해보고 있다.

 

공부하며 알게된 지식을 정리해본다.

 

NOTE 1.

테스트 코드가 나오려면 명세서가 있어야됨
따라서, 요구사항이 주어지면
1. 요구사항을 이해하는데 시간을 들여 요구의 숨겨진 의도는 없는지 이것으로 달성하고자 하는 목표는 무엇인지
충분히 심사숙고한다.
2. 어떻게 달성할지에 대해서 명세서를 직접 작성해보고 그것에 맞춰 테스트 코드를 작성한 뒤 본 코드를 작성한다.
3. 명세를 작성할때는 어떤 경우에 성공하는지, 혹은 어떤 경우에 실패하는지 모든 가능한 상황을 아울러 작성하도록 하며 기대되는 결과값에 기반해 테스트가 정상인지 확인하면 된다.
728x90
반응형
728x90

mac m1에 mongodb를 설치하는 과정에

작은 불편함을 겪었다.

 

각자 원하는 버전 혹은 권장버전의

mongodb 사이트에 접속한 뒤 아래의 과정을 밟아보자.

https://www.mongodb.com/docs/v4.4/tutorial/install-mongodb-on-os-x/

 

1. homebrew가 설치되어 있어야한다.

2. Install the Xcode command-line tools by running the following command in your macOS Terminal

xcode-select --install

3. Tap the MongoDB Homebrew Tap to download the official Homebrew formula for MongoDB

brew tap mongodb/brew

4. To update Homebrew and all existing formulae

brew update

5. To install MongoDB

// 자신이 원하는 버전
brew install mongodb-community@4.4

6. 

brew --prefix

7. 

brew info mongodb-community@4.4

---> 결과
echo 'export PATH="/opt/homebrew/opt/mongodb-community@4.4/bin:$PATH"' >> ~/.zshrc
라는 메시지 확인가능

8. zshrc 수정

export PATH="/opt/homebrew/opt/mongodb-community@4.4/bin:$PATH"

9. 실행

brew services start mongodb-community@4.4

10. 몽고 connect

mongo
728x90
반응형
728x90

react-native 개발을 하다보니

zulu jdk11 버전으로 jdk를 변경하게 되었다

 

jdk1.8등 기타 버전이 아닌

zulu jdk11을 설치하는 방법을 알아본다.

 

1.

brew tap mdogan/zulu

2.

brew install zulu-jdk11

3. 설치 완료 확인

java --version

4.

nano ~/.zshrc

// zshrc 맨 하단
export JAVA_HOME=`/usr/libexec/java_home -v 11`
export PATH=$PATH:$JAVA_HOME/bin

5. 변경된 zsh 적용

source ~/.zshrc

6. 잘 적용됐는지 확인

echo $JAVA_HOME
728x90
반응형