I’m at the early stages of building a SaaS app. I want it to be 2.0 ready with minimal refactoring. As such I’m building along the lines of : Future Proofing Your Ember 1.0 App
Problem is I’m finding nothing is gelling that well at all and frankly it feels a bit fragile while we span this not-quite-2.0 status of minimally implementing controllers and eliminating views.
The problem is, if like Google’s Material Design components, you consider components to be totally self contained and unaware of the context in which they are to function, you can’t very send data down from the route (or controller if you’re using them) and actions back up into the route (or controller). Because the component won’t be portable, it’s now dependent and therefore not as reusable as I understand a web component is supposed to be.
For example, if I have a dynamic navigation component, should it not load the links to iterate directly?
If it were me, I’d prefer to have the component use the store to load the model and iterate directly. And if the user re-sorts the nav or adds/removes a link, marks as a favorite, … should it handle this interaction directly within the component (or possible sub-component). I mean, if we are totally breaking the MVC pattern, why not go all the way?
Perhaps there is some unexpected impact on the lifecycle or rendering that I’m not aware of (eg loading routes … ?)
Would appreciate comments/feedback.
I think you’re saying that sometimes the component can’t really function completely without some of the server interaction stuff that would normally go in the route in data down actions up. This means you end shuffling that logic around to different routes as you move your component which is dumb. It seems like components are implied to be view only components rather than full on self contained units of functionality.
One possible solution I’ve been playing with is wrapping server persistence domain logic in a pojo that I pass to the component. You still have to instantiate that pojo in different routes but I’ve found it to be a good balance between a more data down actions up approach and not having to shuffle around complex logic between different routes. If you would prefer not to have the pojo dependency then you could use a service instead. This is essentially using the store directly but with one more layer of abstraction allowing for sharing of domain logic between components. A third option is to try and use route nesting to centralize your server persistence domain logic. Basically find the common ancestor to all the components that share the server persistence logic and bubble your actions to there.
The recent Ember NYC component talk discussed briefly communications between components. Ember.js NYC, Apr. 23 2015: Ember Components Deep Dive with Ray Tiley, and more! - YouTube If you have time watch the whole talk it’s a great overview of components now and what’s coming up.
Yeah, ok. I’ll check out that vid. Thanks for the input.
If anyone else has thoughts on how to handle this either in 2.0 or in the interim and whether using the store directly within a self-contained component is good or bad, I’d appreciate comments.