You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/10/11 10:06:00 UTC
[jira] [Commented] (WEEX-17) Abstract a common `weex` variable for
each JS framework
[ https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200055#comment-16200055 ]
ASF GitHub Bot commented on WEEX-17:
------------------------------------
GitHub user Hanks10100 opened a pull request:
https://github.com/apache/incubator-weex/pull/785
[WEEX-17] Abstract "weex" variable for each js framework
Fix [WEEX-17](https://issues.apache.org/jira/browse/WEEX-17).
Pass the `weex` variable to each front-end framework in the last argument of `createInstance`. Its API is defined [here](http://weex.apache.org/references/weex-variable.html).
Both Vue and Rax can use the `weex` variable with the same implementation. Currently, Vue passed `weex` variable to the js bundle, but Rax doesn't pass it yet.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Hanks10100/incubator-weex jsfm-feature-weex
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-weex/pull/785.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #785
----
commit 48ccea1c4edc02b7af80e81f5639243776bef077
Author: Hanks <zh...@gmail.com>
Date: 2017-10-11T09:19:48Z
+ [jsfm] add weex variable api in runtime
----
> Abstract a common `weex` variable for each JS framework
> -------------------------------------------------------
>
> Key: WEEX-17
> URL: https://issues.apache.org/jira/browse/WEEX-17
> Project: Weex
> Issue Type: Improvement
> Reporter: Jinjiang Zhao
> Priority: Minor
> Labels: features
>
> I think before a Weex instance initialized by a certain JS framework, we can abstract and prepare something which every JS framework will do the same and put them into a common `weex` variable. Then this variable could be used directly in a JS framework.
> It contains:
> 1. A CallbackManager instance: to convert callback into a unique callbackId in this Weex page, just for passing the id to native as the callback itself.
> 2. A NativeModuleGetter instance: to require a native module in this Weex page. Because it certainly need processes functions, so it depends on the CallbackManager instance.
> 3. A Document instance: every Weex page must have and only have one Document instance.
> 4. Config object of the Weex page. It should contains env info, framework info and bundle info.
> 5. CSS Units calculator. It depends on config object.
> 6. All injects from JS Services.
> All of above could be passed into JS framework for init. And NativeModuleGetter instance, Document instance, config object and CSS units calculator could be exposed on `weex` variable as `{ requireModule(name), document, config, unit }`. So the new API design of `framework.createInstance` could be:
> function createInstance(id, code, info)
> and parameter info contains: { weex, callbacks, services }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)