EmberJS Confuses Me • Hacker News Board

Re: EmberJS Confuses Me

#21

Post by jfarmer » Wed, Mar 06, 2013, 9:08 PM UTC

robconery wrote: post #15

jfarmer wrote: post #9

I've never used EmberJS and am not familiar with any of the front-end JavaScript frameworks, but I don't get what's confusing. It looks like instead of the controller pushing data to the view, the view asks the controller for data (which it might proxy to the model). This makes sense with a long-running controller, right? On the web both the controller and view are ephemeral -- they last for just that one request --…

The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.

That's not how I'm seeing it. The controller has data, some of which might be from the model. The view shouldn't care whether the data came from a model or not. It would be coupling if the view did care.

The view asks the controller for data. The controller might delegate that question to the model. The view shouldn't care whether the data was delegated or not; it should just get a response from the controller.

Seems like textbook object-oriented design. Otherwise how will the views update automatically when the models change? The views shouldn't know what models it needs. In fact, it seems they shouldn't know that models are a thing at all. It's just data from the controller.

Re: EmberJS Confuses Me

#22

Post by robconery » Wed, Mar 06, 2013, 9:08 PM UTC

clintjhill wrote: post #16

robconery wrote: post #10

Earlier quoted context omitted.

The examples were to show how $scope is used in Angular vs direct use of the Controller/Model proxy in Ember. This makes a bit more sense to me, personally.

Except you could write identical code in Ember as well when you extend the controller. Replace "$scope" with "content" and it's identical.

Interesting - didn't know this. $scope is injected by Angular and available to the view - is this the same thing? I didn't think Ember had a DI aspect to it.

Re: EmberJS Confuses Me

#23

Post by ef4 » Wed, Mar 06, 2013, 9:08 PM UTC

robconery wrote: post #15

jfarmer wrote: post #9

I've never used EmberJS and am not familiar with any of the front-end JavaScript frameworks, but I don't get what's confusing. It looks like instead of the controller pushing data to the view, the view asks the controller for data (which it might proxy to the model). This makes sense with a long-running controller, right? On the web both the controller and view are ephemeral -- they last for just that one request --…

The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.

> The controller is the data.

No, it's not. Because a single controller over its lifetime can be bound to many different models.

The controller is glue. It brings together whichever model is appropriate at the moment with whatever view is appropriate at the moment, and makes decisions about when to change those things.

Re: EmberJS Confuses Me

#24

Post by robconery » Wed, Mar 06, 2013, 9:08 PM UTC

randall wrote: post #14

The Angular example is a bit incorrect... when you do an ng-repeat, you're going to do like ng-repeat="person in people" and then each template item will be like {{person.name}} as opposed to just {{name}}. Just a little clarity in the code. Thanks for the writeup!

This is fixed - thank you.

Re: EmberJS Confuses Me

#25

Post by robconery » Wed, Mar 06, 2013, 9:10 PM UTC

clintjhill wrote: post #18

robconery wrote: post #15

Earlier quoted context omitted.

The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.

The controller is responsible for rendering the view when the data changes. It does graft the model data - and any other data you want renderable into the view. I wouldn't characterize it as "the data" however.

How is the controller not the data as far as the View is concerned?

Re: EmberJS Confuses Me

#26

Post by ef4 » Wed, Mar 06, 2013, 9:12 PM UTC

robconery wrote: post #19

ef4 wrote: post #17

> When talking routes, urls, and resources - that's a RESTful consideration and involves stateless state "stuff" (sidestepping the REST debate here). What is this concept doing in a desktop app?. Ember is explicitly not about "desktop apps". That's actually why Ember broke off from Sproutcore. Ember is very opinionatedly focused on building web applications that are native to the web and stick to web conventions. The…

The team has been rather clear that Ember is Desktop MVC, not web/server based: https://twitter.com/trek/status/309315009291378690 They say as much in their guides as well.

> The team has been rather clear that Ember is Desktop MVC, not web/server based

