V2EX › vizards 的所有回复 › 第 1 页 / 共 17 页

V2EX = way to explore

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

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 17

❮

❯

341 天前

回复了 WangLiCha 创建的主题 › React › React 拖拽辅助库选型求推荐？

@WangLiCha 实际上如果是单纯的 flex 布局（即使包含 wrap ）直接 flex 排就可以了，拖拽也可以正常工作，只不过由于不定宽高，要自己处理动画变形问题

341 天前

回复了 WangLiCha 创建的主题 › React › React 拖拽辅助库选型求推荐？

你的要求 dnd-kit 都可以满足
1. 跨容器拖拽排序官方有 examples ，其实就是定义多个 container ，共享 draggable element ，如果需要的是从源容器复制的效果，则需要源容器内的 draggable element 在被 drop 后重新渲染（通过修改 key 或 id ），这样被拖走后他会在原地重新生成一个，或在拖拽开始/拖到可放置区域时重新生成一个新的 key 以破坏和源容器中的元素的对应关系

2. 限制特定交换顺序：真正的交换是否成功是看渲染的结果，也就是说 dnd-kit 在拖拽完成的事件里你是否调用 arraymove 等帮助方法让列表数据改变，如果没有改变，那么拖拽就没有成功，列表顺序也不变

3. 每个标签有点击事件：可以通过 sensors 实现只监听某些地方的 pointer 事件，也可以通过监听 onPointerDown 事件来变相监听 onClick ，通过监听延迟来确定是移动还是点击（因为开启了 pointerSensor 后无法监听到 onClick ）

4. flex 不定宽排序：官网有例子，至于拖拽时可能的变形问题，可以通过动态渲染一个 drop item placeholder 实现，即保存一个自定义的 dragoverlay 数据，在元素可以被放置到某个位置但元素还处在被用户鼠标抓住时，插入此 dragoverlay 对应的元素到预测的位置，展现为一个半透明的占位，可以保证布局不变形

我目前遇到的 dnd-kit 较难做到的是多列瀑布流布局下的自由拖拽，拖拽可以实现，但是很难保证容器内不变形

346 天前

回复了 17681880207 创建的主题 › React › 技术咨询，各位大佬们，现在 react 开发项目，有什么类似 Vue 中的 keep-alive 方案吗？

目前（截止 2024.1.10 ） react 还没有真正生产可用的 keep-alive 方案

替代选择：
1. react@experimental 中提供的 unstable_Offscreen ，要求 React 使用 experimental 版本
2. 基于 Suspense 实现的 keep-alive ，比如极简代码实现的 react-freeze ，要求 React 17+
3. 其他介入 React 渲染流程的 hack 实现，比如你已经搜到的

结合路由的方式基本都是手动劫持 Outlet 组件的渲染，使之可以不被 unmount ，转而使用一个新的属性比如 mode 控制子路由组件是否渲染

2023-08-25 14:56:14 +08:00

回复了 hanlin85 创建的主题 › 问与答 › 父母的房子在装修，想给他们弄点智能家居，不知道有没有可以自动关门的产品？

淘宝敏匠开窗器。非广告，DIY 过一个 90 度旋转开门器正常运行了 2 年。
优点：24V 无刷电机，可以自己 DIY 主控板接，也可以用他们做好的（只能接入米家），同时支持手动和电动操作；
缺点：丑，只能外置，要在门上打钉子。手动推拉需要用力以抵抗无刷电机的阻力。

2023-03-07 16:03:33 +08:00

回复了 v2yllhwa 创建的主题 › 奇思妙想 › 纯前端的加密访问

配合 webpackJsonP 的类似实现，例如重度使用此功能的 webpack5 module federation 可以实现运行时 dynamic import 进相关的 js 代码文件块（加密后），在 service-worker 层挂一个劫持逻辑做解密，或许具有可操作性？编译时要多做一步加密 jsbundle 的操作

2023-03-03 11:27:36 +08:00

回复了 unt 创建的主题 › 程序员 › 请教大家一个 web 功能设计问题

目前实践下来最简单的方法是给需要权限的 dom 挂上 data-permission-id （你喜欢的名字），然后在整个 app 顶层用 mutationObserver 集中处理权限并按需隐藏所有的权限 dom ，既实现了框架无关也做到了动态化控制权限无需发布前端代码

2023-02-24 17:11:18 +08:00

回复了 beginor 创建的主题 › 程序员 › 2023 年又发现了一个 "IE6" ，那就是安卓版微信内置的 Webview

其实还有魅族和 OPPO 的一些手机，安卓版本已经到了 9.0 和 X ，而他们系统内置的 webview 的 Chrome 版本还是 55 、60 ，在 sentry 上可以看到大量这些低版本报的兼容性错误

2022-12-24 20:55:48 +08:00

回复了 proxytoworld 创建的主题 › 问与答 › 阳了，发烧好了，但喉咙还是吞刀子一样怎么搞啊，咽部红肿有突起，有学医的 v 友知道怎么搞吗

接上面，西红柿我四天之内吃了 9 个，因为我本来就喝茶，绿茶每天起步三杯，抗生素我大概四天内口服了 0.5g 的头孢克肟，感觉对症状无明显缓解作用

2022-12-24 20:50:32 +08:00

回复了 proxytoworld 创建的主题 › 问与答 › 阳了，发烧好了，但喉咙还是吞刀子一样怎么搞啊，咽部红肿有突起，有学医的 v 友知道怎么搞吗

