Why is Endev renaming common Angular directives?

[macaullyjames]

One of the things I found made it hard to understand Endev was the fact that some of the most common directives mean different things in Endev than they do in vanilla Angular. For example, the if directive is actually a thin wrapper around the ng-show directive in Angular, whilst the ng-if directive maps (in part) to the Endev directives edit and new. Moreover, quite a few directives are simply renaming common Angular directives; the value directive is just a thin wrapper around ng-model, the click directive is a thin wrapper around ng-click and the list directive is again basically just a thin wrapper around ng-repeat.

What is the benefit of this compared to using the native Angular directives directly? From a beginner's standpoint, it means that I have to learn both the Endev and Angular syntaxes (since Endev wraps only a small fraction of the entire Angular API), and the Endev syntax isn't applicable anywhere else. Don't get me wrong, I actually prefer the alternative syntax, I just don't understand why it's a part of Endev; the fact that writing click is quicker than writing ng-click has nothing to do with making server-side data more accessible.

How would you feel about me either breaking it out into a separate project or just removing it entirely? I think it would really help make the project easier to understand and use, and put the focus of the project back on manipulating data declaratively in HTML :)

[filipkis]

The idea of thin wrappers is that Endev is designed to be independent from Angular. Angular is just currently the framework of choice for all the magical binding, but when Endev constructs were designed, we thought about them independently. So that is the general idea of thin wrappers. It is true that some users will need to learn both, but ideally Endev could be used without knowing you are actually using Angular at all (that's the vision at least).

There are some specifics too. For instance the Endev if maps to Angular show instead to Angular if because angular if creates new isolated (or is it child, I forgot) scope which messes up references. Show was therefore better for Endev use.

Then, the edit and new constructs in Endev are just conceptual constructs to deal with the case when you are editing an existing object (already stored in the provider) or working on the newly created one. The newly created object is identified with "$isDefault" flag on the scope, so basically those two directives just wrap if to show/hide stuff depending on that flag. We don't want to confuse the user with needing to write something like ng-if="$isDefault"... when it can be just data-new. Thinking about it, maybe it would be better that they map to show instead of if as well, but so far the if was not an issue (I prefer if when it behaves good as it removes the HTML node instead of just hiding it, so the HTML looks nicer when exploring the running one).

As for writing click, vs. writing ng-click. I agree from computer science perspective, however from non-experienced user how do you explain the ng-? When to use it, when not? You need to then explain Angular and what's Angular, what's Endev. I'd rather have have a version of Angular powered Endev that has the basic functionality wrapped for simplicity.

But I agree that these wrappers could be just extracted to a new module (e.g. "endev-anguar-basic-directive-wrappers".. ok it's a mouth full, but something like that) that should be included by default in the "full" package, but not in the basic one (the one meant for more experienced users using it in integrated manner).

[macaullyjames]

That sounds reasonable, and I agree that saying "go learn angular, then come back" probably isn't making things easier for the end user. Especially if the target audience is people that aren't really programmers ^^

This could actually lead to a really nice separation of interests. You have Endev, which is meant to be a top-to-bottom solution for simply making small web apps. It's simple because it provides a small subset of declarative control flow (the equivalent of if, for etc. in empirical languages) so you don't need to write Javascript, as well as providing a declarative way of handling persistent data in the HTML.

So Endev is really a combination of two disjunct projects: "endev-storage" and "endev-control-syntax" (or "endev-anguar-basic-directive-wrappers" ;)). What's nice about that is that both components hold their own; you can use the simple data handling in an Angular project without the syntax (great for people that are already familiar with Angular), and you can use the simple syntax without having to use the data handling module (great for people transitioning from Endev to full Angular).

If you want, I can start separating the two :) I'll wait until you've had the chance to review #2 though.

[filipkis]

Yep, that sounds good.

I'll try to review the code by Thursday. If I don't manage, proceed with the separation as I probably then won't have time to do it before August.

On Sun, Jul 12, 2015 at 3:10 PM, Macaully James Muir < notifications@github.com> wrote:

That sounds reasonable, and I agree that saying "go learn angular, then come back" probably isn't making things easier for the end user. Especially if the target audience is people that aren't really programmers ^^

This could actually lead to a really nice separation of interests. You have Endev, which is meant to be a top-to-bottom solution for simply making small web apps. It's simple because it provides a small subset of declarative control flow (the equivalent of if, for etc. in empirical languages) so you don't need to write Javascript, as well as providing a declarative way of handling persistent data in the HTML.

So Endev is really a combination of two disjunct projects: "endev-storage" and "endev-control-syntax" (or "endev-anguar-basic-directive-wrappers" ;)). What's nice about that is that both components hold their own; you can use the simple data handling in an Angular project without the syntax (great for people that are already familiar with Angular), and you can use the simple syntax without having to use the data handling module (great for people transitioning from Endev to full Angular).

If you want, I can start separating the two :) I'll wait until you've had the chance to review #2 https://github.com/filipkis/endev/pull/2 though.

— Reply to this email directly or view it on GitHub https://github.com/filipkis/endev/issues/3#issuecomment-120720195.

[macaullyjames]

Good stuff! :)