You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by 汤威 <tw...@qq.com> on 2018/01/21 04:00:57 UTC
Discussion of weex components in the round table conference - 2018 Weex conf
Discussion of weex components in a round table conference
A simple introduction
Hello everybod，I'm YouXi(Tw93) from the Fliggy user technology team, Currently maintaining weex-ui components.
First of all, Congratulations on the success of 2018 weex conf. 🎉🎉🎉🎉
I would like to introduce our four aspects of the Weex component in round table discussion.
What we need to pay attention to when encapsulating native components ?
Common features：We need to consider whether this component will be used in more than one business, as well as a removable, or mature, functional component in native. Such as Video/TabBar/TitleBar/ImageUpload components.
Stability, Because the native components do not like weex upper component has a very good regulatory, so we must need to pay attention to good native components must need no bug, prevent repair and update time will have trouble. Also need to pay attention to the native components should be given the most part at the beginning, to prevent frequent updates, led to the need to fit a lot of versions.
Atomicity, not suggesting that a component does a lot of things at the same time, should be a single function, and then get more functionality through the collocation method.
What's good experience in the development and practice of Weex UI components ?
811 principles：80% features should be the default, users don't need configure many parameters. And let users configure some parameters to achieve 10% features. A rare case of 10% can temporarily don't be considered, here may cost a lot of time to develop, so we can wait for when the user needs to update it.
Need someone unify：In order to avoid the components into a hodgepodge, subsequent iterations visual interaction, adding new features need to be taken into account. Commonality here need a unified the convergent, development maintenance can avoid a lot of business to interfere with the availability of components. But the more ideas there are, the better.
Performance experience, Weex components need to ensure performance experience more than H5 components.
Trust mechanism: A lot of times when someone uses your component, a big reason is to believe that the component is not buggy, is stable and good, and will be maintained later.
What do you think Weex Ui is still missing?
Currently, the use of a single component has been described in detail, but for some use of multiple components, or a lack of relevant cases at the page level, the latter needs to be patched up.
More often than not, the theme color is changed by parameter configuration, which can be modified by a unified external parameter configuration.
What is the future of cross-end development?
Native layout needs to learn from the development flexibility of H5, and gradually use the automatic layout to realize it. Meanwhile, flexbox development is introduced to avoid absolute calculation.
Data binding is becoming more and more convenient, like MVVM, when the data changes, the view is immediately modified, not triggered manually.
These are some of the conclusions of our discussion. Thank you for reading, and welcome to the discussion.
回复：答复: [weex.incubator.apache.org代发]Discussion of weex components in the round table conference - 2018 Weex conf
Posted by 汤威 <tw...@qq.com>.
It can be done by flexbox's flex-wrap
https://github.com/alibaba/weex-ui/blob/master/packages/wxc-grid-select/index.vue#L129
------------------ 原始邮件 ------------------
发件人: "黄炳金";<hu...@landicorp.com>;
发送时间: 2018年1月25日(星期四) 上午9:48
收件人: "dev@weex.incubator.apache.org"<de...@weex.incubator.apache.org>;
主题: 答复: [weex.incubator.apache.org代发]Discussion of weex components in the round table conference - 2018 Weex conf
Hi TW,
I'm grad to hear that.
The GridSelect component display from top to bottom on android platform, do you have any suggestion to solve this problem?
Best Regards!
HuangBJ
-----邮件原件-----
发件人: 汤威 [mailto:tw93@qq.com]
发送时间: 2018年1月21日 12:01
收件人: dev
主题: [weex.incubator.apache.org代发]Discussion of weex components in the round table conference - 2018 Weex conf
Discussion of weex components in a round table conference
A simple introduction
Hello everybod，I'm YouXi(Tw93) from the Fliggy user technology team, Currently maintaining weex-ui components.
First of all, Congratulations on the success of 2018 weex conf. 🎉🎉🎉🎉
I would like to introduce our four aspects of the Weex component in round table discussion.
What we need to pay attention to when encapsulating native components ?
Common features：We need to consider whether this component will be used in more than one business, as well as a removable, or mature, functional component in native. Such as Video/TabBar/TitleBar/ImageUpload components.
Stability, Because the native components do not like weex upper component has a very good regulatory, so we must need to pay attention to good native components must need no bug, prevent repair and update time will have trouble. Also need to pay attention to the native components should be given the most part at the beginning, to prevent frequent updates, led to the need to fit a lot of versions.
Atomicity, not suggesting that a component does a lot of things at the same time, should be a single function, and then get more functionality through the collocation method.
What's good experience in the development and practice of Weex UI components ?
811 principles：80% features should be the default, users don't need configure many parameters. And let users configure some parameters to achieve 10% features. A rare case of 10% can temporarily don't be considered, here may cost a lot of time to develop, so we can wait for when the user needs to update it.
Need someone unify：In order to avoid the components into a hodgepodge, subsequent iterations visual interaction, adding new features need to be taken into account. Commonality here need a unified the convergent, development maintenance can avoid a lot of business to interfere with the availability of components. But the more ideas there are, the better.
Performance experience, Weex components need to ensure performance experience more than H5 components.
Trust mechanism: A lot of times when someone uses your component, a big reason is to believe that the component is not buggy, is stable and good, and will be maintained later.
What do you think Weex Ui is still missing?
Currently, the use of a single component has been described in detail, but for some use of multiple components, or a lack of relevant cases at the page level, the latter needs to be patched up.
More often than not, the theme color is changed by parameter configuration, which can be modified by a unified external parameter configuration.
What is the future of cross-end development?
Native layout needs to learn from the development flexibility of H5, and gradually use the automatic layout to realize it. Meanwhile, flexbox development is introduced to avoid absolute calculation.
Data binding is becoming more and more convenient, like MVVM, when the data changes, the view is immediately modified, not triggered manually.
These are some of the conclusions of our discussion. Thank you for reading, and welcome to the discussion.
答复: [weex.incubator.apache.org代发]Discussion of weex components in the round table conference - 2018 Weex conf
Posted by 黄炳金 <hu...@landicorp.com>.
Hi TW,
I'm grad to hear that.
The GridSelect component display from top to bottom on android platform, do you have any suggestion to solve this problem?
Best Regards!
HuangBJ
-----邮件原件-----
发件人: 汤威 [mailto:tw93@qq.com]
发送时间: 2018年1月21日 12:01
收件人: dev
主题: [weex.incubator.apache.org代发]Discussion of weex components in the round table conference - 2018 Weex conf
Discussion of weex components in a round table conference
A simple introduction
Hello everybod，I'm YouXi(Tw93) from the Fliggy user technology team, Currently maintaining weex-ui components.
First of all, Congratulations on the success of 2018 weex conf. 🎉🎉🎉🎉
I would like to introduce our four aspects of the Weex component in round table discussion.
What we need to pay attention to when encapsulating native components ?
Common features：We need to consider whether this component will be used in more than one business, as well as a removable, or mature, functional component in native. Such as Video/TabBar/TitleBar/ImageUpload components.
Stability, Because the native components do not like weex upper component has a very good regulatory, so we must need to pay attention to good native components must need no bug, prevent repair and update time will have trouble. Also need to pay attention to the native components should be given the most part at the beginning, to prevent frequent updates, led to the need to fit a lot of versions.
Atomicity, not suggesting that a component does a lot of things at the same time, should be a single function, and then get more functionality through the collocation method.
What's good experience in the development and practice of Weex UI components ?
811 principles：80% features should be the default, users don't need configure many parameters. And let users configure some parameters to achieve 10% features. A rare case of 10% can temporarily don't be considered, here may cost a lot of time to develop, so we can wait for when the user needs to update it.
Need someone unify：In order to avoid the components into a hodgepodge, subsequent iterations visual interaction, adding new features need to be taken into account. Commonality here need a unified the convergent, development maintenance can avoid a lot of business to interfere with the availability of components. But the more ideas there are, the better.
Performance experience, Weex components need to ensure performance experience more than H5 components.
Trust mechanism: A lot of times when someone uses your component, a big reason is to believe that the component is not buggy, is stable and good, and will be maintained later.
What do you think Weex Ui is still missing?
Currently, the use of a single component has been described in detail, but for some use of multiple components, or a lack of relevant cases at the page level, the latter needs to be patched up.
More often than not, the theme color is changed by parameter configuration, which can be modified by a unified external parameter configuration.
What is the future of cross-end development?
Native layout needs to learn from the development flexibility of H5, and gradually use the automatic layout to realize it. Meanwhile, flexbox development is introduced to avoid absolute calculation.
Data binding is becoming more and more convenient, like MVVM, when the data changes, the view is immediately modified, not triggered manually.
These are some of the conclusions of our discussion. Thank you for reading, and welcome to the discussion.