I'm looking at the Nativescript 4.0 changes listed in here and it says that application.start() is being deprecated for application.run(). I've downloaded the nativescript-template-ng-tutorial and am looking at all the files but I don't see where application.start() is being called.
Where is this being called?
It's called in nativescript-angular
likely related: https://github.com/NativeScript/nativescript-angular/issues/1274
Related
I'm using Globalize.js script in my app to work with locales. All works well, except currency formating. When I use Globalize.currencyFormatter(currency), I'm getting this error
TypeError: cldr.once is not a function
I don't know where should I get "once" function. I've searched in cldr library (latest version 5.0) and don't see once function. Where it suppose to get from?
cldr.once is part of a supplemental library cldr/event.js found in the dist folder of cldr repository
Globalize.js has a dependency to the CLDR low level manipulation tool cldr.js. once is its method for adding event listeners. Make sure you have loaded cldr.js on the page or included it as part of your build.
I have an existing ExtJS application I'm upgrading from 4.x to 6.2.0. I had a simple storage provider setter that I pass into my Ext.onReady() block that looks like the following:
Ext.state.Manager.setProvider(Ext.create('Ext.state.LocalStorageProvider',{}));
When I swapped to 6.2.0, I'd get the error:
ext-all-rtl-debug.js:9389 [E] Ext.util.LocalStorage.constructor(): Cannot create duplicate instance of local store "ext". Use Ext.util.LocalStorage.get() to share instances.
So what I had to do to, what I think is a fix, was the following:
Ext.state.Manager.setProvider(Ext.util.LocalStorage.get('id'));
My concern here though is that I'm just applying a bandaid to the problem and not really going through with a real fix. I don't explicitly set the provider anywhere else, all I did was swap out the ExtJS lib from 4.x to 6.2.0 to get that error. It's as-if it's being created somewhere else first in the 6.2.0 initialization process and now I'm getting a duplicate error as aforementioned.
What has changed in 6.2.0 to cause this behavior? Is there now two providers set, one by ExtJS and one with my client code? Is there a cleaner way of handling this?
The preconditions for this error are the same in both, ExtJS 4 and ExtJS 6. The corresponding file does not have changed: compare ExtJS 4.2.4 version and ExtJS 6.2.0 version.
Because of this your application must be responsible for this. Somewhere in your (upgraded) code an instance of Ext.util.LocalStorage must be created. Since this error is thrown in case the ID is already registered and the registration is done only in the constructor of the Ext.util.LocalStorage class, I'd suggest to set a breakpoint right there to check in the stacktrace which function does call the constructor method.
I'm trying to get loadIntoLocation working, but I keep get the error message,
Property 'loadIntoLocation' does not exist on type 'DynamicComponentLoader'.
I've looked at other examples and used plunker and it works there, but I can't seem to get it working locally. I grep'd the Angular2 core and could not find any mention of a loadIntoLocation function.
How do I find out what version of angular2 I'm using? Can I upgrade? I just used npm install to deploy my environment.
That was removed a while ago as far as I remember. DynamicComponentLoader is deprecated anyway. Use ViewContainerRef.createComponent() instead.
For a full example see Angular 2 dynamic tabs with user-click chosen components
I use SignalR 2.2.0 in a MVC5 project. SignalR depends of JQuery in client-side.
JQuery recently released new version, I updated it from Nuget, specifically from version 2.2.4 to 3.0.0.1, but then SignalR stopped working. Startup command "$.connection.hub" in javascript fails.
After a long time head scratching, I downgrade JQuery to 2.2.4 and everything is fine again.
Am I the only one getting this problem? There is any workaround?
Thanks.
You must edit the signalR code by yourself, In jquery 3 they removed the shortcut for load event :
Breaking change: .load(), .unload(), and .error() removed
These methods are shortcuts for event operations, but had several API
limitations. The event .load() method conflicted with the ajax .load()
method. The .error() method could not be used with window.onerror
because of the way the DOM method is defined. If you need to attach
events by these names, use the .on() method, e.g. change
$("img").load(fn) to $(img).on("load", fn).
https://jquery.com/upgrade-guide/3.0/
so in the file jquery.signalR-{version}.js :
you must update this line :
_pageWindow.load(function () { _pageLoaded = true; });
To :
_pageWindow.on("load",function () { _pageLoaded = true; });
Finally version 2.2.1 of SignalR was released, solving this problem. Thanks for all comments.
If you're still getting errors like this after updating to 2.2.1 and jQuery 3.x then read on...
TypeError: Cannot read property 'client' of undefined
Like I am you are probably using the dynamically generated proxy, and you checked your /signalr/hubs file and found you don't have any proxies defined.
var proxies = {};
Wait you may ask I didn't change anything - where did they go?
Well, like me you probably were in such a hurry to upgrade signalR to 2.2.1 that you forgot to do it in all your projects and now you are using both 2.2.1 and 2.2.0 in different assemblies. (I am defining my hubs in a different assembly than my main app).
All I needed to do was make sure I had the latest nuget package version in every project and it all worked. Should work fine after rebuilding. If not, this may also help.
Also do yourself a favor and read the jQuery 3 upgrade guide if you use much jQuery elsewhere.
I'm loading yui.js 3.3.0 version file from portlet but liferay its using 3.2.0 yui.js file,
so whenever i'm loading that page js errors are coming like
G_ENV._loaded[VERSION] is undefined - this error is coming in yui.js which is liferay using that is 3.2.0 version.
so its replacing value like G_ENV._loaded[3.2.0] and that will throw an error becoz we loaded 3.3.0 version from portlet.
I replaced yui.js 3.2.0 version file in portlet but It was throwing some other js errors.
How will it work same in 3.2.0 or Is there any way to update existing version of yui?
This is the code of yui.js in this line its throwing error
if (!G_ENV._loaded[VERSION][name]) {
missing.push(name);
} else {
used[name] = true; // probably css
}
Any help would be appricated, anyone has faced this kind of problem.
Thanks
Upgrading, changing, or overwriting the native YUI installation in Liferay is extremely difficult, because of two reasons. One, Liferay 6.0's UI framework (Alloy) runs on YUI 3.2.0. Two, the native portal template instantiates alloy ui onto the global YUI object (YUI.AUI), which is awful, as it makes the YUI framework tightly coupled to the horrifically implemented AUI. Your browser calls this AUI reference, on the YUI object, as the page is loading and after the window.onload event. If you try to replace or modify the global YUI object, it screws up Alloy, which Liferay's UI runs on.
Since upgrading is out of the question, the next best alternative is to bring in just the new YUI modules you want to use. Also, you could try out Liferay 6.1 CE, which has 3.4.1 built in, but it looks like its still in beta testing.
Here's an example of bringing in and using the dom-core module from YUI 3.4.1 and using it in Liferay 6, which runs on YUI 3.2.0. I got the idea from YUI's docs on how to bring YUI 2 modules into 3 (http://yuilibrary.com/yui/docs/yui/yui-loader-ext.html). To quickly figure out dependencies each module has, you can use YUI's online configurator http://yuilibrary.com/yui/configurator/.
var config = {
ignore : ["skin-sam-overlay","skin-sam-widget","skin-sam-widget-stack","skin-sam-tabview"],
groups: {
yui341: {
base: '/js/yui-3.4.1/build/',
modules: {
yui341_yui_base: {
path: 'yui-base/yui-base.js'
},
yui341_oop: {
path: 'oop/oop.js',
requires: ['yui341_yui_base']
},
yui341_features: {
path: 'features/features.js',
requires: ['yui341_yui_base']
},
yui341_dom_core: {
path: 'dom-core/dom-core.js',
requires: ['yui341_yui_base','yui341_oop','yui341_features']
}
}
}
}
};
YUI(config).use('yui341_dom_core',function(Y){
//YUI 3.4.1 config modules are now accessable through 'use' call
console.log(Y.version); //say hello to the newer version (3.4.1)
Y.use('dom-core',function(Y){
//Finally have access to native 3.4.1 module
console.log(Y.DOM);
});
});
Actually, the problem isn't because of Alloy being shoved onto the YUI object. That would be fairly trivial to work around by just simply doing:
YUI.AUI = AUI after loading the new YUI.
The problem is because of everywhere Alloy (and even YUI modules already loaded on the page) references YUI, it expects it to be a specific version of YUI.
In many cases, this isn't that big of a deal, as the API between YUI releases isn't that far off. However, between 3.2 and 3.3 there were some changes in Widget, as well as other general changes that could cause problems.
The issue is that YUI currently doesn't have an acceptable way to load multiple versions of the library onto the page that won't cause some sort of conflict.
(Because the YUI global get's overwritten, as well as it's properties, such as YUI.Env).
However, I have been kicking around an idea for one possible way to handle this, using dynamically generated iframes to load a separate YUI instance in a different window and pass it along to the original page).
If I can get that working, it's something that we will be backporting to all versions of Alloy, so that Liferay users can leverage it as well.
Josh, if you have any thoughts on a better way to handle this, I'd definitely be all ears.
Thanks,