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

V2EX = way to explore

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

For Existing Member Sign In

3 天前

回复了 ronda90 创建的主题 › Claude › Claude Design 有没有差不多能力且便宜的平替？

@milkleeeeee 或许你可以试试 https://unui.cc ，相比于 v0 更注重单一风格，但专注率、产出品质和效率都大幅提升，适合做 web saas 风格。

6 月 19 日

回复了 weiyunjun 创建的主题 › 程序员 › 前端界面比想象中复杂好多

如果你对风格没有自己很严格的要求，可以试试 unUI ，用 codex 设计但准确性非常高，因为设计方向被固定在 saas 类上约束了范围。
这里是免费试用： https://unui.cc/zh/campaigns/ETV0LGM1mUTQ8ap5Runh

6 月 18 日

回复了 heywitt 创建的主题 › 分享创造 › 又整了个可能没啥用的活：给 Codex 看设计参考

有些哥们在邮箱问邀请码，一个个发太麻烦了，每个链接可以用 10 次：

- https://unui.cc/zh/campaigns/OYK-0qaHO20NSq1gYfug

- https://unui.cc/zh/campaigns/kdagHZO12frWnO4gDN3m

- https://unui.cc/zh/campaigns/UaITHOBHVICZAX1VGADK

6 月 9 日

回复了 heywitt 创建的主题 › 分享创造 › 家人们，有意思的来了，做了个临时分享小秘密的工具

@wukaige 可以，但我做了一半移除了。原因是我发现 cf oauth 拿不到高级权限 (即创建 token 的权限)，必须要 global token 才可以运行脚本，这其中需要创建多个资源，考虑到安全考量，还是让 wrangler 部署时自动创建 + 用户手动填充 env 的方式 selfhost 了，这确实有点麻烦，特别是不熟悉 cf 时想要找到各种 token 得花点力气。
你的想法也很有道理，如果能接受 global token 自动创建所有资源 + 部署，体验也是非常不错的。

6 月 9 日

回复了 heywitt 创建的主题 › 分享创造 › 家人们，有意思的来了，做了个临时分享小秘密的工具

@aileaile 你的建议很有道理，有个中文版本确实会容易传播

6 月 9 日

回复了 heywitt 创建的主题 › 分享创造 › 家人们，有意思的来了，做了个临时分享小秘密的工具

@kekxv haha 不是要自己卖产品，域名不关键，只是 preview ，如果需要使用可以自己 selfhost

6 月 9 日

回复了 heywitt 创建的主题 › 分享创造 › 家人们，有意思的来了，做了个临时分享小秘密的工具

@shilianmlxg 没 skill ，这个没有特意设计，是 tailwind + shadcn 黑白灰

2022 年 2 月 21 日

回复了 heywitt 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜

@a132811

`select.d.ts` 是一个类型文件，`ScrollToOptions` 是 DOM 全局类型，你需要在你的 `tsconfig` 中指定 `lib: ["dom"]` 以确认当前 TS 应用包含 `lib.dom.d.ts` 类型 (可用 DOM 接口)。
对于刚开始使用 TS 的开发者可以参考： https://stackoverflow.com/questions/42603783/missing-basic-dom-types-in-typescript-project

----
另外，后续有问题建议在 GitHub 创建一个 Issue ，这样回答之后可以被索引，其他人有类似问题可以在 issues 内查找答案。

2022 年 2 月 21 日

回复了 heywitt 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜

@a132811 不太懂你的意思，上面有回复过：支持 ES Module ，如果你的脚手架环境支持引入 esm 那么就可以自动引入 esm 。(参考： https://cdn.jsdelivr.net/npm/@geist-ui/[email protected]/esm/index.js)

2022 年 2 月 21 日

回复了 heywitt 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜

@Macolor21 用阴谋论来推断别人的动机是不太友好的，我相信大部分人去建设 OSS 都是为了爱，至少我是很喜欢： https://unix.bio/fixed/projects

2022 年 2 月 21 日

回复了 heywitt 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜

@shanex 为了寻找一些不一样的解决方案和理想的 Geek 风格。

2022 年 2 月 19 日

回复了 heywitt 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜

@a132811
有的。
如果你正在使用 Webpack 5+ / NextJS 11+ / CRA 5+ 或其他 esbuild 解决方案即可自动 tree-shaking ，如果是以前的脚手架会自动引用 CJS ，但可以用 babel 插件，参考： https://geist-ui.dev/zh-cn/guide/bundle-size 。

2022 年 2 月 18 日

回复了 gibber 创建的主题 › 程序员 › 关于手机端列表页面操作定位的处理

@gibber

- 产品上：你可以埋点看看返回列表后下滑的用户比例多不多，如果对于你的业务来说这是一个常见的用户行为，那推荐做一下。
- 技术上：数据变化的处理不难，加起来未必会超过一个组件的长度，肯定是处理会更好。

2022 年 2 月 18 日

回复了 gibber 创建的主题 › 程序员 › 关于手机端列表页面操作定位的处理

如果你正在使用框架，那么保持原来的路由 keep-alive 就可以。(具体不同可以去搜解决方案)，如果滚动内容较多，可以尝试和 [虚拟滚动]( https://github.com/react-component/virtual-list) 结合。
至于回来时数据发生了变化有很多解决方案，你可以用网络请求、url 传递参数、组件内部内存交互，借助浏览器平台交互等各种方式完成 re-validate ，以剔除不需要的数据。

2022 年 2 月 13 日

回复了 jaywhen 创建的主题 › React › 2022 年，学习 React 还需要学 class component 吗?

要的，还是有一些使用场景：

1. Error Boundaries 没有一个 FC 的接口，如果你需要定义还是要嵌套 Class Component 。(你可以用 FC 去嵌套包裹实现它，但有多个错误边界需要处理时，Class 仍旧是最好的方案。)
2. 当你需要对外扩展一个继承组件接口时，Class 能够帮助更好的提供对外的接口定义。FC 一般会使用组合、HOC 等方式。当你需要编写库、抽象逻辑时，很可能两种都需要兼容 (组合与继承)。
3. 维护过时代码时。一些旧的代码库本身就是 Class 实现，或是代码本身引用了一些只兼容 Class 的第三方依赖。如第三方库中对组件使用了 `Component.prototype.render` 的判断；第三方库依赖了 IoC 模式等，这会约束你只能写 Class Component 。