Upgrade to Angular 2 and Magento 2

[ghost]

It would be nice to have the middle ware upgraded to support magento 2. Also would be extra nice to support angular 2 for SEO purposes... I am going to fork it and start this project.

[zontafil]

I would suggest to use prerender or phantomjs for SEO for the moment.

Angular2 is quite new, and few people are gonna use it in the following months imho

[ghost]

Yah converting it to angular 2 is the only way I would be able use this project at work. I would get push back for SEO. The pre-render phantom js method doesn't work on all engines and isn't perfect. Angular 2 is the first solution out there to fix this problem with pre-rendering server side. SEO is very important to my company and probably most other e-commerce sites out there.

[creaux]

Very nice idea I have some small experience and I have to say to write it directly on angular 2 is not good idea because as you find there is missing a lot of libraries which are available for angular 1. But there is a library which suppose you to write ng1 code in way of ng2. When you traversing to angular 2 it is simply possible. On Fri, 15 Jan 2016 at 00:10, Josh Spivey notifications@github.com wrote:

Yah converting it to angular 2 is the only way I would be able use this project at work. I would get push back for SEO. The pre-render phantom js method doesn't work on all engines and isn't perfect. Angular 2 is the first solution out there to fix this problem with pre-rendering server side. SEO is very important to my company and probably most other e-commerce sites out there.

— Reply to this email directly or view it on GitHub https://github.com/Wildhoney/Magento-on-Angular/issues/110#issuecomment-171823698 .

[Wildhoney]

I'd be happy to help in moving this from Angular to Angular2 :+1:

[ghost]

Angular 2 can run angular 1 code... that is a non issue like I said the real issue is seo.

[creaux]

Angular 2 definitely can't run Angular 1 code it's totally different architecture. Which is not compatible at all. On Fri, 15 Jan 2016 at 09:00, Josh Spivey notifications@github.com wrote:

Angular 2 can run angular 1 code... that is a non issue like I said the real issue is seo.

— Reply to this email directly or view it on GitHub https://github.com/Wildhoney/Magento-on-Angular/issues/110#issuecomment-171905880 .

[ghost]

@creaux I guess you havent read the migration guide yet http://angularjs.blogspot.com/2015/08/angular-1-and-angular-2-coexistence.html

"Good news! We're enabling mixing of Angular 1 and Angular 2 in the same application. You can mix Angular 1 and Angular 2 components in the same view. Angular 1 and Angular 2 can inject services across frameworks. Data binding works across frameworks."

There is a backwards compatibility lib you import in and you have to do small modifications to get the code to run.

[creaux]

A read that but reality is different. As I mention it mainly depends on libraries which are you using. Most of them basically not exists. That's the reason why you can't easily traverse. I think to try this is some kind of way https://github.com/ngUpgraders/ng-forward because it will suppose you to find what is missing and rewrite if that is necesary. On Fri, 15 Jan 2016 at 17:26, Josh Spivey notifications@github.com wrote:

@creaux https://github.com/creaux I guess you havent read the migration guide yet http://angularjs.blogspot.com/2015/08/angular-1-and-angular-2-coexistence.html

"We're making it easy for you to take advantage of these benefits in your existing Angular 1 applications by letting you seamlessly mix in components and services from Angular 2 into a single app"

There is a backwards compatibility lib you import in and you have to do small modifications to get the code to run.

— Reply to this email directly or view it on GitHub https://github.com/Wildhoney/Magento-on-Angular/issues/110#issuecomment-172024731 .

[ghost]

Check this... https://docs.google.com/document/d/1xvBZoFuNq9hsgRhPPZOJC-Z48AHEbIBPlOCBTSD8m0Y/edit and http://blog.thoughtram.io/angular/2015/10/24/upgrading-apps-to-angular-2-using-ngupgrade.html

It might be best to start off with a angular 2 yeoman generator and just follow that guide on the second link. Any ideas on a good boilerplate?

here are a few to checkout. https://github.com/abner/generator-angular2-beta-gulp-webpack#readme https://github.com/curiosityinc/generator-angular-next#readme https://github.com/joshuacaron/generator-angular2-gulp-webpack#readme

[creaux]

And what about then update of API from laravel to Magento 2. As i found Magento 2 should support directly RESTAPI but structure of json will be different.

On 15 Jan 2016, at 17:59, Josh Spivey notifications@github.com wrote:

Check this... https://docs.google.com/document/d/1xvBZoFuNq9hsgRhPPZOJC-Z48AHEbIBPlOCBTSD8m0Y/edit and http://blog.thoughtram.io/angular/2015/10/24/upgrading-apps-to-angular-2-using-ngupgrade.html

