Maybe my initial responsive was a bit harsh. I don’t think that a complete declarative solution is useless rather highly limited. If you’re just in need of a simple read only solution, then yes, I think a fully declarative is pretty easy to get setup with and easy to maintain / read. My only concern here is future scalability. Once that read-only table needs some features added to it (ones that a declarative syntax can’t easily support), that’s when you have to decide if you need to switch to an alternate solution, create some app specific hacks, or take the time to incorporate new features into your current solution.
The reason I say this is because when starting with ELT, we too were very excited about Ember’s new declarative compatibilities when the whole notion of composable helpers was introduced. As the project grew, we quickly realized its limitations and had to come up with a solution that is flexible enough for a dev to take full control of the table from multiple places in the app as well as be composable enough to resemble a table structure.
I think this is personal preference. IMHO large templates files are really difficult to read and maintain. I dont think there is anything wrong with leaving some work and structure to the JS (again… personal preference).
Right. But my examples were highly generalized and very rudimentary. There are many cases where actions are not enough, state is required to be kept, and structure / appearance must be dynamically created.
Rolling out your table is simple. You have full control of how things are rendered, how events are bubbled, what dependencies do what, but in terms of a generalized declarative addon, I dont believe that it’s currently possible to create a solution that will cover 100% of the use cases that apps need without some sort of access to a mutable table instance.