没有好办法，我小刀喇嗓子喇了四天，吃布洛芬片剂可以短暂把小刀换成石子，利多卡因气雾剂有效，但是维持时间太短了，半小时就疼回来了，也不敢太频繁地用。自制高渗盐溶液润嗓子也可以缓解一些，凉水效果更明显。今天稍微好转了一些，这玩意太折磨人了

2022-10-12 22:50:12 +08:00

回复了 Zero00favor 创建的主题 › 智能家电 › 关于装修规划时如何准备和规划全屋智能家居

还没经历装修，先对 LZ 表示羡慕，不过在改造过程中遇到的问题想到几个：

1. 厨房、卫生间预留的插座太少。因为强电设备很多，全部实现机械电源通断智能化需要的智能插座又很占地方；
2. HomeLab 控制中心（包含 NAS 、路由、主 AP ，光猫、AIO 服务器）还是很难决定位置（要兼顾散热），以及 UPS 的服务范围（是服务器、安防设备、还是全部智能设备）；
3. 灯的开关盒一定要预留零线进盒，因为现在单火线的智能开关仍然很难解决鬼火问题；
4. 如果要做智能窗帘、窗户、门，应该在哪里预留电源端子，如何保证 esp32 的弱鸡 Wi-Fi 稳定性
5. 弱电设备太多，交流转直流电源几乎每个弱电设备都要加一个，占的体积又大，发热又比较严重。如果全屋可以走一个 24V 弱电线路或许是更好的选择？（但是损耗可能也不小）

2022-09-20 00:54:10 +08:00

回复了 tmtstudio 创建的主题 › 程序员 › 请教大佬们个硬件问题，感谢

为了提高按钮的识别率一般还会搞个导电橡胶保证和电容触摸按钮的贴合

2022-09-20 00:52:33 +08:00

回复了 tmtstudio 创建的主题 › 程序员 › 请教大佬们个硬件问题，感谢

任何导体触屏都可识别--应该是你的手拿着导体测的吧？所以关键是改变触摸按钮对 GND 的电容量，用继电器 /MOS 管 /三极管切换串联电容 or 断开，或者改变电容大小随便你，注意做好电容对地放电就好了

2022-08-31 17:56:18 +08:00

回复了 lisr 创建的主题 › Apple › 关于 Apple TV 做 Homekit 家庭中枢 + 透明网关流媒体解锁共存问题

homekit 前段时间服务域名换成了 akadns.net ，网上的 apple-list 都不包含这个域，可能需要在 openclash 确认下对应的连接情况

2022-07-18 23:09:26 +08:00

回复了 DanielHall 创建的主题 › iCloud › 苹果您的 iCloud 逻辑是不是有点大病？

关于 iOS 系统空间里面显示的“其他”，个人更愿意把它理解为系统的缓存，但是这个缓存不会因为重启就会清理，iCloud 备份完成后也不会清理 iCloud 产生的缓存数据。目前我试过的有两种比较可靠的办法去清理“其他”。一是 dfu 升级系统（保留数据升级），二是拍摄 pro raw 视频时相机界面可以手动清理空间（限定有此功能的机型）

2022-06-17 23:01:11 +08:00

回复了 LxnChan 创建的主题 › 程序员 › 经过米家崩溃，想和大家讨论一下智能家居本地化的可能性。

@rockyzhang 他的云服务本质上只是提供了一个公网映射和一个 TTS 方案，我选择的是 600 多买一个 HomePod mini 用 HomeKit 去代替

2022-06-17 21:44:18 +08:00

回复了 LxnChan 创建的主题 › 程序员 › 经过米家崩溃，想和大家讨论一下智能家居本地化的可能性。

从三年前的米家用到现在变成 HomeKit 的用户可以随便谈谈，希望能给楼主一点建设性意见。

首先是智能家居的本质问题，对于 80%的智能家居来说，他的本质是多个遥控开关（继电器） + 传感器，因此选择平台，选择的是操作体验、稳定性和开放性。基于目前的智能设备生态，对一个没有嵌入式基础或计算机基础的用户来说，在价格和体验方面是很难两全的。接下来谈谈我的方案。

1. 选择 HomeKit 作为人机交互的入口，是因为操作体验较好，界面设计较为合理。以及通过 HomePod 可以实现仅局域网的智能控制，也不缺失外网控制的功能。但是问题在于支持的设备类型较少，自动化方案不够；

2. 选择 Home Assistant 和 Homebridge 双平台作为大部分非 Homekit 认证设备的统一接入平台。他们可以作为一个 Bridge 提供给 Homekit 用于控制其他设备。原因在于 Home Assistant 在开源智能家居方面生态较好，可以买到爱好者自制的如单火线智能开关、窗帘电机等设备，价格实惠。也可以通过插件接入米家 /易微联智能设备，实现全局域网控制。更可以通过更广泛的协议如 HTTP/BLE 等与开放本地端口的设备如电视、机顶盒、蓝牙温湿度传感器等实现通信；

3. 通过开源的 HAA 协议和 ESP32 芯片，可以自己编译固件刷入实现原生的非认证 HomeKit 设备。比如目前没有国内厂商接入的窗户、门、楼宇门铃等等，可以自己通过 ESP32 实现，之前为接入写过几个固件 https://github.com/Vizards/esp-homekit-entities

4. 米家设备生态日趋封闭（狂推蓝牙网关），局域网控制协议越来越难破解，MIOT 通信协议已不向个人开发者授权，但价格合理，品类覆盖面广，在一个米家设备拥有接入 Hass 和 HB 的开源方案时，也不失为购买方案（易微联同理）

1 2 3 4 5 6 7 8 9 10 ... 17

❮

❯