Tables have long served the web. I'll reflect briefly here on some implementations in Ember.js
Single page applications often need to display data with some visual structure. HTML tables have long filled this void. In Ember.js we have a few leading implementations. I want to summarize my experience building features with tables in Ember.js. By problems I mean obstacles in day-to-day development not boiling cauldrons of emotional angst. I'll first discuss using the primitives provided by Ember core and then in two leading implementations: ember-light-table and ember-table.
do-it-yourself (not invented here)
I and team first built tabular sections in our application using our own components. Ember primitives often make this painless. A few of these tables, implemented 4 plus years ago, still run strong. For any basic, read-only displays of tabular data, I would take this approach. However, other use cases swarm and demand sophisticated implementations.
I'll pause to describe my topsy-turvy internal dialog when considering adding new dependencies to an application. I am professionally lazy. I avoid adding dependencies "just because" or when they appear to do something I need only partially. Long-term, dependencies incur costs I tire of paying: upgrades, maintenance, and bugs from both of these combined. Yet, being lazy, I do not want to reinvent the web-application wheel. Especially when ad hoc "feature requirements" pile up like the dishes in my kitchen sink. Dragging columns, bulk selection, loading 500+ rows "fast", editing within rows, etc. In these cases I want to share a solution and build upon efforts by talented, hard-working people solving the same problems. So, on with actually discussing 2 table addons.
ember light table
I first worked with ember-light-table a couple years ago whilst Ember strolled the 2.x lands. The basic documentation shined and it promoted best practices in component design and data flow. I and team built a complex, data laden feature using ember-light-table. We had a few struggles. Advanced customizations required us to look beyond the introductory documentation. Experimentation and reading the source became our solutions. We also fought with rendering performance. Tables that do not have the same performance requirements could benefit from using ember-light-table. Our team needed to build a major feature that would load hundreds of rows. We searched for an implementation that performed well and happened upon ember-table.
I only have experience using the 2.x beta releases of ember-table. I found basic documentation vital for easily building a real example in our application. Performant rendering happens by default thanks to the "svelte render" using vertical-collection. We struggled most with customizing row selection behavior and a lack of advanced use case documentation. Given internal deadlines, we wrote our own selection behavior. I felt that was simpler than trying to naively build performance functionality. Looking at the project as a whole, I see increased development and responsiveness from the maintainers and those leading development. I feel strongly about this since a polished 2.0 release approaches.
I've picked 2 projects that I and team have worked with in our application. These are not the only ones; explore emberobserver's dedicated category for the current list. If this article has felt light on technical details, I agree. I see value to sharing actual experience while building digital things in Ember using community projects. Addons make working professionally in Ember delightful. They, along with the core framework, make me look smart when delivering features in or under time. I feel an elated laziness when I install and things just work. So, to summarize, thanks to each person behind creating and maintaining these addons. To a future, growing!