generated from Java-2025Fall/final-vibevault-template
56 lines
3.8 KiB
Markdown
56 lines
3.8 KiB
Markdown
|
# 前端开发反思报告
|
|||
|
|
|
|||
|
|
> 请参考 `FRONTEND_GUIDE.md` 了解写作要求。建议 600–1200 字。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. 我的界面展示
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
截图使用说明：
|
|||
|
|
1. 将截图保存到 images/ 目录下
|
|||
|
|
2. 使用相对路径引用：
|
|||
|
|
3. 建议 3-6 张截图，每张下方用 2-3 句话说明
|
|||
|
|
|
|||
|
|
示例：
|
|||
|
|
|
|||
|
|
这是歌单列表页面，展示了...
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
这是歌单详情页的“添加歌曲”弹窗，用于向当前歌单中新增歌曲。用户可在此填写歌曲名称、歌手（必填项）及专辑（选填项），完成后点击“添加歌曲”按钮提交。我在设计时将必填项与选填项做了标注区分，同时在弹窗底部重复放置操作按钮，避免用户滚动后需返回顶部操作。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
这是歌单详情页面，用于展示指定歌单的基础信息和歌曲列表。用户可在此编辑歌单信息、返回歌单列表，或通过“添加歌曲”按钮向歌单中新增歌曲。我设计了空状态提示文案，当歌单无歌曲时引导用户点击按钮添加，同时将操作按钮放置在显眼位置，降低操作成本。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
这是创建歌单的弹窗界面，用于生成新的音乐歌单。用户需填写歌单名称（必填）和歌单描述（选填），完成后点击“创建歌单”按钮即可生成新的歌单。我在此处设计了输入项的功能标注，明确区分必填与选填内容，同时将“创建歌单”按钮做了视觉强化，让核心操作更醒目。
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 2. 我遇到的最大挑战
|
|||
|
|
|
|||
|
|
<!-- 描述一个具体的前端问题、你的排查过程、以及最终如何解决 -->
|
|||
|
|
本次开发中，最大的挑战是跨模块的数据同步问题。在实现“添加歌曲后自动更新歌单卡片的歌曲数量”功能时，我发现歌曲管理模块和歌单列表模块是独立的，添加歌曲后，歌单卡片上的“歌曲数量”不会自动更新，需要手动刷新页面才能同步。
|
|||
|
|
|
|||
|
|
起初我尝试在“添加歌曲”的按钮点击事件里，直接去修改歌单卡片的文本内容，但这种方式需要遍历DOM找到对应的歌单卡片，不仅代码繁琐，还容易因为歌单名称重复导致修改错误。接着我又尝试用全局变量存储歌单数据，但不同模块修改全局变量后，其他模块无法感知到变化，依然需要手动触发刷新。
|
|||
|
|
|
|||
|
|
最后我采用了自定义事件的方案：在歌曲管理模块添加歌曲后，触发一个自定义事件（如 songAdded ）并携带当前歌单名称；歌单列表模块监听这个事件，收到事件后更新对应歌单卡片的歌曲数量。这种方式既避免了DOM操作的繁琐，也实现了模块间的解耦。
|
|||
|
|
|
|||
|
|
这次经历让我明白：前端模块间的通信，要尽量避免直接操作DOM或共享全局变量，利用自定义事件、状态管理等方式，能让代码更易维护。
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 3. 如果重新做一遍
|
|||
|
|
|
|||
|
|
<!-- 回顾你的前端实现，哪些地方可以做得更好？ -->
|
|||
|
|
|
|||
|
|
回顾这次实现，我会优先做两方面的改进：
|
|||
|
|
|
|||
|
|
第一是添加数据持久化。当前页面刷新后，创建的歌单和添加的歌曲都会丢失，重新开发时我会用 localStorage 存储歌单和歌曲数据，页面加载时从本地存储读取数据，确保用户操作不会因为刷新而丢失。
|
|||
|
|
|
|||
|
|
第二是优化代码组织。这次开发把所有JS代码写在同一个 <script> 标签里，随着功能增加会变得臃肿。重新开发时，我会将歌单管理、歌曲管理的逻辑拆分为独立的函数模块，甚至封装为类，让代码结构更清晰，后续修改某个功能时不用在大段代码里查找。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|