I have created a personal website to put those demos [1]. It doesn't finish
yet and could be linked form Weex's official website when it's done.
It's a static website at present, developers can add examples through PR. I
think we could let developers modify or add examples online if it has a
backe
Moreover, I think our playground app should be redesigned.
Most examples are based on the ".we" framework, which will be removed soon.
Even those examples written in Vue are not the best practice and have no
reference value. The UI of it is also rough and has not been updated for a
long time. We s
+1. Currently, multiple js bundles are executed in the same js context, and
the isolation is implemented by js, which is not robust.
In my opinion, the most reasonable solution is to distinguish the "Global
Context" and the "Instance Context", move the logic of instance management
and code executi
Weex is using custom js engine (JavascriptCore) on Android. Its version is
new and supports almost all ES6 features, except modules.
I think this is a good opportunity to use ES6 in js framework and remove
useless polyfills. It can improve the js runtime efficiency on Android.
However, we can't u
[
https://issues.apache.org/jira/browse/WEEX-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang reassigned WEEX-95:
---
Assignee: YorkShen (was: Adam Feng)
> border-radius is overlap on Andr
within
> > the community. Normally this goes much quicker then anyone expect. If the
> > discussion is settle down. the proposal is accepted.
> >
> > I will answer to the other points in a separate mail
> >
> > Regards, Raphael
> >
> > Am .10.
[
https://issues.apache.org/jira/browse/WEEX-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251007#comment-16251007
]
Hanks Zhang commented on WEEX-114:
--
I can offer an example: http://dotwe.org
starts, we discuss it out and try to rich consensus within
> the community. Normally this goes much quicker then anyone expect. If the
> discussion is settle down. the proposal is accepted.
>
> I will answer to the other points in a separate mail
>
> Regards, Raphael
>
>
&
Hanks Zhang created WEEX-97:
---
Summary: font-weight and linear-gradient can't be reset on iOS and
web
Key: WEEX-97
URL: https://issues.apache.org/jira/browse/WEEX-97
Project: Weex
Issue Type
Hanks Zhang created WEEX-95:
---
Summary: border-radius is overlap on Android
Key: WEEX-95
URL: https://issues.apache.org/jira/browse/WEEX-95
Project: Weex
Issue Type: Bug
Reporter: Hanks
e" framework in dev and debug tools.
4. Remove the source code of ".we" framework, as well as the related test
cases, build scripts and migration documents.
The first two steps can be performed immediately. 3 and 4 should be done in
2018 January.
Best Regards, Hanks
2017-10-30 1
gt; let us put burden down and traveling light :)
> >
> > Hanks Zhang 于2017年10月27日 周五13:25写道：
> >
> >> OK, that's a good idea.
> >>
> >> The issue is created. [WEEX-90]
> >> https://issues.apache.org/jira/browse/WEEX-90
> >>
>
[
https://issues.apache.org/jira/browse/WEEX-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16221795#comment-16221795
]
Hanks Zhang commented on WEEX-90:
-
+1. The .we framework related documents have alr
than Dong
>
> On 26 Oct 2017, 3:05 PM +0800, Adam Feng , wrote:
> +1， I suggest removing all the other documents about ".we" except the 2
> documents you mentioned, let’s speed up the migration.
>
> Thanks.
> Adam Feng
>
> On 26 Oct 2017, 2:04 PM +0800, Hank
Hanks Zhang created WEEX-90:
---
Summary: Remove The Legacy Weex DSL 1.0 (.we) Front-End Framework
Key: WEEX-90
URL: https://issues.apache.org/jira/browse/WEEX-90
Project: Weex
Issue Type: Bug
Weex DSL 1.0 (.we) front-end framework is inspired by Vue.js 1.0. Since
Weex supports the official Vue.js 2.0 in v0.10.0 [1] at 2017-02-17, the
".we" framework is deprecated. In order to optimize the performance,
stability, and package size, this legacy framework should be removed from
the WeexSDK.
Hi, Raphael
As far as I know, our workflow is adjusted, documents are reorganized and
assigned to the specific person to rewritten them. We all take part in it.
After all the documents are ready we'll deploy the new website to the
server.
1. The "contribution" related documents [1] are finished a
s.
> Adam Feng
>
> On 13 Oct 2017, 9:00 PM +0800, Hanks Zhang , wrote:
> > Hi everybody,
> >
> > I think to put our website in the incubator-weex-site [1] repo is more
> > properly. I have already reorganized the structure of our documents and
> > website, I wil
Hanks Zhang created WEEX-86:
---
Summary: Reorganize the structure of documents and website
Key: WEEX-86
URL: https://issues.apache.org/jira/browse/WEEX-86
Project: Weex
Issue Type: Improvement
such a big repo
> which contains everything(iOS, Android, JS, Website, Document, etc.),
> finding the documents' location always makes my life harder.
>
>
> Thanks.
> Adam Feng
>
> On 11 Oct 2017, 1:14 PM +0800, Hanks Zhang , wrote:
> > Dear Weex Members,
> >
I'm sure using GitHub issues will be more convenient, but I also worried it
to be abused.
Currently, members of Weex can assign, add labels, resolve, close an issue
on JIRA. If we use GitHub issues, I wonder if we have permissions to manage
them? Otherwise, it will be easy to get out of control.
Cheers!
According to my observation, our documents and tools are often questioned
in the community. If we do improve that, developers can use weex more
easily and it can also inspire the community.
I'm reorganizing the structure of our documents and website. Considering
that our developers are va
[
https://issues.apache.org/jira/browse/WEEX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang resolved WEEX-51.
-
Resolution: Fixed
> The console APIs doesn't work on
[
https://issues.apache.org/jira/browse/WEEX-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang resolved WEEX-32.
-
Resolution: Resolved
> weex-vue-framework add services mechan
[
https://issues.apache.org/jira/browse/WEEX-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang resolved WEEX-54.
-
Resolution: Resolved
> [proposal] Support to detect the feature compatibility of w
[
https://issues.apache.org/jira/browse/WEEX-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang resolved WEEX-78.
-
Resolution: Resolved
> The ES7 methods should be removed to improve compatibil
Dear Weex Members,
Currently, the source code of Weex website is in the doc subfolder of
incubator-weex [1]. It's independent of Weex SDK.
I wonder if it's a good idea to move the website out of the incubator-weex
repo. As we adjust our commit and pr strategy, I think it would be more
efficient t
[
https://issues.apache.org/jira/browse/WEEX-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang updated WEEX-78:
Summary: The ES7 methods should be removed to improve compatibility (was:
The ES7 methods should be remove to
Hanks Zhang created WEEX-78:
---
Summary: The ES7 methods should be remove to improve compatibility
Key: WEEX-78
URL: https://issues.apache.org/jira/browse/WEEX-78
Project: Weex
Issue Type: Bug
[
https://issues.apache.org/jira/browse/WEEX-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16183600#comment-16183600
]
Hanks Zhang commented on WEEX-75:
-
+1
> [Vote] change weex bran
[
https://issues.apache.org/jira/browse/WEEX-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang updated WEEX-54:
Description:
h2. Background
Because Weex support to extend components and modules, so the host environment
Hanks Zhang created WEEX-54:
---
Summary: [proposal] Support to detect the feature compatibility of
weex
Key: WEEX-54
URL: https://issues.apache.org/jira/browse/WEEX-54
Project: Weex
Issue Type: New
[
https://issues.apache.org/jira/browse/WEEX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang updated WEEX-51:
Summary: The console APIs doesn't work on Android (was: Fix the console
API to adapt JSC on Android)
Hanks Zhang created WEEX-51:
---
Summary: Fix the console API to adapt JSC on Android
Key: WEEX-51
URL: https://issues.apache.org/jira/browse/WEEX-51
Project: Weex
Issue Type: Bug
The Weex runtime has some legacy hack of the console on Android platform.
As we switch the js engine from v8 to JSC on Android, the legacy hacks
didn't work well.
I have already fixed this in https://github.com/apache/
incubator-weex/pull/470 . It will be merged after code review.
Because not all
Yes, we have already support "addElement" for a long time, but not include
the other methods, such as "updateAttrs".
By the way, we have refactored Weex runtime to use "TaskCenter" and
"CallbackManager" to manage the render tasks. The Vue.js 2.0 should have a
slight change to adapt it.
2017-03-13
I found the examples of Vue.js in our repo is outdated. Especially since we
upgrade the weex-vue-framework to 2.2.1, compile the examples will get the
warning as follow:
"component lists rendered with v-for should have explicit keys."
That's because of the Vue.js 2.2.0 [1] add this restriction: "
That's great.
Since most of our users are Chinese currently. It's quite a good news for
China developers.
2017-03-14 9:36 GMT+08:00 Dong Yun :
> Hi, Everyone!
>
>
> I've got good news: we'll deploy a mirror site in China, it will increase
> the speed with which docs and website can be accessed.
Thanks for doing this.
The code in the gist [1] might be able to execute the js bundle, but still
need some modifications. The "normalize" method should move to Weex
runtime. The "instances" object seems to have no chance to contain the
instance, and the callback may not works well.
Moreover, the
As we discussed before, we should support all top-level DOM operation APIs
directly to improve the performance. I have already achieved it in Weex
runtime, include the following methods:
Format: TAKS -> METHOD
* createBody -> callCreateBody
* addElement -> callAddElement
* removeElement -> call
WebAssembly is a new portable, size- and load-time-efficient binary format
suitable for compilation to the web. [1] It's a new technology tendency and
reached consensus by Chrome, Edge, Firefox, and WebKit. [2] It will affect
the developer's choice between web and native (or Weex). However, it will
Great ! I also found a lot of duplication in our GitHub issues. I think we
could summarize the FAQ and record it to StackOverflow and SegmentFault at
first.
2017-01-18 11:08 GMT+08:00 BryantWu :
>
> That's a good idea！We should guide more community developers。
> -
101 - 142 of 142 matches
Mail list logo
