After successful initialization, a complete development framework has been generated for you. The following is the directory structure of the entire project, which provides various functions and pits covering middle and back-end development.
โโโ config # umi configuration, including routing, construction and other configurationsโโโ mock # local mock dataโโโ publicโ โโโ favicon.png # Faviconโโโ srcโ โโโ assets # Local static resourcesโ โโโ components # Business common componentsโ โโโ e2e # Integration test caseโ โโโ layouts # General layoutโ โโโ models # Global dva modelโ โโโ pages # Business page entry and common templatesโ โโโ services # Background interface servicesโ โโโ utils # tool libraryโ โโโ locales # Internationalized resourcesโ โโโ global.less # global styleโ โโโ global.ts # Global JSโโโ tests # test toolsโโโ README.mdโโโ package.json
In order to make the project code organization more standardized and make it easier for development to locate the relevant page component code, we have defined a set of specifications, which are currently only used as recommended guidelines, not mandatory.
srcโโโ componentsโโโ pagesโโโ Welcome // No other routing components should be included under routing components. Based on this convention, routing components and non-routing components can be clearly distinguished| โโโ components // You can do more in-depth organization for complex pages, but it is recommended not to exceed three levels| โโโ Form.tsx| โโโ index.tsx // code of page component| โโโ index.less // page styleโโโ Order // No other routing components should be included under routing components. Based on this agreement, routing components and non-routing components can be clearly distinguished| โโโ index.tsx| โโโ index.lessโโโ User| โโโ components // public component collection under group| โโโ Login // page under group Login| โโโ Register // page under group Register| โโโ util.ts // There can be some shared methods here, do not recommend and restrict, do your own organization depending on the business scenarioโโโ * // Other page component codes
All routing components (components that will be configured in the routing configuration) are recommended to be flattened to the first level under pages with the big hump name (complex projects can increase the group level and place pages under the group). It is not recommended to nest routing components inside routing components-it is not convenient to distinguish whether a component is a routing component, and it is not convenient to quickly locate the routing component globally.
We recommend splitting routing components into more fine-grained components as much as possible. For components that may be used on multiple pages, we recommend putting them in src/components. For components that are only dependent on a single page, we recommend It can be maintained near the routing component folder.