It might be best to start off with a angular 2 yeoman generator and just follow that guide on the second link. Any ideas on a good boilerplate?

here are a few to checkout. https://github.com/abner/generator-angular2-beta-gulp-webpack#readme https://github.com/curiosityinc/generator-angular-next#readme https://github.com/joshuacaron/generator-angular2-gulp-webpack#readme

— Reply to this email directly or view it on GitHub.

[ghost]

@creaux Im stuck on magento 1.9.0 for a bit. I dont like the idea of moving from laraval tho. The middleware approach seems allot better. Its better to have a unified interface to your app so lets say I want to drop magento and go with schema.io or something for scalability 'Because EAV sucks and cant scale' I just have to rewrite the extensions in the middleware to map the data and the endpoints. Then I dont have to worry about the rest of the carts I support. Extensions are allot easier to write then rewriting your entire cart.

[ghost]

I am not really fond of aura project for some architecture reasons but it has a good example at a high level of using extensions to make applications framework agnostic.

http://aurajs.com/

My experience with carts tho is you usually create a middleware to make your projects e-commerce engine agnostic to your app. I have done this on some enterprise level carts like demand-ware with success before. I think its the most attractive feature of the project.

[zontafil]

The middleware approach which abstracts the ecommerce APIs is quite nice indeed (and I'm in favour if it). One, not small, problem, is that it's not easy to support everything of every ecommerce, and when you reach the point that you need that feature of magento which is impossible to abstract to a middleware, problems can arise.

A similar situation is happening often, for example, with ORMs whose puroposes are to abstract various SQL and noSQL dbs, and they end up supporting half of the feature of each.

Regarding angular2, keeping a single repo for:

• core API middleware
• core angular services
• angular UI

is complete nonsense to me. -What happens if I want to use magento API with, i.e. react.js ? -What if I want to use just magento + angular module and make the angular UI from scratch (which a lot of angular developers want to do?) Every angular lib exposes the business logic. The UI is up to the developer/designer. -What if I want to stay with angular1? (the majority of angular devs are willing to stay to angular 1 for this year, at least with serious and potentially big apps like ecommerce).

The correct approach is having a main core API repo, and splitted repos for various frontend frameworks (angular1, angular2, react, backbone etc.)

[creaux]

@m3l7 I think separated main API is logical way. As you said there is a lot of situations and reasons.

How reusable are components regarding to service layer of Angular depends on architecture. Depends how loosely coupled each component/service is. There is a way how to make Angular1/2 modular using ES6 modularization. If it is clean and well readable code you can just extend using other components.

[ghost]

@m3l7 Well I think yeoman is the solution for that you can just create different generators for different stacks... Thats the problem its made to solve. My business requirement requires angular 2 so I can work on the generator for that. Aura was architected wrong and it's only async in nature which causes tons of underlying architecture and performance issues. If you have a business requirement of reusing a ton of client side modules that are controlled through a CMS it might be a viable option. I don't think there is a clean solution to map the services to all frameworks because that layer is what usually makes them so different. I got extensive experience with backbone, angular 1 and some react. The way the events are and the models work are so different. Thats why there is projects like bangular "Backbone/Angular mixed".

@creaux So the modular part is a important discussion.

http://angular-tips.com/blog/2015/06/why-will-angular-2-rock/

So I guess this answers the module system concerns.

In Angular until recently, we always had a problem with module loaders. What should I use? Maybe the classic way of endless script tags? Require.js? Browserify / webpack?… Angular 2 uses the standard System.js which is a universal module loader that loads ES6 modules, AMD, Common JS…

https://github.com/systemjs/systemjs

[creaux]

AMD is quiet good aproach. I think the most flexible and transparent from all of them.

SystemJS is very suitable for ES6 and with jspm seems to be the most similar to true external modularization. Just now trying to transfer RJS to JSPM project. There is couple of issues with typescript will see if it is possible to resolve. If yes I'm definitely for this approach. No gulp, no grunt just start jspm server and building on the flow in browser. Production release is possible to make by one command. On Mon, 18 Jan 2016 at 17:31, Josh Spivey notifications@github.com wrote:

@m3l7 https://github.com/m3l7 Well I think yeoman is the solution for that you can just create different generators for different stacks... Thats the problem its made to solve. My business requirement requires angular 2 so I can work on the generator for that. Aura was architected wrong and it's only async in nature which causes tons of underlying architecture and performance issues. If you have a business requirement of reusing a ton of client side modules that are controlled through a CMS it might be a viable option. I don't think there is a clean solution to map the services to all frameworks because that layer is what usually makes them so different. I got extensive experience with backbone, angular 1 and some react. The way the events are and the models work are so different. Thats why there is projects like bangular "Backbone/Angular mixed".

@creaux https://github.com/creaux So the modular part is a important discussion. In angular 1 I would wrap everything in AMD. In node I use electrolyte containers because the dependency injection rocks. But from what I seen the angular 2 team uses typescript modules vs es6 modules because of browser compatibility. A couple of the angular 2 boilerplates are using common js and webpack. Im not sold on any solution right now. I wish there was electrolyte for the browser...

— Reply to this email directly or view it on GitHub https://github.com/Wildhoney/Magento-on-Angular/issues/110#issuecomment-172599740 .

[ghost]

@creaux jspm is new to me looks like a bower replacement that works with system.js? If you dont use gulp or grunt how will you take care of image optimization and sass compiling?

[creaux]

JSPM is different, it suppose you to use JSPM repository, NPM and bower as well, and what is the biggest positive you can use any host git repository by aliasing host url. And then you work with that like its registry. So it seems to be with decentralized registry. Installed packages can be imported directly to your app using es6 syntax.

Yes image optimization is deal. It can't be achieved by this as I know. I used that only by less where you can make each less file coupled to whichever module so it's forwarding loosely coupling almost out of box (less is plugin I think).

But I don't think that this is big positive because then if you want to for some reason transfer to RJS or CJS it's not supporting specific syntax of less import. (There are similar plugins but with different way of how to write import)

I think if we will use es6 there can be used each of mentioned tools. On Mon, 18 Jan 2016 at 17:48, Josh Spivey notifications@github.com wrote:

@creaux https://github.com/creaux jspm is new to me looks like a bower replacement that works with system.js? If you dont use gulp or grunt how will you take care of image optimization and sass compiling?

— Reply to this email directly or view it on GitHub https://github.com/Wildhoney/Magento-on-Angular/issues/110#issuecomment-172603942 .

[ghost]

So I played with the yeoman generators and this is the one I found that looks best.

https://github.com/x6doooo/generator-gulp-angular2#readme

Its based off the angular2 seed project that has a ton of contributors. They are currently using gulp with. var Builder = require('systemjs-builder');

https://github.com/systemjs/builder

[aonic]

Hi @joshspivey @m3l7

The middleware approach seems allot better. Its better to have a unified interface to your app so lets say I want to drop magento and go with schema.io or something for scalability 'Because EAV sucks and cant scale' I just have to rewrite the extensions in the middleware to map the data and the endpoints.

This was exactly the reason I re-architected our Laravel codebase to follow this approach, so that the entire MoA system was not tied to a specific platform (Magento) or version (Magento 1). And to give true separation of the front-end (Angular app) with the back-end (Magento).

I would be very interested in helping with adding a Magento2 middleware to the Laravel code, unfortunately for the past year or so I was not working with Magento but I am back to working with it on a frequent basis and hope to get my hands dirty with Magento2 soon.

Anyone in here have experience with Magento2?

[ghost]

@aonic Your probably going to want to start here. https://github.com/magento/code-migration

Its completely different now and even more complex and even slower by like 25%. I really wish they learned from there mistakes the first time around, about over architecting with bad design patterns. But nope! They gave you another system that doesn't scale. Why I want the middleware so I can get my organization to move from it later.

[ghost]

@m3l7 @Wildhoney @aonic @creaux So when doing middleware in the past we used xslt to transform the data. Since XML is a nightmare you can accomplish the same thing with a json data transform map.

https://www.npmjs.com/package/jsonpath-object-transform

Using this as a piece in our REST API will help add and abstract the data layer in a way so we can attach other carts easy. But I think @creaux might be on to something about using the magento 2 REST API only thing is things like login sessions ect... We can still do the middleware layer with less work possibly on magento 2 doing json transforms.

[wozniakm]

I'm working with Magento 2 trying to connect it with Angular 2 and from my perspective current API provided by Magento 2 is not good at all. It is not possible to fetch all required data at one request, for example about products or cart. To make it work as expected I have to write API extensions. The question is whether it is worth to write extensions than write complete middleware?

Magento 2 is far better than Magento 1, but as @joshspivey mentioned it is still complicated.

[razvanmitre]

Any news on this?

[refaelgold]

I follow this post as well

[ghost]

Since there are no updates or interest in this project I am closing this ticket. I moved all my sites to Mage 2 and there doesn't seem much benefit of adding an extra client side layer on top of everything. Mage 2 did a massive overhaul on client side architecture and I prefer that design vs making magento into CPA that won't roll well with updates or be SEO friendly.