[
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanks Zhang resolved WEEX-17.
-----------------------------
Resolution: Done
> 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
> Assignee: Hanks Zhang
> 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
(v7.6.3#76005)
