I need to port an app that includes tables for viewing and editing budget levels. Key features:
Fixed columns on the top and left, with a scrollable region that fills the bottom right of the table’s div.
Spanning rows and columns
An input cell that can be moved around the grid using arrow keys and mouse. Events for changes in the cell, plus enter and tab keys
Ability to specify cells as read-only (i.e. won’t accept input cell)
Apply styles at the cell level.
Ability to update the contents of any cell (values and styles) in response to events using x,y coordinates.
This will be in a desktop app so it doesn’t need to be responsive. I don’t need row filtering or sorting, and I don’t need anything like paging or infinite scroll. It won’t need to do any spreadsheet-like math, since that will happen on the server.
This is a pretty specialized scenario, so I expect to implement it myself, but I would appreciate it if anyone could point to examples of the features listed above to get me started!
In making a decision about the design I would start with the above statement. Is the app essentially just the editable table? Or is the editable table merely one way to view / interact with the data in a much larger application? This will drive how you should define your data types and, in turn, how your table will consume this data.
I suggest reading the “About API Design” section of Evan’s elm-sortable-table package. Pay special attention to the Single Source of Truth section, as that can be very relevant here.
Moreover, you can look at the API of that package for some ideas that are tangential to your needs. Things like applying custom styling (as well as an actual table display) are demonstrated by that package.
Cells
a. For using the arrow keys, you’ll need to way for the cell to be “focused”.
b. I’ve not done drag-and-drop in Elm but I’ve seen people quoting this article a lot
This can be done with a union type
This could use a class or you could set inline styles
You should be able to use the standard Elm architecture here, just make sure you pass the coordinates along with the Msg.
I’d put some thought into the data structure backing this table. Just because you’re displaying it as a table doesn’t mean you want to store it as an array of arrays. Given the requirement of having “focus” (is some cell always focused?) you may want to use some sort of zipper structure.