프로젝트 리팩토링을 하던 중 폴더 구조를 제대로 정하고 가자는 의견이 나왔다.
가장 논쟁이 많았던 부분이 image 파일들을 public 폴더에 넣어야하는지
아니면 src 폴더에 넣어야 하는지였는데,
결론을 먼저 말하자면 src폴더에 image파일들을 넣게 되었다.
나는 public 폴더에 image 파일들을 넣자는 주장이었는데 이유는
public 폴더안에는 정적 파일(index.html을 비롯한 html 파일, img 등)이 들어가고
src 폴더에는 개발하면서 작업하는 파일 (index.js, 그 외 리액트 컴포넌트 같은 js 파일, css 파일 등) 대부분이 들어간다고 생각했기 때문이다.
하지만 이는 이미지 용도에 따라 다르다는 것을 간과했다.
따라서 정확히 해당 폴더는 무엇이 들어가야 좋은지 알아보게 되었다.
public 폴더
public 폴더는 앱이 컴파일될 때 싸용하지 않는 모든 것을 담는 곳이라 생각하면 된다.
장점으로는 절대 경로 사용이 가능해서 import할때, ../../ 이런 상대경로로 써주지 않아도 되므로 경로가 하나 바뀔 때마다 수정하지 않아도 된다.
공식문서에서는 public 폴더를 사용하는 이유로
- 빌드시 웹팩이 파일 이름을 바꾸지 않게 하기위해서
- 동적인 경로 참조로 수천개의 이미지들을 다룰 때
- 번들되는 코드 외에서 작은 스크립트를 포함하고 싶을 때 (압축이 필요없는 경우)
- 웹팩과 호환되지 않는 라이브러리를 사용해서
이렇게 네가지를 제시하고있다.
src 폴더
위에서 설명하였듯이 개발하면서 작업하는 동적이 파일들이 들어가 있어야 하며, 컴포넌트 안에서 사용하는 이미지는 src폴더에 있어야 하지만 파비콘과 같이 앱 밖에서 사용하는 이미지는 public 폴더에 있어야 한다.
src폴더에서 require를 통해서 가져 온 이미지가 갖는 장점으로는
- 파일을 찾지 못하는 경우, 404 오류 대신 컴파일 단계에서 에러를 잡을 수 있다
- 추가 네트워크 요청을 피하기 위해 스크립트와 스타일시트가 축소되고 함께 번들된다.
- content hash가 파일명에 포함되기 때문에 브라우저가 오래된 버전(파일 수정 전)의 파일을 캐싱하고 있는 경우를 고려하지 않아도 된다. (파일이 변경되었을 때만 hash값이 변경된다)
- 서버 요청 횟수를 줄이기 위해 10,000 bytes 이하의 이미지는 path대신 data URL을 반환한다.
(bmp, gif, jpg, jpeg, png 파일에만 적용, SVG 파일 제외) - 이 때, 파일 크기 기준(10,000 byte)은 IMAGE_INLINE_SIZE_LIMIT 환경변수로 설정을 변경할 수 있다.
- webpack's asset bundling을 사용하면
src 폴더내의 파일들이 rebuilt된다!
즉 rebuild를 빠르게 하기위해 src내부의 파일만 webpack에서 처리되므로 src 폴더 안에 모든 JS, CSS 파일을 넣어야 한다. 그렇지 않으면 webpack에서 볼 수 없기 때문이다.
결론은 scr 폴더 안에!
public 폴더내에서는 파일이 후처리(post-process)되거나 경량화(minify)되지 않는 문제와, 컴파일 단계의 오류가 아닌 404 오류가 나고, 결과 파일명에 content hash가 포함되지 않기 때문에, 파일이 수정될 때마다 직접 파일명을 수정하거나 매개변수 쿼리를 추가해야 줘야하지만,
scr 폴더 내에서는 자바스크립트 모듈을 쓰듯이 static assets들을 import 할수 있고, 문자열 변수처럼 사용할수 있다.
path 대신에 data URI 를 리턴해서 서버 요청수를 줄일 수도 있다.
build 시 images 들을 build 폴더로 넣고 우리에게 정확한 경로를 제공한다.
코딩할때 오타내거나 삭제로 중요한 파일이 삭제될 때 컴파일에러를 제공해준다.
장래에 파일 컨텐츠가 바뀌더라도 다른 이름이 생성되기 때문에 long-term 캐싱에 대해 걱정할 필요가 없다.
정적애셋을 넣는게 필수는 아니지만 이런 점들을 때문에 많은 사람들이 src 폴더에서 이미지를 관리하는게 좋다는 의견을 내고 있다.
