V2EX › yyfearth 的所有回复 › 第 49 页 / 共 169 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 45 46 47 48 49 50 51 52 53 54 ... 169

❮

❯

2018-07-10 01:01:28 +08:00

回复了 huiyifyj 创建的主题 › 问与答 › 求解 ES6 的类语法中操作 document 操作问题？

@mostkia @Rubicker666 defer/async 怎么用我明白就他给的这个例子而言只要不阻碍就应该可以了
一般情况下如果放到 head 里面就要等 dom
或者放 body 最后就可以不用等了

2018-07-09 13:01:39 +08:00

回复了 huiyifyj 创建的主题 › 问与答 › 求解 ES6 的类语法中操作 document 操作问题？

这个和 ES6 没关系你用 ES5 或者 ES3 写也是一样的

原因仅仅是因为顺序问题
<script src="./bundle.js"></script>
<div id="fyj"></div>
你代码执行的时候是阻塞的你要的这个 div 还没有渲染出来呢
所以 a 当然是空的

你只要调换一下位置就解决问题了
<div id="fyj"></div>
<script src="./bundle.js"></script>

这只能说你实在是没有如何经验啊
要操作 dom 一般都要要等 dom ready 才行（其实只要等你要操作的相关 dom 就可以）
所以 script 放在 head 里面的时候一般要等 dom ready 或者 window onload

或者用 async/defer 模式
<script src="./bundle.js" async></script>
<div id="fyj"></div>

一般推荐做法就把这些 script 放在 body 里面的最后面

2018-07-08 16:01:01 +08:00

回复了 Hashtagoo 创建的主题 › iCloud › 怎样把 icloud 内的钥匙串密码转移到 1Password

@Cavolo 就算是全果也有跨浏览器的需求啊
另外 1p 比 icloud keychain 在管理功能上也强的多啦
而且还可以存一些其他东西不仅仅是账号密码比如软件序列号还可以是加密文档
当然 keychain 也可以存一些其他东西比如笔记和证书什么的

2018-07-05 01:35:48 +08:00

回复了 DravenJohnson 创建的主题 › macOS › Setapp 现在划算么？

你运气不错貌似又开始促销啦

2018-07-04 02:30:30 +08:00

回复了 DravenJohnson 创建的主题 › macOS › Setapp 现在划算么？

你错过了前段时间的促销啦

2018-06-16 11:41:24 +08:00

回复了 zivn 创建的主题 › macOS › 刚入了 Setapp，转让几个空闲授权

哦没看清楚是你入了 SetApp 把原来用的软件许可转让这样吧

2018-06-16 11:40:25 +08:00

回复了 zivn 创建的主题 › macOS › 刚入了 Setapp，转让几个空闲授权

SetApp 不是绑定账号的吗不存在每个软件单独的许可证吧

我记得是每个账号可以安装在两台机子上然后这两台机子可以随便装里面的软件

就像云端软件一样你顶多和别人共享账号密码没办法单独转让吧

一年前用的 SetApp 是这样的选择不知道是不是还这样

2018-06-05 06:19:33 +08:00

回复了 wohenyingyu03 创建的主题 › Apple › WWDC 最期待的东西

不可能的 Apple 压根就没打算让 iOS App 运行在 macOS 上面也压根没打算做的像 UWP 那样
Apple 做的只是做了它早就应该做的事情就是把 iOS 的 UI SDK 移植到 macOS
这个只能说是方便开发者希望开发者不要再忽略 macOS 的原生应用（然并卵）

你说的权限那些的今年 macOS 确实有加强但是和你说的这个没啥关系

而且这次 UIKit 还是内部使用没有开放给开发者

2018-06-05 06:13:17 +08:00

回复了 Building 创建的主题 › iOS › 纵然 Apple 花了一个小时来介绍 iOS 12，可是升级完成后我想问: 到底更新了什么？

