I want to integrate an ES6 Dependency (vtk.js) into a Qooxdoo Application. I don't know how to manage this. Here is an Example to use the vtk.js. So my Question is:
Is it Possible to integrate ES6 Dependencys?
When it is possible, what i have to do?
The short answer is yes, with some caveats. Qooxdoo v5 (the current release) does not support ES6 constructs in code, because (a) the generator will not accept that syntax and (b) ES6 requires strict mode and there's a compatibility issue which prevents it working.
You could use Qooxdoo v5 with an ES6 library, provided that you don't want to write ES6 code yourself - strict mode is specified on a per-file basis, and your only restriction is to not enable it on code which the generator compiles (ie your code).
However, Qooxdoo v6 supports ES6 out of the box, provided that you use the new compiler (at github.com/qooxdoo-compiler). This compiler will allow you to write ES6 code and transpile it on the fly so that you can also achieve platform independence.
Qooxdoo v6 is in beta and available via github.com/qooxdoo - the master branch is very stable and used in production by core team members so is worth consideration.
In v6 you can customise the index.html generation, or use the externalResources key in compile.json (if you're using the compiler) or handle loading yourself via qx.io.DynamicScriptLoader.
Once the javascript is loaded, you then need to create a custom class derived from qx.ui.core.Widget and override these methods:
_createContentElement- override this method to create the DOM element that implements your widget, i.e. this is where you would initialise a VTK instance
_getContentHint() - this returns a map of preferred height & width for the widget; it's job is to tell the Qooxdoo layout engine how big the widget would like to be
renderLayout - this method is called to make the element appear on screen and at a given size and position - in practice, this means that you use this method to modify the dimensions of the DOM element which implements your custom widget
Once you've done that, you will have a custom widget that integrates with Qooxdoo; all that remains is to either expose the internal VTK implementation or build an API to operate VTK through.
Related
A client has request me to build a set of reusable components / widget to be integrated on legacy web development (JQuery, ES5 based).
My idea is to create:
A library that will make use of React / Preact to build the widgets.
Use ES6/TS + webpack + babel, to end up transpiling to ES5 and packing it into a library.
My main concern comes with the third party libraries dependencies(e.g. react, react-dom or preact…), I’m thinking about taking one of this two approaches:
A. Treat third party libraries as just external dependencies, the legacy application that needs to consume my widget library have to reference that library.
Pros: no extra weight added to my bundle, this library could be used in legacy apps and modern apps.
Cons: possible versioning hell in the future, e.g. we release the library for React 16, and in the future, they mix other widgets from another library that depend on React 18 (maybe a possible workaround is to fix versions and perform an all or nothing migration from time to time).
B. Embed preact into the library bundle:
Pros: only adding 3 to 4 Kb to the library bundle, the bundle is self contained.
Cons: probably we could not use these components on modern development (e.g. compose it with other components from other react based libraries).
What could be the best approach? Is there another option available? Does approach B make sense? (haven’t tried that one before).
I would lean to the B answer.
if you need to combine them with other libraries, you still have the sources in ES6+ which allows you to import them easily inside a new project.
I actually only work with the B approach because it removes the dependency nightmare. You know that you ship code with the compatible react version, and you have total control of the final ES5 code with babel.
If you worry that much over 10kb, there's plenty of ways to reduce size (enabling compression, making sure you use production bundle, etc).
I'm trying to figure out how React Native works under the hood and something that I'm unsure of is if React Native utilizes the so-called 'virtual DOM' that React uses. I'm assuming that React Native somehow keeps track of changes to the state of the application and then does the least amount of work to get to the new state, i.e reconciliation in React. I understand that there is no real DOM on the mobile side of things and that React Native invokes native API's to render/re-render views, but...
Could one say that React Native also uses a 'virtual DOM', and if not, how would one put it into words?
UI rendering in React
Like the Real DOM, the Virtual DOM is a node tree that lists elements and their attributes and content as objects and properties. React’s render() method creates a node tree from React components and updates this tree in response to mutations in the data model, caused by actions.
So whenever anything may have changed, the entire UI will be re-rendered in a Virtual DOM representation. The difference between the previous Virtual DOM representation and the new one will be calculated. The real DOM will be updated with what has actually changed.
UI rendering in React Native
Those React-Native components map the actual real native iOS or Android UI components that get rendered on the app means React Native uses native API for the rendering of components on mobile. React Native uses a shadow thread that performs layout calculation using YOGA.
In case of any change in the component state, It will calculate the changes in the background using shadow thread then update the UI threads.
2022 Update
As React Native has changed a lot in recent times and will change a lot in the near future, I thought it's timely to update this answer:
New components to understand:
Hermes:
React Native team developed their own Javascript Engine in C++, called Hermes. If enabled, Hermes will be shipped with your app as a context for executing Javascript (instead of JSC), promising to make your app's bundle smaller, and your app's execution faster.
JSI (Javascript Interface):
It is a unified, lightweight, general-purpose layer for (theoretically) any JavaScript engine. It's implemented in C++, just as the engine, but decoupled from the engine. This makes it possible to hold references of native objects on the JS thread, eliminating the need for the bridge, thus eliminating the need to stringify everything and making React Native way faster altogether as the stringification is the bottleneck currently. It also makes it easier to switch between JS engines. As JSI is developed in C++, it makes it easier for developers to share native code between Android and iOS. For example, you can develop native code in C++, call it both on iOS and Android from Javascript through the help of JSI. Both platforms can execute C++ code, iOS can use it really easily through Objective C as it is a superset of C. Android needs a bit more work with the help of Android NDK (Native Development Kit) and JNI (Java Native Interface, responsible for Java <=> C++ translation).
Bridge will be split into two parts, read more:
Turbo modules
This is a new way of interacting with the native side, interoperable with JSI. It allows lazy initialization of packages, thus making the startup time of apps having lots of native dependencies way shorter.
Fabric renderer
Re-architecture of the UI manager, that is interoperable with JSI and Turbo modules. Instead of the Shadow Tree (or Shadow Thread) that was formerly used for calculation the layout of elements (it was coupled with the bridge), Fabric makes it possible to use the new powerful JSI features to render the ui without having to stringify anything. This will deliver truly native-like performance.
New answer for the original question:
React Native uses Fabric as a renderer, which lives in the C++ world (UI thread), has a reference to the virtual DOM, that's created by React in C++ and eliminates the need for the shadow thread as objects will be shared between the UI (native) and the JS threads. So once you click a button, React can mutate an object that it has reference to (that holds the virtual DOM), which is shared with the UI thread, that will instantly update in the UI thread, updating the UI of the app.
In the Material2 project every component uses ViewEncapsulation.None. (e.g. the MdButton)
Recently the encapsulation has just been changed to None for md-toolbar.
Why is that so? Isn't the possibility to encapsulate the CSS one of the biggest advantages of creating such a framework with Angular2.
Polymer Components seem to use this feature. Why doesn't Material2?
A while ago /deep/ and >>> were implemented for ViewEncapsulation.Emulated therefore it should be easy to style the same as with ViewEncapsulation.None.
The only reason I can think of is that SASS (or whatever preprocessor they use) doesn't support these CSS combinators because they are deprecated since almost a year in Chrome and were never implemented in other browsers.
Is there any library that provides just Model, View and Collection base classes, similar to Backbone's, but without all the router/history/sync stuff?
You may want to take a look at Exoskeleton by Paul Miller.
Exoskeleton is a faster and leaner Backbone that supports custom builds. Please note that it does not support IE below version 9. If you need to support older browsers, you might want to stick to backbone.
You can just ignore the Router and use the rest of the framework, or if you want to reduce the code footprint to absolute minimum it is not difficult to remove the Router from the code.
Another alternative is Bamboo which is a model layer solution similar to Backbone.Model. You can use it with any view/template library eg. Reactive or Ractive
ExtJS have "adapter" for working with other javascript libraries. But why? Why not just use Ext Core?
UPDATE:
I know it was designed for YUI. But why it need an adapter?
ExtJs use ExtJs namespace, almost all other framework
use $, they should never conflict.
jQuery can work with others without any adapter. Why Extjs need it?
Is there any extra functionality provided by these adapters?
Am I missing anything?
I know there are some people here that were part of the early ExtJS Team so they probably will have a better answer, but basically ExtJS started as an extension to YUI where it was using the YUI Library to create a set of components to use.
Then it was modified using the adapter design pattern to support people that were already using jQuery or Prototype which had a few advantages: Fewer JavaScript to load on the page (if you already used jQuery you didn't need to load the YUI library) and let coders re-use their existing skills.
I can only assume that as the set of Components evolved it became easier to write a core adapter written in an optimized way for the ExtJS set of Components, and not rely on an external library for bug fixing, etc.
I would add that personally, I feel much more comfortable using the Ext Core as the adapter even though I prefer jQuery for a lot of DOM manipulations, but I think there are less chances of facing bugs while using the components if the base adapter is Ext Core.
UPDATE -
Based on your updated question, I think what you are missing is the separation from Ext Core and ExtJS.
ExtJS - A library of JavaScript Components (mainly UI but also Data classes, themes, etc.) that allows to build Rich Internet Application.
Ext Core - A cross-browser javascript library used to enhance web pages with dynamic changes (some Dom Querying, Dom traversal/manipulation, Ajax requests, etc.)
If you want to make the comparison into the jQuery world, Ext Core = jQuery and ExtJS = jQueryUI.
Now with jQueryUI, you NEED the jQuery library with it, because jQueryUI is built on TOP of jQuery.
With ExtJS, because it was built on top of YUI originally even before Ext Core existed, you can if you want use ExtJS WITHOUT Ext Core, but with the jQuery or YUI adapter for example.
You CANNOT ust ExtJS on it's own without any of the adapters, just like you can't use jQueryUI without jQuery.
I hope this answer your question.
ExtJS used to be built on top of YUI, so there were adapters created for operating with other libraries as well. I think as of version 1.1, ExtJS became a standalone framework, so these adapters are now optional. I think the adapters are now for people who are more comfortable with the basic frameworks of the other libraries, but want to use certain components of the ExtJS library (Ext's greatest strength is their UI widget toolkit, IMHO).
Take a look at this SO question too:
Is jQuery compatible with ExtJS?