Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

How can I use loopback-sdk-angular and loopback-sdk-angular-cli with angular2 support ? I already tried to fork and merge the angular2-support-branch whith each respective master branch and replace the loopback-sdk-angular and loopback-sdk-angular-cli folders where strongloop is installed globally (npm library) but I can't create my lbService.ts with lb-ng -l angular2 command ... only succeed in generating javaScript service ! Does anyone can explain the way to do it ? I actually trying to dev something with loopback + angular2.0 and I don't want to wait for the effective merging to start developping the clientside part :)

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

I use this since 15 days now, and it works fine, you just have to remove all function starting with "R."
and replace "::" by something else to avoid typescript compilation errors.
@pierreclr With this done, you can start using this now.

To generate the code without the official cli, create a node file like this one and launch it :

var generateServices = require('loopback-sdk-angular').services;
var app = require('./server/server');
var client = generateServices(app, 'lbServices', '/api', 'angular2');
require('fs').writeFileSync('lbng2.js', client, 'utf-8');

@sylvaindumont, may you give example of generated file with "R." functions? And what server-side methods produces these functinos?

Indeed, @sylvaindumont it generates me a typescript fil, merci !
However there is plenty of syntax errors, for example :

// INTERNAL. Use Company.users.createMany() instead.
public ::createMany::company::users(id: any, data: user = undefined) {
let method: string = "POST";

let url: string = this.getPath() + "/company/:id/users";
let urlParams: any = {
  id: id
};

let params: any = {};

let result = this.request(method, url, urlParams, params, data);
return result;

}

Since I am new to typeScript (but very exited to learn) could you confirm that I can use all the methods generated without to worry about syntaxes problems detected by my Webstorm ?

Thank you again !

@mnvx The "R." methods are all the functions of the relations (belgongsT...).
@pierreclr in typescript, ":" is here to define a type, so the :: in function name produce syntax errors, we have to replace them by something else (__ in my case). Then you'll have some types undefined thaat you can replace by any, and it'll work.

does anyone have idea when the existing PRs will be merged in the mainstream so the community can start to use and test this feature?

thanks.

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

Does someone of Loopback developers plan to review this pull request, give feedback and merge it?

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@mnvx I'm not a strongloop dev, but I have contributed to the angular sdk before, so while they review your code I can tell you so you can gain some time, it won't be merged unless you create unit tests also for your code.

Then, you will need to squash all of your commits into 1 single commit and use the git commit 50/72 format for it.

Cheers,
Jon

these are the tests for angular1 api -> https://github.com/strongloop/loopback-sdk-angular/blob/master/test.e2e/spec/services.spec.js

it's a 1000+ lines file that we have to port to angular2 syntax.
i've no time these days to work on it, someone can help us?

thanks.

I would love to help on this, I'm just short in time right now.. I will be following this thread so if I get some free time I will try to help on this.

Cheers,
Jon

@jonathan-casarrubias, would be great

@mnvx Thank you for your PR.
As @jonathan-casarrubias suggested, please create unit tests, squash your commits and use the git commit 50/72 format.
Thanks!

@mnvx I am open to help with this as well. Would you like me to get going on the unit tests?

@csvan I have not free time for this project at this moment and I well be wery glad for help.

@mnvx I'm sorry for the late reply. I have forked your PR and started working on the requested changes. Will hopefully have it done by the weekend. CC @phra

EDIT: Fork is here: https://github.com/csvan/loopback-sdk-angular

Using since 1 week the original PR and it's working so far pretty well, thank you @mnvx !

great!

I won't make excuses, but put bluntly I was not able to finish this in the timeframe proposed.

There is a framework ready to run Angular2 tests for the SDK in my fork. However, there are still 2 major things to be done:

1. Find a way to generate and inject the SDK script for the various test cases. Since the Angular2 SDK is written in TypeScript, this requires an intermediate compilation phase.
2. Convert the existing test cases to an equivalent Angular2 form.

Any help with the above would be appreciated.

@gvsdan If you use the RC version, the angular modules have changed. You need to update the generated file with following (basically the first 2 lines of the file):

import {Injectable, Inject, Optional} from '@angular/core';
import {Http, Headers, Request, Response} from '@angular/http';

