You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by "Jinjiang Zhao (JIRA)" <ji...@apache.org> on 2017/01/25 01:17:26 UTC

[jira] [Created] (WEEX-17) Abstract a common `weex` variable for each JS framework

Jinjiang Zhao created WEEX-17:
---------------------------------

             Summary: 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


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.3.4#6332)