构建复杂 ui 组件的核心在于合理拆解与精准控制渲染逻辑：明确职责边界、配置驱动多态、状态机管理异步、适配多容器布局。
构建复杂 UI 组件的核心不在于堆砌功能，而在于合理拆解、精准控制渲染逻辑。关键是要让组件既灵活可配，又保持性能可控——尤其在列表、动态表单、多状态卡片等场景下，渲染函数的设计直接决定体验是否流畅、维护是否轻松。
明确渲染职责边界
一个渲染函数应只做一件事：根据当前输入（props、state、上下文）返回确定的 JSX 结构。避免在其中执行副作用（如 API 调用、定时器）、修改外部状态或嵌套深层条件判断。
- 把数据预处理（如格式化、过滤、映射）放在组件顶层或自定义 Hook 中，渲染函数只接收“就绪数据”
- 用 React.memo 或 useMemo 缓存稳定结构，防止无关更新触发重渲染
- 对长列表，优先使用 FlashList 的 renderItem + 自定义 CellRendererComponent，而非 FlatList 的内联函数
支持多态与条件组合
复杂 UI 常需同一组件承载多种形态（如带图标的按钮、禁用态标签、带加载指示的卡片）。靠 if/else 堆砌易失控，推荐用配置驱动方式：
- 定义清晰的 variant 枚举（如 'primary', 'outline', 'ghost'）和 size（'sm', 'md', 'lg'）
- 用 StyleSheet.create 预置组合样式，通过数组合并实现运行时拼接：
style={[styles.base, styles[variant], styles[size]]} - 对差异较大的结构（如表单字段 vs 只读展示），用 renderXXX prop 允许外部传入定制渲染函数
处理异步与动态内容
加载中、错误、空状态、分页加载……这些不是装饰，而是 UI 的一等公民。渲染函数要主动表达状态，而非被动隐藏：
- 统一用状态机思维组织：loading → success / error / empty，每个状态对应明确的 JSX 片段
- 避免
{data && <item></item>}这类隐式条件；显式写出if (loading) return <spinner></spinner>; - 对需要 Portal 渲染的内容（如 Toast、Modal），封装为独立 hook（如 useToast），由调用方触发，渲染函数本身不耦合 DOM 操作
适配不同容器与布局上下文
同一个组件在 Modal 内、在 ScrollView 中、在固定高度卡片里，行为可能不同。可通过 props 或 Context 注入环境信息：
- 传入
availableWidth或isCompact等布局提示，让组件自主调整换行、截断或折叠逻辑 - 用
useWindowDimensions()获取实时尺寸，配合 useMemo 做响应式渲染决策 - 对瀑布流、网格等复杂布局，不依赖 Flex 布局硬撑，而是借助 FlashList 的自定义 ViewHolder 或第三方库（如 react-native-super-grid）提供底层支持
