Design Thoughts

• Styles used in ng-scrolling-table should inherit/reflect styles (or at least close promixate) those of Material design. Highlight color, primary color, border color etc. should all be derived from the equivalent themes in Material.

For the future, Angular 2.0 will drastically change the interaction of existing components. As such, the library should be positioned to better adapt to the 2.0 design principles. Some suggestions include

• Always favor declarative over imperative/programmatic handling. Try and avoid "model" knowledge in directives. Favor the DOM as the source of record if possible.
• Use events to trigger interaction between directives vs. direct calling. Use a set of published "event names" to handle things like "selection", "sorting", "collapsing", "resizing" etc.
• avoid the use of jQuery and Angular jqLite functionality. jqLite is going away, and jQuery as a maintstream may follow in time. the DOM methods should be sufficient on ever-green browsers
• simplify defaults. Curently when you add the table directive to get resizing and selection you have to implement additional directives. this is wrong. It should be implicit with an opt-out property/directive
• explore virtual scrolling for all tables with Enzy library. Need to see how this handles column sizing/rendering as different data sizes are brought into the virtual viewport.

The end goals should be maintained

1. Focus on augmentation as opposed to rewriting. HTML table tags are good at rendering tables and laying out cells - it is what they are implying. Don't try to create div tables or some other nonesense. Augment what is there to make it more powerful.
2. Minimal dependency on third-party libraries. Keep it pure and minimalist.
3. Provide the key aspects of functionality a user expects (see below)
4. Performance is paramount.

Core Features That Need to be Build / Maintained

• Augment standard HTML tables elements
• Tables should scroll vertically when placed within a confined space with the headers been sticky
• Provide modern look and feel table with appropriate styling of headers etc.
• Support wrap-around text and flowing of column widths based on content. Should not have to declare all the column widths!
• Support resizing of columns (unless marked as fixed)
• Support reordering of column (not present)
• Support the ability to hide/show columns
• Support the adaptive responsive behavior via column prioritization (columns of lesser importance should "drop off" if insufficient width is available) (not present)
• Support sorting of column and provide basic "sort" for text (with ability to override behavior, including supporting Remote Sort - implies new row data fetched) (not present)
• Support inline editing of cell values (provide a way to do this declaratively) (not present)
• Support the ability to support single or multi-line selection
• Support the ability to gracefully handle empty tables while still restricting "some" screen real-estate
• Performant in tracking changes to rows (modification, inserts and deletes)

Editable Tables

Editable content in tables is effective in many ways. We also want to leverage declarative markup without a lot of programmatic JS being needed. For simple text/number/Boolean model values a basic editor can be used with the model expression. However this would only work for simple expressions that are rendering of plain text model values (for example {{model.name}}). For expressions that involve more complex interaction or functions determination over the model to update can not be implied by the expression. As well, the rendered value may not represent the model's true value (an example would be a country column. The name may be shown, but the editor may need to pick from a list of countries since the country in the model is an ID value.)

Some design thoughts:

• Not all values in a row will be editable.
• Editing may involve "in-place" editing, firing an edit event that causes a component to be enabled and focused, or even open a popup. These interactions will be left for the user of the library to implement. The library should only enable the firing of an event with the row model and column identifier (as well as the read-only rendered value) and in-place editing.
• trigging the edit can be done by single click (excel like functionality), double click or right-click menu selection. The right-click is beyond the scope of the library currently, however the table/edit "watcher" of the table should be able to respond to an event to edit a "row" and "cell/column"
• ideally editors should be markup either in a template or in the page (but hidden) and "cloned" with the row model (and other information) to support editing the cell.
• standard event names should be defined that can be used to process the edit completion. Another option would be some form of prototype interface that can be called on completion (or change) by the template.
• one challenge is knowing when the edit values should be "persisted". For example you could in theory update to model on the server after each cell update, however if the object does not exist (new row insertion) or has dependent model values (one value is only editable if another value is set to a value) then control over "when" a row is effectively changed needs to be made on a table by table basis.
• for in-place edit, a directive should be used to modify the DOM of the cell to the "edit" mode.

Example syntax or a cell.....

<td editable="dbl-click" edit-template="templates/name-editor.html">{{model.name}}</td>

Another approach could be to define a declarative construct as a peer to the table

<table id="table-123">
  <thead> 
     <tr>
       <th>Name</th>
       <th>Phone Number</th>
     </tr>
  </thead>
  <tbody>
    <tr><td>{{model.name}}</td></tr>
    <tr><td>{{model.phoneNumber}}</td></tr>
  </tbody>
</table>
<table-editor for="#table-123" edit-style="dbl-click">
  <editor col="0" edit-template="templates/name-editor.html"></editor>
  <editor col="Phone Number"><input type="text" value="{{model}}"/></editor>
</table-editor>