The rest for me worked fine.

@Krisa Sorry it my mistake it's working fine <3

Hello, I am glad the solution proposed here (and in https://github.com/csvan/loopback-sdk-angular) works great for Angular2 users.

I am afraid we cannot accept a contribution without automatic test coverage, code without tests is difficult to maintain, it makes it easy to introduce unintended breaking changes and bugs.

I have two proposals for you: if there is a person willing to rewrite current test suite to use the new Angular2 template, then please do take over this patch and open a new pull request.

Alternatively, you can maintain the Angular2 template in your own repository and publish it to npmjs.org under a different name, e.g. loopback-sdk-angular2.

@bajtos are you planning to keep supporting the generator for further versions? or is the swagger option the one that will be officially supported?

I already published -loopback-sdk-builder- a version of the generator for NativeScript2 and Angular2 extending this fork, because of the hurry to implement it on projects. But if you plan to keep supporting the generator I can make tests for these 2 sdks and pull request these.

But please confirm if the generator will be supported in the long term.

In the other topic; the name of the module is loopback-sdk-angular but really the same generator can build sdk for different technologies, and right now is really easy to provide support for other frameworks like React. What are your thoughts on this topic? do you think is better for me to keep supporting the loopback-sdk-builder for different technologies as it is leading? or do you see as a possibility to officially support multiple frameworks using 1 generator with different templates?

I know these are many questions but, is not good idea to duplicate effort.

Cheers,
Jon

@jonathan-casarrubias We don't have concrete plans yet, we are still discussing what would be the best direction for us. I think that if we ever decide discontinue support for loopback-sdk-angular, then we will offer the module for the community to take up the maintenance.

In the other topic; the name of the module is loopback-sdk-angular but really the same generator can build sdk for different technologies, and right now is really easy to provide support for other frameworks like React. What are your thoughts on this topic? do you think is better for me to keep supporting the loopback-sdk-builder for different technologies as it is leading? or do you see as a possibility to officially support multiple frameworks using 1 generator with different templates?

In my experience, an important aspect when making this decision is versioning. When a single module provides multiple unrelated features (support different client frameworks), then each breaking change in one of these features (client frameworks) means a major release affecting users of all features (client frameworks), even if there is not breaking change affecting many of the users in particular. We tend to release major versions infrequently to save our users of costly upgrades. When you put these two things together, it becomes difficult to introduce breaking changes, because too many users would become affected.

The lesson we have learned over time is to follow the "many small modules" approach and I think it makes a lot of sense to apply that approach here too.

In the light of the above, I think it actually makes most sense to keep your Angular2 code generator in a different repository, e.g. the one you are maintaining right now.

Thoughts?

@bajtos I took the time to think about it and I think you are totally right.

My concern was that at this moment the JS generator is the same for all the different templates, the differences are between the actual ejs templates, so I was thinking that duplicating the same generator could be unnecessary and even wrong.

But.... While analyzing the situation I got a pull request in the module I'm maintaining that made me think that even these JS Generators will take different directions in a future not so far.

So, having the modules separated as you suggest make much more sense now than before.

If you ever plan to officially support an Angular 2 (and its flavours) we may jump in to the conversation to avoid duplicating efforts.

In the meanwhile for all the people - @mnvx, @sylvaindumont, @phra - that worked in the Angular 2 Generator before me and @JonnyBGod, please share your name, email and website to jcasarrubias@mean.expert so I can add you as collaborators. Also the loopback-sdk-builder is moving really fast, so many changes have been made since you worked on it and you may be interested either to implement or to keep collaborating.

Cheers!
Jon

My concern was that at this moment the JS generator is the same for all the different templates, the differences are between the actual ejs templates, so I was thinking that duplicating the same generator could be unnecessary and even wrong.

If there is code that should be shared between different JS generators, then we can put that code either into strong-remoting, loopback and/or in a new shared dependency. I have already improved strong-remoting's API to make it easier for code generators to introspect the REST API, we can improve those APIs as needed.

So, having the modules separated as you suggest make much more sense now than before.

Cool, I am glad my proposal makes sense to you too.

I am going to close this pull request then.