What is the Best File Structure for Frontend Application?

Domain Driven

Design(feature-based)

Pros

• easily scalable, readable, and maintainable
• easier to bring new developers to the project, as the structure is clear and understandable
• Features of the application are totally separated, so if developers have to fix bugs in one part of the application, Easy.

Cons

• take some more time to understand the main domain in the application’s business logic

현 프로젝트 구조 DDD

페이지 가 곧 하나의 비즈니스 Feature 로 역할

TECH ASSUMPTIONS

Since this article will be opinionated, I'll make some assumptions about what technology the project will be using:

• Application - React (Hooks)
• Global state management - Redux, Redux Toolkit / 다른 상태관리 라이브러리 도 고려 필요.
• Routing - React Router
• Styles - Mui style 사용. styles.ts
• Testing - Jest, React Testing Library

Directory Structure

• assets - global static assets such as images, svgs, company logo, etc.
• components - global shared/reusable components, such as layout (wrappers, navigation), form components, buttons
• services - JavaScript modules
• store - Global Redux store
• utils - Utilities, helpers, constants, and the like
• views - Can also be called "pages", the majority of the app would be contained here

Components

• Component.tsx - The actual React component
• Component.styles.js - The mui style file for the component
• Component.test.tsx - The tests
• Component.stories.tsx - The Storybook file
• Component.mocks.tsx
  • Component.test.tsx 으로 부터 test 파일을 따로 만든 이유.
    • 로직 그리고 UI 테스트에 모두 활용 가능하기 때문.

having one folder that contains the files for ALL components,

• one folder that contains all the tests, and
• one folder that contains all the Storybook files, etc.

Everything related is grouped together and easy to find.

components 를 아래의 세부 폴더로 구성

• forms
• routing
• layout

Views (현재 프로젝트의 Pages 에 해당)

Here's where the main part of your app will live: in the views directory. Any page in your app is a "view".

The advantage of keeping everything domain-focused instead of putting all your pages together in **components/pages**is that

• it makes it really easy to look at the structure of the application
• and know how many top level views there are,
• and know where everything that's only used by that view is.
• If there are nested routes, you can always add a nested views folder within the main route.

컴포넌트와 마찬가지로,

page.styles.js - The mui style file for the component

page.mocks.tsx

page.test.tsx - The tests

page.stories.tsx - The Storybook file

**현재는 index 파일 내부에서 상태를 관리해주고 있음. 이를 상태 관리 만을 위한 파일 생성하여 관리하도록 개선. 예를 들어, states.tsx

아래는 Reducer 를 사용하는 경우로, 하나의 페이지 안의 상태를 관리해준다.

Services(현재의 hooks 에 해당)

Good to store temporary data when getting back to list from detail page of specific row

global UI state section🤩

**ui**section of the store to handle modals, toasts, sidebar toggling, and other global UI state, which I find better than having const [isOpen, setIsOpen] = useState(false)  all over the place.

이처럼, UI 관련 상태 관리를 위한 파일도 있으면 좋을 것 같음.

Store(현재의 cache 에 해당)

The global data store will be contained in the store directory

 

셀러 리스트 등 범용적으로 사용하는 데이터들을 저장할 수 있다.

Utils

Reference

How to Create a Front End Project Structure That Scales and Is Easy to Maintain?

React Architecture: How to Structure and Organize a React Application

How to structure your files in a large React application — the solution.

Guidelines to improve your React folder structure

How To Structure React Projects From Beginner To Advanced

Literally just for reference

Evolution of a React folder structure and why to group by features right away

React project structure for scale: decomposition, layers and hierarchy

React Folder Structure in 5 Steps [2022]