本来之前就说了今年的 iOS macOS 主要来修 bug 的主要更新都推迟到 2019 了
有这么几个功能更新已经算不错了明显就是实在没啥好说的只好把鸡毛蒜皮的更新都拿出来了

2018-06-04 23:31:42 +08:00

回复了 susunus 创建的主题 › 问与答 › 有没有声音小点的鼠标和键盘

罗技有静音鼠标和键盘可以考虑一下

2018-06-01 17:05:04 +08:00

回复了 banxi1988 创建的主题 › 前端开发 › 帮你记住 CSS `padding` ,`margin` 属性的简写对应关系

同意楼上只要记住顺时针 “上右下左” 就够了
如果少了最后一个左那么就用右的值
如果还少了一个下那么就用上的值
如果只有一个值当然就全部都用了

2018-05-16 09:56:58 +08:00

回复了 mz02005 创建的主题 › SSL › 怎样禁止 chrome 浏览器在 wss 握手时的服务器验证行为

解决办法很简单啊为什么要跳过验证直接安装证书就好了
不想验证用 ws 就好了啊为啥还要用 wss

2018-05-13 17:28:49 +08:00

回复了 vevlins 创建的主题 › 前端开发 › 制作 react 组件 npm 包，采取导出源文件(jsx 语法)和 bundle 文件各有什么优缺点？

另外我之所以最后选择第一种方法的主要原因是因为方便开发和 debug
因为在开发项目的时候经常要对 npm 包里面的组件进行修改和 debug
导出 bundle 虽然可以用 source map 来 debug 但是没办法直接修改代码立即 debug
必须修改组件代码 -> 打包发布 -> 主项目 npm i 新版本 -> debug -> 修改组件代码 -> ...
非常耗时和浪费精力

改用直接使用 jsx 源代码然后 npm link 或者 yarn workspace
一切就和没有 npm 包组件化一样方便了

2018-05-13 17:24:00 +08:00

回复了 vevlins 创建的主题 › 前端开发 › 制作 react 组件 npm 包，采取导出源文件(jsx 语法)和 bundle 文件各有什么优缺点？

这里 webpack 坑比较多我现在都是不用打包的组件直接引用源代码基本上就是你第一种方法

导出 bundle 其实也可以但是你 external react 是不够的要 external 所有的依赖除非你 100% 确定这个依赖是你这个组件独有的
external 所有依赖后 bundle 文件就比较小了而且不用担心因为整个项目的 webpack 会把依赖打包进去
否则同一个依赖如果其他地方有用到会被打包多次造成文件非常大

另外如果项目的多个组件用了不同版本的依赖多个版本会被打包起来导致最终 bundle 非常大
最容易碰到的例子就是 lodash 和 moment 两个库本身就挺大的加上不同组件及其依赖使用了不同版本或者不同发布方式的版本
比如 lodash 有 cjs 版本 es 版本模块化的 cjs 版本模块独立的发布的 cjs 版本而且每种还可能有不同的 version 我之前就遇到过一个项目里面 lodash 就 4-5 个不同的拷贝被打包每个 10k - 90k 不等
然后是 moment 的 locale 需要在打包的时候排除否则非常大
这个可以通过修改 webpack 的配置来统一版本

我接触过的一个项目一开始每个组件自己 bundle 然后项目再 bundle 结果各种重复打包一个简单的 webapp 可以到 10M 的 JS bundle
通过各种办法在没有减少任何功能组件和依赖的情况下减少到 250K JS + 100K CSS + 80K 字体文件

2018-05-11 15:40:41 +08:00

回复了 yyttll 创建的主题 › 问与答 › mac 快速拷贝文件到一个指定目录

@xuuuu @littleylv APFS 下 CP 没有复制粘贴快
复制粘贴不管文件大小只要是同一个分区都是毫秒完成而且占用空间也不增加
而且还不是 symlink 或者 hardlink 虽然实际上相当于 hardlink

2018-05-11 03:19:04 +08:00

