in production for over a year. Ember has been moving fast (as you know), we have lots of bumps and bruises, but really liking where the framework is headed. large ember application... 41 controllers (story)
13 taking a step back One of the recurring themes we’ve faced is how to extract templates and behavior to simplify and better reuse code. We’ve tried several approaches and most brought us....
we have a “paginated list” used many places around our ember application has a variety of different uses, different columns, content, paginated or infinite scroll, etc... prior to components, what are the options for sharing view templates and behavior? all prior alternatives have great use-cases, but I’d argue that they aren’t really suited for real reuse
low-level control if you need it... con: can be quite confusing to make sure you know about how to setup context, etc. con: not something you should be doing if you want reusable code to be a pattern in your codebase IMO.
ended up doing when we faced this problem awhile ago. pro: can encapsulate both template and behavior con: you’re still sharing context with the parent view, which can make it hard to reuse if you aren’t careful con: if you need data for your shared view, you’ll have to manually setup any controllers or related objects
when we were building this, we may have used it instead. I don’t have much hand on knowledge of render, but the idea is it setups up a MVC structure like a route would. pro: encapsulated, isolated template and behavior! con: can be heavy weight if you don’t have a model or much related data con: expects a model, which can make it hard to reuse in a generic way.
we talked high level company goals but we also were able to start hacking on a refresh of our interface and update our ember skillz with all the newest stuff and write some golang...
components. used elsewhere in the app, not just specific to campaigns. Just needs to know about a few pieces of data needs control over template and view to properly setup and render.
to met the “Custom Elements” spec context is limited to only data passed to the component. we can now use the component to render any type of data (rather then being tied to a campaign, etc)