weui/react-weui

1. What this repo is

- react-weui is a React component library that wraps the WeUI design system.

- There is no backend or server-side business domain here; the architecture is centered on reusable UI components, styling, docs, examples, and tests.

2. Public library boundary

- The main package entry is src/index.js.

- That file re-exports the component surface area from src/components/**, so consumers import from the package root rather than internal files.

- src/version.js holds package version metadata used by the build/runtime surface.

3. Component subsystem structure

- The library is organized by component family under src/components/.

- Each component typically has:

- a main React component file,

- an index.js barrel export,

- and sometimes a .less stylesheet.

- The structure is intentionally granular: many components are split into small internal pieces such as button_area, button_preview, panel_header, tabbar_item, mediabox_info_meta, etc.

4. Design of the UI layer

- Components are mostly presentational React components that compose smaller building blocks into WeUI patterns.

- Examples of composite areas include:

- form/ for inputs, toggles, uploader, validation-related controls,

- cell/, panel/, and mediabox/ for grouped list/content layouts,

- tab/ and swiper/ for navigation and page switching patterns,

- popup/, dialog/, toast/, toptips/, and mask/ for overlays and notifications.

5. Styling and asset boundary

- Styling is split between:

- package-local styles in src/components/**.less,

- and external base styles from WeUI itself.

- The README’s example explicitly imports both weui and react-weui CSS, which means the library depends on the external WeUI stylesheet as part of its rendering contract.

- The build outputs a distributable CSS bundle referenced as build/packages/react-weui.css.

6. Utilities and shared behavior

- src/utils/ contains cross-cutting helpers such as:

- classnames.js for class name composition,

- deprecationWarning.js for runtime warnings around legacy APIs.

- These utilities support consistency across component implementations rather than introducing a separate domain layer.

7. Docs site subsystem

- The docs/ directory is a separate documentation application built from React components and markdown content.

- It includes:

- page containers in docs/pages/,

- UI chrome in docs/components/,

- guide content in docs/guide/,

- generated metadata like docs/docs.json and docs/langs.json.

- This site powers the live documentation and component previews, so it is a consumer of the library rather than part of the library runtime.

8. Example application subsystem

- The example/ directory is a second consumer app that demonstrates real usage patterns.

- It contains many page-level demos for specific components such as button, dialog, picker, tab, toast, uploader, etc.

- This folder is useful for understanding the integration boundary: it shows how the exported components are composed into app screens.

9. Testing strategy

- test/ contains per-component unit tests that largely mirror the src/components/ tree.

- The test suite includes shared setup (test/setup.js) and Mocha config (test/mocha.opts).

- This indicates the primary validation strategy is component-level rendering/behavior testing, not end-to-end system testing.

10. Build and packaging pipeline

- webpack.config.js builds the library package, while webpack.config.doc.js builds the documentation app.

- scripts/build.js is the build orchestration entry.

- Babel, ESLint, and the webpack configs define the compile boundary from source React/JS/LESS into distributable assets.

- The repo is packaged for npm, with CI/publish automation in .github/workflows/, plus legacy Travis config.

11. External dependencies and runtime assumptions

- The runtime assumes a browser React environment with react and react-dom.

- The library is paired with the external weui package for visual styling and theme alignment.

- Distribution is designed for both npm installation and CDN consumption, which is why the build artifacts are important public outputs.

12. How to think about the architecture diagram

- Draw the repo as three main consumers of the same component source:

- the library package (src/ → built npm/CSS artifacts),

- the documentation site (docs/),

- and the example app (example/).

- Put src/components/** at the center, with src/index.js as the public API boundary.

- Add a side layer for shared utilities and styling, and a separate validation layer for tests.