openwebf/webf

一些未来发展的建议

Closed this issue · 8 comments

mchao123 commented

Should this be an RFC?

  • This is not a substantial change

Description

也许可以不追求浏览器标签，定义一个使用flutter组件的规范，以及常用接口的api封装，剩下的交给社区，将重心放在核心优化上，比如更快的速度、更低的内存占用。
反正flutter可以打包web，一样跨全端。

Alternatives and Workarounds

No response

mchao123 commented

让程序拥抱flutter社区，而不是尝试重现一个浏览器，复现常用的api让大部分的前端库可以正常工作，定义一个通用的flutter组件注册方法，开发者可以直接用flutter社区的ui组件，而不用像现在这样担心兼容性问题而不敢入手。

mchao123 commented

去掉为了兼容浏览器而专门写的组件，相信框架体积也会大大缩小，从原先的大体积框架，改为小巧的胶水层，我相信大有可为，直接遥遥领先（狗头）

andycall commented

我想你要的是通过 Flutter Widget 扩展自定义 Element 的功能，这块还没有完整的文档，可以看下 demo 体验一下。

https://github.com/openwebf/samples/blob/main/demos/widget-elements/front-end/src/views/Action-Sheet/ActionSheetChild.vue

  • 👍1
mchao123 commented

不是自定义组件给js使用，大概类似这样的
前端：

import { regiterFlutterCompoent } from '@webf/api';
regiterFlutterCompoent<PropsType>('tag',{
  path:'lib/myCompoents',
  name:'Comp',
  validation:()=>{
    // 类型校验
    return false;
  }
});

编译时，将flutter目录下的lib/myCompoents.dart里的Comp引入，然后交给dart编译，前端则把PropsType转换为jsx的类型声明

mchao123 commented

并不是mxflutter

andycall commented

对于 WebF 来说，它的目标是打造更好的 Web。而基于 Flutter 只是手段，不是最终的目标

  • 👍1
zongren commented

Should this be an RFC?

  • This is not a substantial change

Description

也许可以不追求浏览器标签，定义一个使用flutter组件的规范，以及常用接口的api封装，剩下的交给社区，将重心放在核心优化上，比如更快的速度、更低的内存占用。 反正flutter可以打包web，一样跨全端。

Alternatives and Workarounds

No response

这不就是纯粹的flutter吗