Design goals

[jokade]

I'd like to start a discussion on some basic design goals / rules for this binding, e.g.

• coding experience / API style: I'd prefer to keep the binding as close as possible to the Typescript API of Angular2, and only deviate where necessary (e.g. due to restrictions imposed by macros,etc). One example for such a deviation is the @@[T] operator. In addtion to this basic Typescript-compatible API we could provide enhancements that utilize advanced Scala features (e.g. an efficient DSL for routing, etc)
• packaging/naming: should we place bindings / façade traits under the angular namespace (instead of angulate2)? Should we include all Angular2 modules in a single angulate2 lib? Or should we provide separate libs for the core and optional addons?
• release strategy and version numbering: should we mirror the Angular2 release cycle / version numbers to some extent in the angulate2 version number?

[gregghz]

Here are my thoughts:

• coding experience / API style: 100% agree. I think with Scala's robust macro system and type level programming possibilities it will be worthwhile to expand on that core API where it makes sense to simplify boilerplate and expand features. More immediately, the core API should probably be fleshed out first.
• packaging/naming: I don't have a strong opinion here except that there's currently a bug with using @@[ROUTER_PROVIDERS]. This gets expanded into js.Array(angulate2.router.ROUTER_PROVIDERS) and if you're not using the sjsx loader (I couldn't get it to work with the latest version of angular2) there is no clean/easy way to have that defined and in scope. Changing these paths to more closely match angular2 (I think that would actually mean ng instead of angular) would fix this bug. I don't actually think this is how that should be fixed, but it's the most significant impact naming will have on the project currently. Besides that, I suppose you could argue that imports are part of the API and if you want to match the TypeScript API it might be worthwhile to follow their naming/grouping conventions.
• release strategy and version numbering: Again, no strong opinions here. I think it should be very clear which version of angular should be used along side any given version of angulate2. Whether that means matching major version numbers or not, I'm not sure. It might also be worthwhile to not worry about this too much until a stable release of angular lands (who knows when that will be) because the API seems to be in major flux and I'd like to see angulate2 keep pretty close to up to date. It'll be easier to track API changes once a stable API is defined.

[gregghz]

Somewhat related: have you considered creating a gitter for this project? I suspect it wouldn't be wildly popular, but I'd be around and we'd be able to have more organic conversations about more specific things when needed. https://gitter.im/scala-js/scala-js is already pretty popular and many other scala projects have gitters used for design discussion, planning, release notifications, and general help/troubleshooting.

[AugustNagro]

I've been learning the new macros as a pet project, and decided to make some angular 2 bindings.

There are benefits and drawbacks to using scalameta/paradise in place of scalamacros/paradise. The new system is very experimental, but allows a huge reduction in boilerplate. The core logic for the annotations is in a single file, and much easier to read/understand.

I also made some changes to the scalajs-reflect library, which lets us remove the annotations file. This change is independent of the macros library, so it could be copied to this project.

I added you guys as contributors, in case you were interested :)

[jokade]

@AugustNagro I finally had time to look at your code - great work 👍 your project should probably supersede this project eventually. However, I've finally started to port angulate2 to the new SJS module support, and I think I will finish this port before dropping the additional annotations.js (or deprecating this repo completly :)

[AugustNagro]

Thanks. I doubt scalameta will stabilize for some time.

Bundling/lazy loading might be possible with the new module support. But sadly I don't think AOT compilation for js/scalajs will ever be possible, as ngc is a fork of the typescript compiler.