ryanzidago
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.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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.
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
The million dollar question: does column data matter or are we only talking rows?
sreyansjain
You can have inputs with a form attribute. The input doesn’t need to inside the form.
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.
ryanzidago
I have tried this, this is approach 2) but could not make it work with LiveView.
ryanzidago
Unfortunately, I don’t know enough about spreadsheets or the problem space to answer you this question
My educated guess tells me that we care much more about rows than columns as each rows are isolated from one another. There will be no dependencies in the like of:
ryanzidago
@BartOtten @sreyansjain
In the end, I’ve decided to ditch streams and resort to one live component per row. This works well for now and no focus is lost on input changes.
This post and the fact that they come with the default generator made me think that streams should be the go to for handling a large collections in LiveViev.
Though after dealing with the spreadsheet use case + reading this comment from @garrison it seems that I’m missing some nuance on when and when not to use streams.
cmo
I would go with option 6. The others feel like a lot of work.
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
:forhas 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
:foryou 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!