That's orthogonal to what I'm talking about. I agree that their use of the term "MVC" is much closer to the original meaning it had on the desktop (like in Cocoa) than the meaning in server-side frameworks like Rails.

But I'm not talking about what MVC means. I'm talking about what kind of applications Ember is intended to be used to build.

A flagship example would be Discourse, which is very deeply web-focused, and nothing like the way you would structure a desktop application.

Re: EmberJS Confuses Me

#27

Post by jfarmer » Wed, Mar 06, 2013, 9:13 PM UTC

clintjhill wrote: post #18

robconery wrote: post #15

Earlier quoted context omitted.

The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.

The controller is responsible for rendering the view when the data changes. It does graft the model data - and any other data you want renderable into the view. I wouldn't characterize it as "the data" however.

@rob: The controller should be the data as far as the view is concerned. Otherwise the view knows too much and the controller can't re-proxy a different model.

Re: EmberJS Confuses Me

#28

Post by avolcano » Wed, Mar 06, 2013, 9:13 PM UTC

While I actually totally agree with the confusion in the router, I want to explain what I see in Ember's MVC:

As far as I attempted to implement it in my app (https://github.com/thomasboyt/noted-app), it seemed simple enough. Models were data; all they contained was their properties and operations that controlled their properties.

I mainly used controllers as the "state" for parts of my app. In Ember, this doesn't even need to mean it's tied to a specific model type. For example, my Dropbox integration is handled within a controller that's bound to several separate views (in this case, those views included buttons that triggered syncing and modals that displayed the progress of syncing). There's no "Dropbox model," just other models that I'm using this controller to sync. Controllers are not simply an intermediary between models and views, they are an intermediary between state and views.

> I'm trying my best to reconcile this with the notion that a controller (classically speaking) is supposed to ... well control the view. Here, it's not doing that.

I think what the author was looking for in controllers is what's actually handled by, well, views. The view handles any user interaction, and then uses the controller to change the state of various bits (whether calling methods in the controller or simply updating properties on it).

To sum up: model is data, controller is state (including instance(s) of models), and the view is user interaction. Templates can bind to properties on any of these. Routes are what hook these components together depending on the page.

Re: EmberJS Confuses Me

#29

Post by xaritas » Wed, Mar 06, 2013, 9:15 PM UTC

pilgrim689 wrote: post #4

> The downside to this approach is that your HTML is "compromised", if you will, and many developers don't like that. My thought is that it's already compromised using Handlebars so what's the difference here? Personally I have no issue using the ng-* directives. Some people do, and I respect that. I'm a bit off-topic, but you don't need to "compromise" your HTML with AngularJS, you can place "data-" in front of your…

When I hear this argument I believe the concern is not the syntax of the binding with respect to the HTML spec, but rather the declaration of bindings in HTML at all. So the issue is not "ng-click" vs. "data-ng-click", but that "ng-click" in any form is no different than the pre-JS MVC horrors of onclick="mutateGlobalStateAndPerformIO()"; which is precisely the barbaric approach we thought we were vanquishing. I think that some people prefer to see bindings sprinkled on the DOM via code, as part of the bootstrapping process. I haven't used Backbone for a year but I'm pretty sure it is a strong proponent of "let nothing live in the DOM" school of thought. I don't subscribe to that, by the way, but that's the argument.

Re: EmberJS Confuses Me

#30

Post by clintjhill » Wed, Mar 06, 2013, 9:19 PM UTC

jfarmer wrote: post #21

robconery wrote: post #15

Earlier quoted context omitted.

The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.

That's not how I'm seeing it. The controller has data, some of which might be from the model. The view shouldn't care whether the data came from a model or not. It would be coupling if the view did care. The view asks the controller for data. The controller might delegate that question to the model. The view shouldn't care whether the data was delegated or not; it should just get a response from the controller. Seems…

This is actually where I think Ember does better than the Angular sample provided. Ember controllers hold the "data" in a "content" field on the controller (proxied). Any model can be placed there. If you do add a "people" field to the controller (as in the sample) I'd argue that does what you're describing here as "bad" because it's specifying information in the view about the model.