Design Doc about ng-forward HOT 17 CLOSED

so, next steps? Seems like the design doc has some pretty solid data. Maybe it would be helpful for someone to go through and describe the design goals more linearly, suggested interfaces, etc? (admittedly the ideal interface is “like Angular2”… but obviously there will be gaps) Also, do we want to start talking about whose library we’re starting with?

from ng-forward.

I think it sounds good to build a spec doc from the design doc. Something that spells out the apis and interfaces that we want and maybe also specifies what we don't want as well.

I also have a feeling there needs to be a bit more discussion around polyfilling and how far we want to go. I'd like to polyfill angular 2 as much as possible, however I get a sense that @mitranim feels differently about polyfilling. I've heard him state before that he prefers to just provide good decorators for angular 1.

I kind of feel like the "good decorators for angular 1" solution already exists in all of the existing libraries. I feel like the library that is missing is the true ng2 polyfill. @mitranim, what are your thoughts on this? So this would mean that we'd try to match the ng2 api as closely as possible.

from ng-forward.

Well, with ng-decorate the goal was painless dependency injection and easier declaration of components and factories. Imitating the ng2 API would complicate the internals and erect a learning barrier for people who don't know it or don't care about it.

However, it's not a complete solution. For example, I tend to write additional directives that imitate other parts of ng2, like DOM eventing, with an API matching that of Angular 2. I guess the takeaway is that to create an environment where you can use ng2 patterns, it does make sense to try and polyfill as much of ng2 as possible, at least where it makes sense.

from ng-forward.

Ok this is great feedback.

from ng-forward.

Probably best to go ahead and setup another meeting where we can go over the design doc and discuss which library to use.

from ng-forward.

Yeah another meeting would be good, though @pbastowski will not be able to make it unless we wait for him.

It seems like ng-decorators would be a good starting point. It has the nice writers usage which allows easy class annotation and cross-decorator annotations (e.g. Component working with View) as well as extendibility (e.g. State). It's also using ES6 (which is a minimum requirement in my mind). I'd even be down to use TypeScript, like ng-decorate does, but I'm fine with just ES6.

I wouldn't mind hearing others opinions on where they'd be like to start from before we have another meeting.

from ng-forward.

@timkindberg Ng-decorate because Component and View work together? All our libs do that. ES6 code base is OK, but I don't feel it is mandatory, for simplicities sake. After all, the decorators are just functions that return functions.

Extendability through plugins would be cool. In fact all our decorators can be plugins. Now, that's nice. But, I think, the core should be kept to ng2 emulation and all other stuff, for example State, MeteorMethod and RestCall should be optional addons. Although I find State is almost essential for the development of web apps. Hmmmm...

One way binding, as implemented in ng-decorate, is a facade, as it uses two way binding binding using "scope:{}" behind the scenes. So, no speed advantage there, but a new syntax has to be used that does not exist in ng2.

Other that that, I haven't coded with it, but I have with mine, so can't talk about ease of use of Ng-decorate. Have you written code with it personally?

I'm not criticizing, just can't say I think it's a better base to start with without first working with it for a while.

I'm for keeping thing as simple as possible.

Sent from my iPhone from while on vacation.

from ng-forward.

Ng-decorators. Not Ng-decorate. I know the names are so similar :/

You're right all libs can have component and view work together. I meant I like the Writer in that library. It seems nice to use for annotations dev.

I just really like ES6 :) but you are right it's not necessary.

from ng-forward.

The facade for one way binding in Ng-decorate is probably fine. I've not used it. I just know I could really use it for a better data flow in my current project using a1atscript.

from ng-forward.

I should clarify that I like the Writer if we determine it to be necessary to write the annotation data first and do the work later all during the call to bootstrap. We'd briefly talked about this in the meeting.

from ng-forward.

Aha, I see. Your are talking about some form of delayed instantiation. I have only found a use for it in my delayed instantiation of the component/directive controller to get at other component's controllers. If there are other scenarios then let's hear them.

from ng-forward.

It isn't so much about delaying controller instantiation, @timkindberg is talking about delaying when metadata is read from a class and turned into some Angular provider.

In angular-decorators, the only thing the decorators do at the moment is attach metadata using a structured tree through writer objects. Then after all of the decorators have been applied the metadata is read off of the class and turned into a provider. The mechanism for reading the metadata occurs when you add the class to the angular-decorators Module wrapper, however the plan is to change this such that you could call some bootstrap function on a component and that would trigger the parsing.

I also agree with @pbastowski: if we do provide a bootstrap function, we need to support some kind of routable component. It helps form the component graph that the bootstrapping function would need to traverse.

I have an experiments branch with spikes for dynamic events, bundling the module from a component tree, and a bootstrap function: https://github.com/MikeRyan52/angular-decorators/tree/experiments

If we go with angular-decorators, in the fork I recommend removing almost all of the decorators leaving the core (writers, module, parts of the component parser) in place. That way we can rethink the API for each decorator.

from ng-forward.

I'd say if @pbastowski, @hannahhoward and @mitranim think ng-decorators would be a good place to start then I'm on board too.

from ng-forward.

Hey @MikeRyan52 I really like what you are doing on that experiments branch. I think that is definitely the right direction.

from ng-forward.

I don't have a preference what to start with.

from ng-forward.

Hey everyone, just want to throw in my two cents that I would vote for starting with ng-decorators as well. I like it's architecture. To effectively build our final library, we are going to need some abstraction. ng-decorators has this while at the same time not being quite as overwhelmingly abstract as a1atscript.

I also want to put in a vote for NG2 emulation as our main focus. This is not to say NG1 specific decorators are not useful, or that there shouldn't be a library focused on making NG1 more fun to write. But the specific reason that the NG team has tasked us with working together is to provide something that compliments the upgrade path to NG2.

from ng-forward.

Alright so I think most people seem to be in favor of angular-decorators. I know Paul is on vacation and may have additional thoughts on a starting point.

In favor of continuing to move forward I have pushed the experimental branch from angular-decorators to this repo's master branch. Mike was already making some great progress so it seemed like the momentum was already there.

I'm closing this now, since the original issue was mostly intended to choose a starting point.

from ng-forward.