It might make sense to check the proposed API on the temporary API Reference first: https://xjs.dcefram.now.sh/
Key differences between the current XJS Framework:
ability to create multiple XJS instances. This "could" be useful when having one instance controlling the current XBC, while another is a remote XJS instance. (Remote logic is not yet implemented in this PR, but is planned)
small footprint. The ES6 version is around 32KB, while the minified UMD version is around 23KB compared with the current XJS which is around 220KB for the minified version. Now, it's a given that this is not yet feature complete, and the size would likely increase, but this is one of the primary objectives of 3.0.
extensible app/item properties API. If in case we missed to expose a property, you should be able to easily create your own without having to re-build the whole XJS Framework. One of the pain points of the current XJS Framework is that it's designed in such a way that you have to bake-in each and every property to the framework itself. This is one of the main reasons why newer core APIs take ages before it is supported by XJS.
Now with that out of the way, I'd like to still get some feedback on this. I have a couple of implementations that I did that I wasn't fully convinced as the right or optimal way of doing it.
For example, I exposed a property named app which has 2 methods: getProperty and setProperty. The alternative was to simply use the base class (Xjs class) instead. Consider the following:
Current implementation:
import Xjs from 'xjs';
const xjs = new Xjs();
// Getting a view
const view = xjs.getView(0);
// Getting the current scene
const scene = await view.getCurrentScene();
const items = await scene.getItems();
items[0].getProperty(foo);
items[0].setProperty(foo, bar);
// Getting the app
const app = xjs.app;
app.getProperty(foo);
app.setProperty(foo, bar);
// Notice that for the view, we use a "getter", while for the app, it's just an instance property.
The idea that I didn't go for:
const xjs = new Xjs();
xjs.getAppProperty(foo);
xjs.setAppProperty(bar);
There might be more, like as to how I structured the app properties and item properties, etc. I'd like to request another set of professional eyes to look into the structure and API, and see if it's worth spending more time on :)
Oh, and does this work? Yes, it does. You can checkout the test app I did to ensure what I'm doing is not just an unusable experiment: https://github.com/dcefram/xjs-playground
Request For Comments (RFC):
It might make sense to check the proposed API on the temporary API Reference first: https://xjs.dcefram.now.sh/
Key differences between the current XJS Framework:
Now with that out of the way, I'd like to still get some feedback on this. I have a couple of implementations that I did that I wasn't fully convinced as the right or optimal way of doing it.
For example, I exposed a property named
appwhich has 2 methods:getPropertyandsetProperty. The alternative was to simply use the base class (Xjs class) instead. Consider the following:Current implementation:
The idea that I didn't go for:
There might be more, like as to how I structured the app properties and item properties, etc. I'd like to request another set of professional eyes to look into the structure and API, and see if it's worth spending more time on :)
Oh, and does this work? Yes, it does. You can checkout the test app I did to ensure what I'm doing is not just an unusable experiment: https://github.com/dcefram/xjs-playground
You can also install this through npm: