XCFOX

XCFOX

V2EX 第 433443 号会员,加入于 2019-08-01 22:06:00 +08:00
今日活跃度排名 18060
XCFOX 最近回复了
不用设计,已经有现成的 GO 语言了
现阶段选 React 不会错,生态比其他好得多,js 性能问题也解决了。

React 可以开发前端,做 APP 直接用 React Native/Capacitor ,做小程序用 Taro 。React 理论上可以适配到所有图形引擎或者平台上,包括 Flutter 同款的 Skia ,要是 Impeller 性能出色的话,React 再适配到 Impeller 也完全可行。

新出炉的 React Native 0.76 默认启用了新架构,性能大幅提升,再加上 hermes 引擎,js 的执行速度早就不是瓶颈。

Flutter 的优势是界面是完全自绘,能保证所有平台的一致性。这同时也意味着放着完善的 ios/android 生态不用,全部都另起炉灶。这当然是值得鼓励的,但是谷歌给到 Flutter 的支持显然不如 Apple 给到 iOS 的,也不如谷歌自己给到 Android 的,于是 Flutter 在体验上始终与原生 APP 存在差距,尤其是高帧率逐渐普及之后,Flutter 不得不放弃 Skia 自研 Impeller 。

可以体验一下 V2EX 的 Flutter 客户端和 React Native 客户端,Flutter 版本滑动、翻页的时候存在明显卡顿,RN 的体验明显好得多。
https://github.com/guozhigq/flutter_v2ex
https://github.com/liaoliao666/v2ex
47 天前
回复了 cokey 创建的主题 Android 应该选择哪种跨平台方案
React 的思路和 Flutter 非常不一样。
React 有一层虚拟 DOM ,目前 React 的虚拟 DOM 适配了 web(react-dom)、iOS | Android (React Native)、windows (react-native-windows) 还有社区维护的 tvOS 、Skia ,甚至 React 还能直接渲染到视频 ( https://www.remotion.dev/) 。按理说要是 Flutter 的 Impeller 性能出色的话,React 再适配到 Impeller 也完全可行。
而 Flutter 想做的是跨平台的图形界面的渲染引擎。Flutter 的界面是完全自绘的,这意味着放着完善的 ios/android 生态不用,全部都另起炉灶。这当然是值得鼓励的,但是谷歌给到 Flutter 的支持显然不如 Apple 给到 iOS 的,也不如谷歌自己给到 Android 的,于是 Flutter 在体验上始终与原生 APP 存在差距,尤其是高帧率逐渐普及之后,Flutter 不得不放弃 Skia 自研 Impeller 。

新出炉的 React Native 0.76 默认启用了新架构,性能大幅提升,再加上 hermes 引擎,js 的执行速度早就不是瓶颈。

而 Flutter 好像越来越不受 Google 重视了( https://www.v2ex.com/t/1084590 ) ,之前提到的全新 Impeller 引擎还没有完成 ( https://github.com/orgs/flutter/projects/21 ) ,期待 Impeller 能够拉近 Flutter 与原生的差距。

我个人体验下来 React Native 的流畅度是显著好于 Flutter 的,React Native 在动画表现上确实 Native 。Flutter 写的页面一滑动就知道是 Flutter 写的(看惯了 120 hz 再看 60hz 肉眼可见掉帧)。

可以体验一下 V2EX 的 Flutter 客户端和 React Native 客户端,Flutter 版本滑动、翻页的时候存在明显卡顿,RN 的体验明显好得多。
https://github.com/guozhigq/flutter_v2ex
https://github.com/liaoliao666/v2ex
其实,除了你,我们都是 NPC
1. GraphQL 需要整个团队巨额的学习成本,相比整个用 GraphQL 重构不如糊个 BFF 层; GraphQL 的生态和普及度还比不上 RESTful ;

2. 权限处理和 RESTful 并无二致,在请求进来时判断用户权限,在查数据库时加额外条件;

3. 我个人理解拿到参数就能验证了,楼主可能在找一种更便捷的验证手段,推荐使用 GQLoom 框架( https://gqloom.dev/ ),天然集成 zod 、valibot 作为验证库,有完善的中文文档。
86 天前
回复了 BeijingBaby 创建的主题 GraphQL 国内用 GraphQL 的好像不多?
GraphQL 很好用,对比 RESTful API 简直完胜。但是很多人并不理解 GraphQL ,甚至把 GraphQL 和 SQL 混为一谈。

GraphQL 在团队开发中解决了 3 个主要问题:
1. 服务端到客户端的强类型:GraphQL 本身是一门语言,而且是强类型语言。使用 GraphQL 客户端能够通过服务端提供的 schema 生成全面的 API 类型,极大减轻了前端的负担;
2. 文档与沟通:每个 GraphQL 服务都会有一个 schema 文件,这个文件就描述了该服务内的所有接口,要了解该服务可以直接看 schema 而不是代码;
3. 接口聚合:GraphQL 允许客户端定义要获取的字段,前端想拿什么接拿什么,避免了前后端扯皮( https://www.v2ex.com/t/1036619 )。大型项目里常常需要 BFF 中间层也是为了接口聚合,很多 BFF 层甚至都是拿 GraphQL 搞的。

看楼主的发言,我估计后端是直接用 PostGraphile, hasura 这样的框架直接把数据库表以 GraphQL 的形式暴露给前端。不得不说这是效率极高的做法,但是很难控制权限访问,只适合快速开发阶段使用。常规开发时我还是建议使用 nest.js 这样的框架老老实实做功能。

顺带安利我们团队自研的 GraphQL 框架 GQLoom:
https://github.com/modevol-com/gqloom
GQLoom 是实现优先( Implementation-First )的 GraphQL 框架,适用于 JavaScript/TypeScript 。GQLoom 最大的亮点是允许使用 Zod 、Valibot 这样的 Schema 库构建 GraphQL ,代码简洁且有完善的类型安全,马上会跟进对 Prisma 、Drizzle ORM 的集成。
TypeORM

> 当我把一个表字段定义为 nullable: true 或者 nullable: false 的时候,似乎并不影响这个字段在代码里是 optional 还是 required ?

是的,装饰器无法影响 class 内属性的类型。


> 如果我不通过 ORM 自动建表,而是自己在 navicat 里建表,那是不是 TypeORM 里面的 @Column 装饰器参数就没有任何意义?

不完全是,@Column 装饰器参数的主要作用就是生成简表语句,其次 TypeORM 在运行时会通过装饰器参数(元数据)做一些判断,避免一些错误的 SQL 。

> 我定义一个 Entity ,所有字段都是 Not Null 的,类型也都是 required 的,结果 TypeORM 允许我往这个表里保存空对象?等着数据库报错?

是的,装饰器无法影响 class 内属性的类型。但为了更好的类型安全你应该在 tsconfig.json 中配置 strictPropertyInitialization 为 ture ,并为每个属性声明是否为 nullable ( https://typescriptlang.org/tsconfig/#strictPropertyInitialization )

我个人建议你尽早抛弃 TypeORM ,TypeORM 项目已经不再积极维护了。换更严谨 mikro-orm ( https://mikro-orm.io/ ),mikro-orm 能通过 ts-morph 从 class property 提取类型以及 nullable ,能够避免装饰器内 nullable 属性与 class property 声明的 nullable 不一致的情况
https://mikro-orm.io/docs/defining-entities
tRPC 简单但严谨
https://trpc.io/
125 天前
回复了 weiwenhao 创建的主题 前端开发 2024 年 rn 和 flutter 怎么选
React Native 和 Flutter 的思路很不一样。

React Native 秉承 React + web 的理念,使用 React + JavaScript 运行时借助各平台原生组件呈现视图。
React Native 的优势是:可以轻松使用系统原生视图、获得原生级的用户体验和动画流畅度,使用 js ,能够轻松热更新;
React Native 的缺点是:在各个平台呈现的视图不一致;

Flutter 使用自己的绘图引擎,在各个平台上自绘视图,运行机制更接近游戏引擎。
Flutter 的优势是能够自制复杂的视图控,;在所有平台上获得一致的视图;
Flutter 的缺点是:Flutter 的绘图引擎( Skia 、Impeller )比不过原生的动画流畅性和交互体验,这方面有太多的 issues 了:动画反馈会延迟 1~3 帧,无法使用 Android 12 的滚动回弹动画,滑动和翻页时有明显的掉帧,严重的着色器编译时卡顿( https://docs.flutter.dev/perf/shader ) ;难以在 Flutter 视图内嵌入原生组件

另外近些年前端的开发理念一直比较领先,React 虽然稍微落后 vue3 、solidjs 、qwik ,但比起 Flutter 还是领先一个大版本的。Flutter 使用嵌套地狱写视图,React 有 jsx ; React 状态管理的 zustand 、jotai 、valti 一个比一个简单易用,Flutter 连 hook 都没有。

对于不需要复杂的绘图操作的 APP ,也就是普通 新闻、聊天 APP 的话,应该首选 RN + expo ;如果你要开发具有复杂视图的 APP ,比如游戏、谷歌地球、高德地图、Wonderous ,应该首选 Flutter 。
具体到楼主的 记账 APP ,肯定首先 React Native 。

建议体验一下 V2EX 的 Flutter 客户端和 React Native 客户端,Flutter 版本滑动、翻页的时候存在明显卡顿,RN 的体验明显好得多。
https://github.com/guozhigq/flutter_v2ex
https://github.com/liaoliao666/v2ex
134 天前
回复了 Gabrielle70 创建的主题 程序员 求推荐 GraphQL 服务器端(nodejs)框架
推荐 Nest.js ,应该是最完善的 GraphQL(node.js) 框架了,并且有丰富的生态
https://docs.nestjs.com/graphql/quick-start

不喜欢 Nest.js 依赖注入这一套的可以就用 TypeGraphQL: https://typegraphql.com/

如果想要类型安全,推荐 Pothos ,Pothos 的问题是过于学术派以至于开发体验不好,需要写很多冗余重复代码以确保程序正确
https://pothos-graphql.dev
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3463 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 04:52 · PVG 12:52 · LAX 20:52 · JFK 23:52
Developed with CodeLauncher
♥ Do have faith in what you're doing.