💡:写代码很纠结?
这是好事 -> 当你对所写的代码有要求的时候,你才会纠结 -> 比如起名字时会想很多
💡:IndexDB 开发用得多吗?
用得不多 -> 一般都是用数据库了
💡:简历项目是挑部分详细写还是大体总结的好?
多写一些比较好!
当然,对于一些大佬而言,如 python 作者,简历里边只写了一句「I write python」就行了
用最简单的词,说最狠的话 -> 到了这种境界的人,不需要用太多词来描述,简简单单就能把自己的能力体现出来!
💡:mv 界面的设计稿?
手机端 -> 网易云音乐和抖音的看起来差不多!
💡:做什么?
做三个东西:
💡:把歌词展示到这个「歌词」页
💡:歌词样式
scroll-view
上下padding
-> 不然,在滚动的时候,上下歌词会消失掉
padding-top/bottom
-> 作用于item
contentHeight
计算可得 -> 可是这是从这中间开始的,太靠中了,所以再提上个80
-> 适配黄金分割点35px
,在移动端设备这是比较舒适的高度,居中效果很好 -> 因此,我们的滚动距离也是35px
35px
-> 你可以设置成常量 -> 用行内样式scroll-top
-> 不过这样的滚动很突兀,有跳跃的感觉 -> 加点动画效果效果:
1 59 32
💡:歌词展示的空白?
那个空白也是有时间的
💡:歌词拖拽播放?
scrollTop
除以35
计算得到index
index
拿到对应的时间,再设置(seek
)对应的时间➹:前端有什么拖动歌词改变播放进度的开源项目? - SegmentFault 思否
💡:歌词前后高度用另一种方式计算
父盒子的伪类给calc(50% +/- 行高)
💡:重构播放页面代码
会修改很多代码,甚至删掉一些代码
目前的代码存在什么问题?
怎么重构?
把数据的原始位置放到其它地方,目前还在这个播放页里边,播放页只有使用权
💡:导出代码
💡:重构步骤
currentSong、durationTime、lyricInfos
-> id
song-item-v1
、song-item-v2
抽取代码的思路:
为什么不一开始就抽离了? -> 先把逻辑都写到播放页里边,再抽取 -> 是为了让大家学会这样抽取的思路
1 23 35
💡:网络请求这部分抽取完了,抽离播放歌曲部分
为什么要抽取:
抽到哪儿去:
💡:播放页 -> 返回到上一页
监听的是整块区域,而不是小图标,毕竟如果小图标太小的话,会无法监听到
nav-bar
组件不能决定用户点击这个图标区域到底要做些是啥事,而是交给使用这个组件的页面来决定
所以我们要把这个事件抛出去
效果:
返回到上一级歌曲还在播放…… -> 这首歌播放完,自动切换到下一首该如何做呢?
如果重复点击同一首歌呢? -> 不需要重复发送 -> 判断一下id
即可!
1 11 17
💡:文字渐变
伪元素::before
-> 用一个相同的有颜色的文字叠加上去,这个完全叠加是慢慢过渡的,也就是宽度从0%
到100%
➹:sample-code/lyrics-progress.html at main · oceanbaby715/sample-code
💡:这三个数据要共享吗?
首页也许不会用到它们,但未来就不一定了
为了长远考虑,我们可以把它们抽离出去
既然要抽离它们,那么这三个数据是来自哪儿的呢? -> 产生这些数据的地方也要抽离出去!
💡:来回拖拽有 bug -> 很慢
滑块会抖动!
这个 bug 例子,能让你很好地理解页面 UI 更新和
data
更新不同步产生什么效果
💡:这个抽取过程
lyricScrollTop
)不要抽取38 30
💡:目前已经做了什么
歌曲的逻辑都抽到player-store
里边去了,其它页面要用直接去拿即可!
💡:现在该做什么
播放模式就写三种:
放到player-store
里边,因为需要共享
要做的:
24 55
💡:暂停功能
做两件事:
这个状态放哪儿? -> player-store
里边
暂停状态的监听可以跟
playModeIndex
放到一起,当然,也可以分开监听 -> 选择放在一起,因为它们俩联系比较紧密,都是在一个 HTML 结构模块里边
暂停或播放歌曲 -> 调用 API -> 在player-store
里边写这个逻辑 -> 在播放页里调用这个action
💡:代码细节
let {a,b} = {a:'xx'}
->a -> 'xx',b -> 'undefined'
💡:其它功能
关键是学会代码的设计,以及如何抽取 -> 公共逻辑抽取一下 -> 如何做状态管理
07 26
💡:暂停后,拖动进度条立马播放,而播放按钮没有变化?
💡:APP 体验
原生体验更好 -> object-c java
uni-app 和 rn 有 bug