回复了 wlwood 创建的主题 › Node.js › 你们家的 nodejs， node_modules 太占空间了。。。。

另外其实还有一个好处就是因为 node_modules 独立
所以可以直接修改依赖而不影响其他项目
尤其是在 debug 的时候发现依赖的包里面有问题
甚至可以在 npm postinstall 里面直接 patch 依赖的包

2018-05-11 03:16:20 +08:00

回复了 wlwood 创建的主题 › Node.js › 你们家的 nodejs， node_modules 太占空间了。。。。

@yuann72 你说的当然可以但是问题就出在 “检查下所有项目的 package.json ”
也就是说要么在 cleanup 的时候整个系统寻找 package.json
要么在 install 的时候需要记录每一个 package.json 存在的路径
都不是一件容易而且有效率的办法

否则你在做清理的时候你没办法知道有没有其他项目在使用你想要清理的包
这样一来就意味着所有 node 的项目就不是 portable 的而且也不能随便移动位置和直接删除

现在 node_modules 最大的好处就是 node 项目大部分情况是 portable 的
只要 OS 兼容 Node 版本兼容你可以随时挪动位置或者删除而且不影响其他项目
另外如果你一个项目的包弄糟了只需要删掉 node_modules 重来就好

我觉得唯一的问题不是 node_modules 太大而是文件太多目录太复杂
我觉得可以学其他的语言把文件打包一下比如 jar war phar 这些 zip 一下
而且由于有可能会有不少重复文件去重再压缩估计会小不少
然后在运行时按需求解压因为很多时候并不是所有文件都有用到
而且现在的机器性能解压缩 zip 的时间基本上可以忽略搞不好从 IO 角度
从 zip 读取可能比加载一大堆文件还要快

这个现在可能不是很必要但是以后有 webasm 了打包一下其实可以考虑的

2018-05-10 21:14:12 +08:00

回复了 wlwood 创建的主题 › Node.js › 你们家的 nodejs， node_modules 太占空间了。。。。

@wlwood @janxin @maichael 其实可以的多个项目其实可以共享全部或者部分 node_modules
node 会自动向上层目录寻找所以如果有公共的依赖而且版本一致可以提取到上层目录的 node_modules 实现共享
或者如果你这些项目的依赖完全一致可以把其中一个 node_modules 放到上层目录然后把其他的删掉或者 symlink
如果你觉得太麻烦有工具会自动帮你弄：yarn workspace
它会自动解决多个项目的相互依赖同时提取公共的部分到同一个 node_modules
其他的项目会 symlink 到这个 node_modules 里面的依赖

@chenstack 不一定要 symlink 其实 node 会自动往上层目录找另外 yarn workspace 最适合这种情况会自动 symlink

@beginor 放全局目录也不一定是好事如果你项目多全局目录会非常大
而且如果你要删除一些项目的时候全局目录就没办法清理只会越来越大而且你还不敢随便删除

@wlwood 其实你说的不完全正确 npm 有 cache 的如果有相同的依赖不会重复下载但是由于每个项目是独立的 node_modules 自然会有独立的拷贝
但是我觉得从部署的角度而言独立 node_modules 其实比较方便和干净
你只要把项目连同 node_modules 一起打包和拷贝只要 OS 和 Node 相同就可以直接跑起来
而且删除的时候也很干净不会在 global 留下不再需要的包

另外同一个项目下面如果版本不同 NPM 倾向保留多个版本这个是 node 社区的问题
不同版本（一般除了_._.x 修正版本）之间往往不兼容而且也有可能会有包锁定依赖版本
NPM 现在的方法其实是比较省事的如果要 merge 和 flatten 反而会造成很多问题
目前新版本的 NPM 和 Yarn 就会做一些 merge 和 flatten 结果每次更新依赖的时候会造成一些问题

1 ... 45 46 47 48 49 50 51 52 53 54 ... 169

❮

❯