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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216509#comment-16216509
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user Hanks10100 commented on the issue:

https://github.com/apache/incubator-weex/pull/785
  
Got, this PR can be closed.


> 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
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216510#comment-16216510
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user Hanks10100 closed the pull request at:

https://github.com/apache/incubator-weex/pull/785


> 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
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207224#comment-16207224
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user gurisxie commented on the issue:

https://github.com/apache/incubator-weex/pull/785
  
I have merged it,but bot seems broken.


> 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
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200064#comment-16200064
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user weex-bot commented on the issue:

https://github.com/apache/incubator-weex/pull/785
  





  

  
  Warnings

  
  
  :warning:
  No Changelog changes!

  

  :warning:
  These new JS files do not have Flow enabled: 
html5/runtime/api/WeexInstance.js, html5/runtime/api/component.js, 
html5/runtime/api/module.js

  

  :warning:
  This PR should update related documents as well. 

  




  

  
  Messages

  
  
  :book:
  danger test finished.

  




  Generated by :no_entry_sign: http://github.com/danger/danger-js/;>dangerJS




> 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)

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
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)

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869085#comment-15869085
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user Jinjiang closed the pull request at:

https://github.com/apache/incubator-weex/pull/1


> 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.3.15#6346)