폴더 구조
-
서비스가 커지면 그 만큼 기능도 많아지면서 폴더 수가 많아지게 됨
-
따라서 이를 큰 그룹에 하나로 묶어주면 관련된 기능들이 모두 해당 폴더 안에 들어가면서 유지보수에 굉장히 유리해짐
-
주소의 가독성도 좋아짐 (해당 주소의 각 내용은 모두 큰 그룹과 관련된 페이지임을 알아차릴 수 있기 때문)
폴더구조 예시
- 위의 경우, boards 라는 큰 그룹 안에는 게시글과 관련된 페이지, 기능들이 폴더로 정리되어 있음
- 이 경로를 토대로 주소가 만들어지는데 그룹으로 묶어서 가독성이 좋아짐
ex.
-freeboard_frontend/boards = 페이지 목록
-freeboard_frontend/boards/new = 게시글 작성 페이지
-freeboard_frontend/boards/[boardId] = 작성한 게시글 페이지
+a) 게시글 [수정] 시 페이지 경로
-
게시글 생성 시에는 그냥 입력한 값에 맞게 API 요청을 하는 것이기에 별다른 정보 필요 X
-
BUT! 게시글을 수정하려면 수정 페이지로 이동해야 하는데 이때 그 특정하는 게시글에 대한 정보가 필요(ex. Id_number...)
-
따라서
...frontend/boards/[boardId]/edit이런 식으로 작성해야 함
*라우팅 될 때(수정 페이지로 넘어갈 때) [boardId]를 통해 query: 에 Id값이 담기고 이를 이용해 id로 특정 게시글 fetch(조회) 가능
실무용 폴더구조(폴더 체계화, 정리방식)
1. Container / Presentational 패턴 =[고전 방식]
2. Hooks 패턴 = [최신 방식]
3. 아토믹 패턴 = [부품(컴포넌트)을 조금 더 체계화하는 방식]
Container / Presentational 방식
- Container = Javascript 가 작성되는 부분
- Presenter = HTML(JSX) 가 작성되는 부분
Container, Presenter 방식 사용 예시
- 각각의 파일을 만든다음 Container, Presenter 부분을 복사해서 각 파일에 붙여넣음
- 위와 같이 Presenter의 function 이름을 Container에서 import로 경로설정하고 가져옴
- 이를 Container 내의 return문 안에
<BoardWrite />이런 식으로 작성
*Container 안에 Presenter가 담기게 됨
+a) 여기서 Container은 부모 컴포넌트, Presenter은 자식 컴포넌트가 됨
-결과적으로 각 자식요소들은 부모요소에 import 되어 사용되며 합해지고, 모든 컴포넌트가 합해진 page는 app.js에 전달되어 최종적으로 합해져서 화면에 표출됨
props
-
컴포넌트를 나누게 되면 데이터, 기능의 연결또한 끊어짐 (ex. 실행함수, 변수,..)
-
이 문제를 props를 통해 부모에서 자식으로 넘겨줘서 해결 가능
-
porps = 부모 컴포넌트가 자식 컴포넌트에게 물려주는 변수, 함수 (역으로 전달은 불가능 X)
*React는 단방향 데이터 흐름이기 때문
(단방향 구조 = 부모에서 자식은 가능, 자식에서 부모는 불가능 / 단방향구조로 에러를 쉽게 캐치하고 가독성이 좋음) -
부모가 자식에게 넘겨줄 때 props는 객체 형태로 묶여서 넘겨짐
1. 부모에서 props 내려주기
//부모 컴포넌트 _ container 부분
const BoardWrite = ()=>{
const [writer, setWriter ] = useState()
const handlechangeWriter = (e)=>{
writer = e.target.value
setWriter(writer)
}
return(
// 자식 컴포넌트 _ presenter 컴포넌트
// 본격적으로 props를 내려주는 부분입니다.
<BoardWriteUI propsName={handlechangeWriter}/>
)
}-
return 문 안의 자식 컴포넌트에 위와 같이 작성해서 넘겨 줌
ex.aaa = {handlechangeWriter}=> [aaa 라는 이름으로 함수 넘김]
+a) props는 넘길 때
props={propsName: handlechangeWriter}형태의 객체로 넘어감
+a) props 는 여러 개 넘길 수 있음
2. 자식에서 props 받아오기
//자식컴포넌트 _ presenter 부분
//파라미터 부분에 props를 적어주셔야 받아 올 수 있습니다.
const BoardWriteUI = (props)=>{
return(
<Wrapper>
<Writer
type = "text"
placeholder = "작성자를 적어주세요"
// 본격적으로 props를 내려받는 부분입니다.
onChange = {props.propsName}
/>
</Wrapper>
)
}-
매개변수 자리에 props 넣어줘야 받아올 수 있음
-
props는 객체형태로 넘어오기 때문에 사용할 때 객체의 속성을 꺼내오는 것처럼 사용해야 함
ex. onChange={props.propsName}
+a) 구조분해 할당으로 props 받기
//구조분해 할당으로 props 받아오기
//기존 파라미터 부분에는 props라고 적어 props의 모든것을 받았습니다.
export const function BoardWrite({handleInput, handleChange}){
//기존 방법은 props.handleInput , props.handleChange 입니다.
<input onChange={handleInput}
<button onClick={handleChange}
}-
const {a,b} = obj{a: 123, b:456}=>a = 123, b = 456 -
구조분해할당을 적용하여 객체형태의 인자로 들어오는 props에서 { } 로 해당하는 요소만 뽑아서 가져올 수 있음
export VS export default
-
import 해서 가져올 때 { }를 사용하는 경우가 있고, 그냥 가져오는 경우가 있음
-
이 때 { } 사용 여부는 export 했느냐, export default 했느냐에 따라 결정됨
-
export = 한 컴포넌트 안에서 여러 개를 내보낼 때 사용
-여러 개를 보내기 때문에 import 해서 사용 시 { } 로 그 중 필요한 것들만 고름
-한 번에 묶어서 import 할 땐ipmort * as abc from "../BoardWrite.styles(경로)"로 가져옴
[styles 폴더 안 emotion의 모든 css 속성을 * 라는 이름으로 가져와서 abc 라는 이름으로 바꾼다]
- export default = 한 컴포넌트 안에서 한 개만 내보내기 때문에 { } 필요 없음
*(결국 컴포넌트 내에 1개만 존재, import시 이름이 바뀌어도 상관 X)
