I have an existing Durandal.js app that takes advantage of all of the ES5 features but I want to upgrade it to the new Aurelia platform. What is the proper upgrade path and what is the simplest way to upgrade up front with as least pain as possible? Is there a doc with the upgrade path?
(Please feel free to make this a community answer by contributing)
Module Loading
Aurelia supports using AMD modules and require.js as a module loader. If you are using require.js with Durandal and want to convert your modules over to Aurelia they should be almost identical, depending on any future changes to require.js.
The lifecycle callbacks remain the same meaning that activate, attached, detached, deactivate, canActivate, canDeactivate, and any others should stay the same. They also still accept returning a promise.
If you choose not to stick with require.js, you can convert the AMD modules over from the AMD format to ES6+ format. This requires removing the first line or two and last line in the AMD module and replacing it with a class export similar to this -
define([], function (){
// stuff
]);
becomes
import {inject} from 'aurelia-framework';
#inject()
export class TheClassName{
// stuff
}
Where the inject piece is aurelia's DI system.
Data-binding
Aurelia provides the developer the ability to use whichever data-binding libraries you wish, including but not limited to the default aurelia-binding, handlebars, knockout, etc...
Some of these libraries may still need plugins to properly update when value changes occur, but this is a work-in-progress to find which do. If you are using Durandal 2.1 and knockout it is advised to leave the data-binding in place as-is and take a step-by-step approach to upgrading, one view model at a time. This is a work in progress and will be explained better moving forward
Aurelia data-binding tries to make use of the newest technology available but will gracefully fallback to dirty-checking. This enables the developer to build for the future but support the present.
The following article explains a possible upgrade path "Upgrading to Aurelia from Durandal.js":
https://github.com/aurelia/framework/blob/master/doc/article/drafts/durandal-to-aurelia.md
And the durandal extension "Durelia" helps with the migration:
https://github.com/josundt/Durelia
Related
Our team needs to add custom code to the ASM module in order to make SSO login possible in our project, and we realised the AsmComponentsModule doesn't export its declared components. This made it difficult for us to reuse them, since we had to create our own custom module which is a copy of AsmComponentsModule, containing components that are simply extensions of the components declared on it.
This is problematic, since we also had to duplicate HTML and SCSS files. The problem would be even bigger if this module had even more components declared on it.
Is there a better way to do this? Or we should expect a future fix containing the exports array on this module?
PR Fix: https://github.com/SAP/spartacus/pull/15282
Will be released into 4.3.1 and 3.4.7 patches.
I was trying to test Lazy-loaded CMS components on ongoing Spartacus project with version 2.1.4 and I wasn't able to properly display the components. Before I continue with further investigation, I just want to check couple of things:
is it possible to lazy-load components which we have overriden, for example BannerComponent, SearchBoxComponent...?
is it possible to apply lazy-load on custom CMS components ?
are there any limitations when this feature won't work? Maybe in combination with some other feature?
There are many OOTB Spartacus CMS components that we have overriden in our project, and I have defined lazy-load feature for couple of them like it is described here https://sap.github.io/spartacus-docs/customizing-cms-components/#lazy-loaded-cms-components-code-splitting inside modules for certain components, this is one example:
breadcrumb.module.ts example here
and after the build, chunks are there, visible from source tab also, but components aren't displayed and there are errors because of missing modules (such as CommonModule, RouterModule, basically for everything that we used in our custom implementation..) which are declared in corresponding module but for some reason aren't registered at all.
Any guesses what we should fix in order to check if this feature is working in our architecture?
I suggest to stick "CMS-driven lazy loading of feature modules" (as explained here: https://sap.github.io/spartacus-docs/lazy-loading-guide/) instead of lazy loading of separate components (using component: () => import()) as it's simpler to make it work.
The idea is to define CMS mapping inside the module, which then will be lazy loaded (with components, services, etc.) instead of lazy loading separate (and decoupled) components. Then, in the root application, we let Spartacus know, which feature module should be loaded, when we want to render specified component (example: https://sap.github.io/spartacus-docs/lazy-loading-guide/#configuration-of-lazy-loaded-modules)
Using component: () => import() will lazy load only component code (no module, unless defined in the same file), such a component will have access to global (root) services, etc. It's still useful in some cases, but a bit problematic to make it work in more than basic scenarios (but this will improve in Spartacus 3.x/4.0).
Regarding your questions:
is it possible to lazy-load components which we have overriden, for example BannerComponent, SearchBoxComponent...?
Yes. Briefly explained here: https://sap.github.io/spartacus-docs/lazy-loading-guide/#wrapping-library-code-in-a-lazy-loaded-module
is it possible to apply lazy-load on custom CMS components ?
Yes.
are there any limitations when this feature won't work? Maybe in combination with some other feature?
As explained above.
I already using the minify argument when building with dart2js.
I looked at the output and I see that the import 'dart:html causes problems in terms of the output file size (2kb .dart file becomes 182kb .js file). For example it imports SVG package though in my code I never touch any <svg> DOM Elements.
I understand that the compiler doesn't know if I'm going to use svg DOM Elements or not. And I understand that the using of var is one of the reasons of that behavior.
But if I will not use any var keywords, the compiler still doesn't have enough 'power' to strip all unused packages and functions.
Is there any directive I can use to forbid the import of certain packages. I mean built-in packages right now. I'm using IntelliJ IDEA and it doesn't allow me to change anything in the Dart default setup.
UPD: Tried to use
import 'dart:html' show querySelector, Element
to import only that method and class, but file size is still 182kb.
The only solution I see for now is to make a few stripped versions of the default 'dart:html' package. The one without WebGL, SVG and some other features.
Because maybe Dart compiler works good, but there is just some methods and classes that I don't use, but the code uses. Like.. the initial package methods checking if some elements are SVG or something like that.
There is a tool for analyzing the output of a dart2js build, especially for references and dependencies. Just tested and gave a better overview in my case.
https://github.com/dart-lang/dump-info-visualizer
hosted :
https://dart-lang.github.io/dump-info-visualizer/
Build with option --dump-info
https://webdev.dartlang.org/tools/dart2js#options
Even when you don't import anything you will get some minimal output size. Dart provides a lot of features like classes with inheritance and mixins (and a lot more) and dart2js output contains code that implements these features.
This is like adding a JS library like jQuery.
Therefore main() {} will already result in an output size of several dozen kb. Adding another line of code probably will only add a few additional bytes.
pub build by default does tree-shaking and minifications, therefore no additional options are required.
I'm trying to understand what is safe vs. not safe with respect to the Eclipse plugin lifecycle.
Background
Something in the Eclipse/RCP/OSGI framework allows for circular dependencies between bundles by allowing bundles to provide extension points. If bundle X provides an extension point, Bundle Y may both depend on bundle X, and provide an extension that implements an interface or extends a class known to X, and make that extension available to bundle X.
Then there's the promise of activators: as far as I understand, it is promised that your activator's start(BundleContext) method will be called before any class in your bundle is made available to any other bundle, and that your dependencies' start(...) methods will have been called before yours.
Limitations/Possible Contradictions
Now, I'm ready to describe my conundrum: I would like to retrieve all the providers of a specific extension point as soon as possible; the easy way to do this would appear to be in the activator of my bundle.
However, if what I've described about the promises that the Eclipse/RCP/OSGI framework makes is true, then I'm pretty sure it shouldn't be possible for me to do that during activation:
Either (1) I'll have a reference to classes provided by one of my dependencies before their start(...) method has been called, or (2) My dependency's start(...) method will have to be called before mine, or (3) No violations will occur, but I'll retrieve zero extensions because the plugins that depend on me couldn't be started before me, so their implementations of my extension point are not yet available.
Why I Need Extensions at Startup
My challenge is that I need to load some data ASAP after the startup of my plugin, but I need to ensure that my extensions are loaded first, because the extensions in question are extensions to the data format of the data that I need to load; if I load the data first, it fails or becomes corrupted.
I'm also wondering whether my picture of the Eclipse plugin lifecycle is correct, because, despite searching for discussions of the plugin lifecycle, I haven't come across any warnings about its limitations; I'm fairly certain it must be possible to do things wrong and create serious problems, and I'd like to understand under what circumstances things would go wrong so I can avoid creating problems.
The extension point registry accessed by the IExtensionRegistry interface will tell you about extension points without starting any of the plugins involved.
IExtensionRegistry extReg = Platform.getExtensionRegistry();
In the registry for an extension point you will have a number of IConfigurationElement entries describing the individual extensions declared by plugins. It is only when you call the createExecutableExtension method of this interface that the the contributing plugin is started.
Note: A plugin's activator start method is not normally run until Eclipse needs to run some other code in the plugin - it does not run at Eclipse startup unless you force it too.
is anyone ever tried implementing the dojo toolkit AMD with laravel 4, or could anyone please point me to a simple sample.
just a simple AMD implemetation on laravel?
What asset manager or the default is ok. how to use it with dojo?
Please help. thanks
For 1. I suggest you may try this Laravel 4 bootstrap suite it gives you RequireJS implementation out of the box.
For 2. You can use dojo with any asset manager you want, or even without it (although it is not a good way) - just by putting its .js files in your /public directory and including them as you do in usual html from inside your view templates. If you are using Blade templates make sure the template syntax is not colliding with your js syntax. If it is, then use #include of .php file with your js code section in your .blade.php view template.
Asset manager gives you a more elegant and correct way of doing the same thing. It maybe extremely useful if you are dealing with LESS or Coffee things to be compiled into regular JS and styles.
If you want advanced asset manager I would suggest your to look at /CodeSleeve/asset-pipeline on github - it's one of many asset managers for Laravel, but one the few keeping alive (take a look at basset or laravel-grunt options on github for instance).
Asset Pipeline makes a good job making asset management similar to the one in Rails. Here is an article on how and why to use it: http://culttt.com/2013/11/04/add-asset-pipeline-laravel-4/