geist 最近的时间轴更新 geist 最近的时间轴更新 |
geistV2EX 第 572566 号会员，加入于 2022-02-12 21:08:52 +08:00 |
echo_witt
| 开源项目 Geist 推荐大家尝尝鲜
4 分享创造 • geist • 2022-02-28 14:43:02 PM • 最后回复来自 g0thic
|
27 |
geist 最近回复了
2022-02-21 18:36:34 +08:00 回复了 geist 创建的主题 › 分享创造 › 开源项目 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 内查找答案。
`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-02-21 12:45:55 +08:00 回复了 geist 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜 |
@a132811 不太懂你的意思，上面有回复过：支持 ES Module ，如果你的脚手架环境支持引入 esm 那么就可以自动引入 esm 。(参考： https://cdn.jsdelivr.net/npm/@geist-ui/[email protected]/esm/index.js)
2022-02-21 10:04:47 +08:00 回复了 geist 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜 |
@Macolor21 用阴谋论来推断别人的动机是不太友好的，我相信大部分人去建设 OSS 都是为了爱，至少我是很喜欢： https://unix.bio/fixed/projects
2022-02-21 10:03:41 +08:00 回复了 geist 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜 |
@shanex 为了寻找一些不一样的解决方案和理想的 Geek 风格。
2022-02-19 20:20:47 +08:00 回复了 geist 创建的主题 › 分享创造 › 开源项目 Geist 推荐大家尝尝鲜 |
@a132811
有的。
如果你正在使用 Webpack 5+ / NextJS 11+ / CRA 5+ 或其他 esbuild 解决方案即可自动 tree-shaking ，如果是以前的脚手架会自动引用 CJS ，但可以用 babel 插件，参考： https://geist-ui.dev/zh-cn/guide/bundle-size 。
有的。
如果你正在使用 Webpack 5+ / NextJS 11+ / CRA 5+ 或其他 esbuild 解决方案即可自动 tree-shaking ，如果是以前的脚手架会自动引用 CJS ，但可以用 babel 插件，参考： https://geist-ui.dev/zh-cn/guide/bundle-size 。
2022-02-18 21:23:23 +08:00 回复了 gibber 创建的主题 › 程序员 › 关于手机端列表页面操作定位的处理 |
@gibber
- 产品上：你可以埋点看看返回列表后下滑的用户比例多不多，如果对于你的业务来说这是一个常见的用户行为，那推荐做一下。
- 技术上：数据变化的处理不难，加起来未必会超过一个组件的长度，肯定是处理会更好。
- 产品上：你可以埋点看看返回列表后下滑的用户比例多不多，如果对于你的业务来说这是一个常见的用户行为，那推荐做一下。
- 技术上：数据变化的处理不难，加起来未必会超过一个组件的长度，肯定是处理会更好。
2022-02-18 21:03:21 +08:00 回复了 gibber 创建的主题 › 程序员 › 关于手机端列表页面操作定位的处理 |
如果你正在使用框架，那么保持原来的路由 keep-alive 就可以。(具体不同可以去搜解决方案)，如果滚动内容较多，可以尝试和 [虚拟滚动]( https://github.com/react-component/virtual-list) 结合。
至于回来时数据发生了变化有很多解决方案，你可以用网络请求、url 传递参数、组件内部内存交互，借助浏览器平台交互等各种方式完成 re-validate ，以剔除不需要的数据。
至于回来时数据发生了变化有很多解决方案，你可以用网络请求、url 传递参数、组件内部内存交互，借助浏览器平台交互等各种方式完成 re-validate ，以剔除不需要的数据。
2022-02-13 06:06:30 +08:00 回复了 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 。
1. Error Boundaries 没有一个 FC 的接口，如果你需要定义还是要嵌套 Class Component 。(你可以用 FC 去嵌套包裹实现它，但有多个错误边界需要处理时，Class 仍旧是最好的方案。)
2. 当你需要对外扩展一个继承组件接口时，Class 能够帮助更好的提供对外的接口定义。FC 一般会使用组合、HOC 等方式。当你需要编写库、抽象逻辑时，很可能两种都需要兼容 (组合与继承)。
3. 维护过时代码时。一些旧的代码库本身就是 Class 实现，或是代码本身引用了一些只兼容 Class 的第三方依赖。如第三方库中对组件使用了 `Component.prototype.render` 的判断；第三方库依赖了 IoC 模式等，这会约束你只能写 Class Component 。
Select Language