Hi, currently I am struggeling to get my head around the current architecture of Ember. As I understand Ember was MVC in the past but now is DDAU. In reference to this always routable components are mentioned but they do not exist, yet?! I am working on an Application, where different functional parts have to communicate to each other but are in the same route. As I understand components are isolated to the surrounding, which makes it complicated for me. As I don‘t need the parts again in any other part of my Application (only 3 or 4 routes), I decided the following: -Different routes with own controller and template → each route represent one core functionality -One Model injected into routes or service? -Service for general data handling So this works like a charm, is easy and clear. Why should I use components? Do you see any problems on this approach? Sure, I could pack my whole controller content in a component but I think thats not the way to do it. What would this be called, what I am doing? Thanks!
Definitely a lot to wrap your head around here. I’ll try and break down some general rules of thumb, hopefully it will be helpful.
MVC and DDAU aren’t mutually exclusive. Ember is still just as much an MVC framework as it ever was, An ember route fetches the model, the controller modifies/sorts/filters/etc the model and provides other bits of view-state data and handles actions, and the template represents the “view”. DDAU is more specifically related to components, and to who (or rather what) owns (and therefore modifies) the data. AFAIK the DDAU principles were inspired heavily by React. The basic idea is that you want to be really explicit what is modifying the data in an application, so instead of mutating data directly, a component should pass an action up to the data owner (usually a route/controller) which modifies the data on the components behalf.
As for routable components… you’ll definitely see a lot of literature heralding their arrival, and we’re getting a lot closer, but for now (and possible for a really long time) routes and controllers are here to stay. So use them without worry.
Some people are pretty dogmatic about both DDAU and about component abstraction. IMHO they’re both very important but they don’t cover all cases and should be more rules of thumb than hard and fast laws. Component design is more of an art than a science, so there are differing opinions. Just want to give that preface before I mention the following, which I would consider good rules of thumbs:
- Don’t over-abstract components too early. This can get messy and over complicated. While I’d recommend using components vs just putting everything in routes/controllers, I think it makes a lot of sense to write your route/template and put actions and view state in your controller for starters, then abstract out components that make sense. Anything that will be repeated/reused is a great candidate for a component, and organizing a view into logical and maintainable units is another great reason to use them (think a massive function that you break into smaller sub-functions).
- Don’t avoid using controllers, they’re not going away any time soon
- DDAU is a really good general guideline, and you should definitely use it, but there are some scenarios where it just doesn’t make sense. Don’t compromise good design just to follow DDAU.
- The router is meant for loading data, and it solves a lot of data loading problems, so in general you should try and load data in your route model hook. However there are some places where it may make sense to do it in a controller or component. Similar to DDAU, don’t be too dogmatic about this either.
- Services are great for data/functionality which needs to be shared in a more global fashion. Examples are things like authentication session, permissions, subscription services, etc.
I don’t necessarily think there’s anything wrong with the approach you described, but I think abstracting a few components out would still be helpful in most if not all cases, so I would consider it for anything that will be repeated across two or more templates, or things that make sense with their own discrete chunks of state.
Anyway hope all that makes sense, feel free to ask any more follow up questions or anything else here. And good luck!
Hi, thank you so much for your detailed explanations! They are really helpfull.
In fact, I have another question regarding ember-data/store: When I don’t save the data explicitly/persistent, how long will the data be in the store, as long as the user is in the current route, or as along as the user uses the app? Thanks!
Data in the store is persisted as long as the user is using the app, essentially. A refresh will clear the store as will closing the tab/window. So if you had “unsaved” records they would remain in your frontend store until the store was destroyed (on app teardown) or until the records were manually destroyed.
If you wanted to destroy “unpersisted” records on a router transition that would be pretty easy to accomplish using the willTransition hook in your route.