ryanzidago
Editable tabular data / grid / table in Phoenix LiveView?
What’s the canonical way of implementing an editable tabular data / grid / table in Phoenix LiveView?
Think of a spreadsheet but only with a minimal feature set (inline editing, showing select inputs, errors, validations, suggestions, etc.).
I don’t really need multi-collaboration in real time for now.
I have to deal with anywhere between 300 - 600 rows of 30 - 50 columns and probably more in the future.
I have tried the following approaches:
1) Streams + HTML table + form per row
HTML does not allow to have a form per row so it does not work. If I’m using streams, I need to have a form per row so on input change, the Live View gets all the data for the given row, not just for the cell being currently edited.
2) Streams + HTML table + form per table using form attribute on form input
Could not make the change tracking work. The form just sends empty params.
3) Streams + HTML table + form per cell
- the form will only send one field at a time (except for the field where I explicit add
phx-value_some_fieldbut I’d need to repeat that over each input for all of the fields of the record I want to update…) - and then in the
handle_event("validate"), I would have to do the following:
def handle_event("validate", params, socket) do
changesets = socket.assigns.record_changesets
changeset = Enum.find(changesets, &(get_field(&1, :id) == params["id"])
changeset = Record.changeset(changeset.data, params)
socket = stream_insert(:changesets, changeset)
{:noreply, socket}
end
Meaning holding the collection in both the assigns and in the stream, which seems to defeat the purpose of streams in the first place.
4) Streams + indivual form input without any forms
So I have:
<tr>
<td><.input type="text" value={get_field(changeset, :some_field)} phx-change="validate" phx-value_id={get_field(changeset, :id)} .../></td>
<td><.input type="select" options={@options} value={get_field(changesetm :some_other_field)} phx-change="validate" phx-value_id={get_field(changesetm :id))} /></td>
</tr>
The problem with stream_insert is that I lose the focus on the cell that was currently being edited. All of the examples that I could find about streams seems to point out that when you want to edit a streamed item, you open a modal, go to another route, etc … I have not seen many use-case for inline editing, which makes me wonder if I am supposed to use streams for that at all.
5) CSS grid
CSS grid does not seem fit for purpose for tabular data. You can’t wrap your headers / subheaders or rows into a parent element and apply classes to the children so it becomes hard to have stuff like highlight the entire row on cell hover. I’m concerned about using CSS grid especially when requirements will grow in complexity in the future.
6) LiveView + JS library (AG-Grid, Handsontable, etc.) via Phoenix hook
Those are either expensive, or I need to duplicate some of the business logic over to JavaScript, which I’d like to avoid as it seems hard to maintain over time.
Most Liked
BartOtten
A post from mobile…so grain of salts are advised.
Replies to listed solutions.
solution 1: How about CSS with display: table? You can wrap divs in one form, no?
Solution 4: You can also add JS hooks to save cursor position and re-activate the cell after stream-insert.
Just freewheeling
assuming you also need some column aggregation / sums.
Create an matrix with input fields with a col-class and row-class. Example class=“b 2”.
Have an event handler send the values to LiveView once a value is entered. Examples just for illustration.
Number 8 in “c 2”: {{c, 2}, :equals, value: 8}
Sum column “g” in “c 3”: {{c, 3}, :calc, [{:sum, {g, nil}}]}
This assumes the whole table is in state and you can query and patch it.
If you don’t want to have state on the server, you can afaik only resort to much more (custom) JS or lazy load rows and cols after dropping the whole table after initial render (but then it gets very complicated im afraid)
That being said: this seems like a task outside the optimal scope for LiveView.
BartOtten
sreyansjain
I too have a similar requirement, I am going with the approach of one live component per cell. I am trying to create something like airtable in liveview. So my cell datatype is dynamic.
Last Post!
garrison
I’m glad to see we’ve reached the point where I don’t even need to reply to these threads anymore
But yes, you are the latest in a long line of victims here.
Thankfully the introduction of keyed :for has substantially improved the situation and the docs now recommend those by default which I am of course very happy about. I don’t know which generators use Streams but those should definitely be changed IMO.
Note that thanks to keyed :for you no longer need to use the LiveComponent hack to get good diffs, though in your particular case (a large grid) I would probably prefer the additional control.
There is very little nuance left in my position at this point; I think Streams should be deprecated. Others (including the Phoenix team) probably disagree with me, though!
Popular in Questions
Other popular topics
Latest Phoenix Threads
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security









