I have written an application using AngularJS 1.0.7. I would like to migrate to AngularJS 1.2. What is the migration path (what issues might I need to fix when migrating)?
The angular team has put together a very comprehensive 1.x to 2.0 migration guide here: http://docs.angularjs.org/guide/migration
Exceptions logged in the console have also been greatly improved. They now include a link to an error reference manual with a detailed explanation of the exception and how to correct it. You can find the error manual here: http://docs.angularjs.org/error
There is no official guide to migrate from 1.0.7 to 1.2 but the best thing I can find is the changelog through angularJS's versions: https://github.com/angular/angular.js/blob/master/CHANGELOG.md .
They notice the crucial changes that can break in the new version so you can look into that.
The biggest change you probably need to deal with is on routing: there is now a separate module to handle routing, just as angular-resource was already separate. You'll need to load the separate angular-route.js file and declare ngRoute as a dependency when you create your app. Until you do that, your app will likely be broken. But that was the only major obstacle I faced. (I've heard we should expect this trend to continue, as they break Angular down into smaller, more modular chunks, so people can take what they need, and skip what they don't.)
Beyond that, there are wholesale new features like the Animations module, a bunch of new directives, and some nice new docs. But I'm not yet aware of anything else you'll need to 'migrate', unless you had already implemented some of the new features on the 1.1.x branch. (FWIW, I've collected some additional detail on this stuff on my blog.)
Related
First, I do not have much background in JS; Aurelia JS is not working for me, I get the following error in Chrome:
1) TypeError: e.configure is not a function
at aurelia-core.min.js:1
If I use the Aurelia basic-aurelia-project.zip
2) I get Uncaught (in promise) Error: Cannot set SystemJS.map["aurelia-framework"] directly. Use SystemJS.config({ map: { "aurelia-framework": ... } }) rather.
If I maken eclipse project and use the below in index.html
<script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/0.20.9/system.js"></script>
<script src="lib/aurelia-core.min.js"></script>
<script>
System.import('aurelia-bootstrapper');
</script>
If I have to follow simple dependency inclusion model with 'script' elements in head/body what are the scripts to be included.
In addition, I did not find any CDN link for Aurelia, which makes me wonder if Aurelia is production ready or a mere Beta level upcoming JS framework.
I do not use Node.js etc. so npm etc. does not work for me. Is there a simpler way of using Aurelia (in AngularJS 1.x style including script elements) or there is some other more complicated way.
I am not sure if Aurelia is worth the effort to adopt in terms of configuration/dependency (my opinion only).
If someone can help me resolve the above problems & dependencies it shall be great.
I'll answer this question based on my opinon.
In addition, I did not find any CDN link for Aurelia, which makes me
wonder if Aurelia is production ready or a mere Beta level upcoming JS
framework.
You may not find any CDN link for Aurelia because it's not like other libraries, such as jQuery. There's no reason for a CDN link because you would never load it using script tags in a production environment (unless if you really know what you're doing). Aurelia (as any other modern js framework) was made to be used with modern loading and bundling tools.
I do not use Node.js etc. so npm etc. does not work for me. Is there a
simpler way of using Aurelia (in AngularJS 1.x style including script
elements) or there is some other more complicated way.
I'm sorry to tell you this, but if you want to use a modern JS framework (Aurelia, Angular2, Vue.js), you will have to deal with node.js, npm, etc. All modern js frameworks have some building process that run under a node.js environment. It's possible to avoid it, but this would only make things harder.
There are simpler ways to use Aurelia, like the project you've mentioned in your question. However, It was mainly made for learning purposes. You can still use them in a real scenario but you will find a lot of difficulties since there will be no tool to help you.
NodeJS tools are there to help us! Give them a chance and you won't regret it. Trust me :)
If you have some strict companies rules that don't allow you to use Node, I think you should to talk to your leaders and try to workaround that.
#Fabio Luz,
please excuse me, this is not an answer, but a longer note to your answer - there might be a scenario for Aurelia modules in CDN...
I understand, that it is very good to have ability to bundle and do the tree shaking of the framework library for the "lonely" SPA architecture. But I am not sure and I wonder whether it would be better to have some different approach - e.g. having the certain Aurelia modules in a CDN. I wonder that in case of a possible decision e.g. to use Aurelia commonly as a platform for continuous development of customization for SharePoint Online /Office365 using the SharePoint Framework. I have tried to configure Aurelia as externals for the webpack in a spfx solution, but I was unsuccessful. I am also not so familiar with all the tooling, so I might have done some beginner's mistake :(. Pity, that the Aurelia cli and the spfx tooling versions are not in a harmony currently - the spfx has to use the gulp with webpack ver.3, though the aurelia works with newer webpack ver.4
I am trying to do some analysis on Angular 2 and React. One of the things I'm interested in is the size of the core libraries. In others, the minimum needed to get a "hello world" app to run in both.
From my understanding, React just requires the react.min.js file (https://cdnjs.cloudflare.com/ajax/libs/react/15.3.1/react.min.js).
For Angular though, I'm confused. I look at the quick start on Plunkr, and I see four JavaScript files loaded. From my understanding, is optional, but recommended. But then I see zone.js, system.js and systemjs.config.web.js. Are all of these necessary? I just want the bare minimum.
Thank you
How to organize Vue-JS project [files and directory]: Non Javascript way?
Coming from a non-javascript background, I found Vue.js very intuitive and easy to use. My earlier experience in Javascript is with JQuery and vanilla javascript on the browser.
I created an application using Vue , Vue-components and vue router. Everything works fine.
My problem is, I have ended up writing a lot of code in a single index.html file of my project. This file contains over 10 templates that I have created and attached to different component in my app. I want to know that is there a non-javascript way to organize these templates in seperate files.
I see that there are options using webpack and browserify to modularize the project. But coming from non javascript background, I don't find them intuitive. I don't want to go node - npm way because that has its own learning curve and moreover it downloads a dozen of files and dependencies in my project which I don't understand. I am old school and more comfortable downloading the files and including them in the webpages.
So probably, you understand where I am going to. I need a solution where I could put my templates as separate files and read those files in the different components.
What I have tried :
Declaring the templates inside my components. But writing all that html inside the component is not that clean. It also, makes my JS file too huge. I am better in putting all data in the index.html instead.
Storing template as smaller chunk "homepage.html","about.html" and in my components, using $.get / $.load to read different components in ready function of the component. This works but I still have to fire an additional ajax call for each component which is not efficient.
Please refrain from suggesting the obvious node-npm [webpack and browserify] way. I know thats what is supported by Vue but this needs a learning curve and complete setup. Answer to this question would actually help other developers who hesitate going the node-npm way.
Please shout back if you need more clarifications to the question.
The options you've mentioned are your only real ones... the HTML of the template needs to be available when it's needed, so you either have to have it within your html file off the bat, or load it using AJAX or an in-browser loader like RequireJS (and this extension that allows it to load HTML https://github.com/requirejs/text).
In-file templates make sense for very small projects. As your project grows, you'll need to start using the tools that are built for this. NPM rocks and every JS package that you'll ever need can be included in your project in seconds.
I highly encourage you to try the Vue CLI
It does use node, npm, webpack and downloads dozens of files. Which you've you've explicitly asked for not to use, so let me clarify:
The Vue CLI takes care of the complexity and configures webpack for you.
You don't even have to know it's using webpack.
It's very developer friendly (it even has a built-in gui) and lowers the barrier to entry compared configuring a webpack config.
I hope you'll also find it "intuitive and easy to use".
I have two different ember applications, but a specific subsection of both will be absolutely identical. I would much prefer, moving forward, to edit a single source of truth for this functionality, and then plug it into both applications whenever it is changed.
What would be a way to accomplish this?
I would assume there is a way to simply plug in the components themselves or, barring that, building another ember app and embedding it in the larger app. Either solution, or another solution, would be acceptable.
Your question is about building and distributing applications, rather than about Ember per se. I would first define the shared code in a namespace: (http://emberjs.com/api/classes/Ember.Namespace.html) and then wrap that up as a node.js module, with a package.json file that describes the module.
Then, I would use bower to install the package by specifying the module in the bower.json dependency section. (http://bower.io/)
This approach gives you more control over your development of all three products- two applications and a shared framework. It then allows you to version your shared code so you don't have to upgrade both applications at the same time- Quite a few problems solved by leveraging the package management features of bower.
One way to achieve this, which actually has much less to do with ember itself, is to have a common place to retrieve files for you applications. Such as a CDN url that you can hit for common libraries, images, global files etc. It seems as thought you may be trying to have the same file locally in two places, and have both update whenever you make changes to one common place. This could also be achieved by simply having a symlink to that file in each project.
Either way, your solution will probably be a server action than it will be an actually Ember issue.
Hope this helps.
I've been getting into Backbone.js lately and I'm enjoying it so far. All the examples tend to be simple to-do lists, so it's been a little difficult extrapolating code organization and file structure for a larger/more robust single page application.
I've come to a crossroad:
Should I use something like Yepnope.js to load models and views as I need them or,
Combine and minify into fewer files and front-load it all.
Some combination of both?
Any advice would be appreciated!
It depends of the size of your app. If you have a bunch of different views its definitely worth to start with a loader, where you can start the app with minimal feature set and load other views when needed. I can't tell anything about yepnope, but it seems the focus is more about polyfills then to structure your app with modules. We use requirejs for our app, and it works really well. You have to write a bunch of boilerplate code for the AMD modules but its really worth it.