Open kiler129 opened 1 year ago
Awesome !
@kiler129 do you you have a dΓ©mo of this feature likΓ© in your videos ?
Awesome! Do you need help creating PR?
Hello, i would be very intereseted as well, if you need any help i would be glad to contribute
Great work ! Maybe i can help too ?
I really love this idea (used it with SonataAdmin mostly to toggle boolean value from the list view).
In term of UX we need to help the user to understand visually that the field is editable inline in the list.
A must have feature ! Great work.
@kiler129: Why the following limitation (Β« by design Β») ?
the implementation by design supports only scalars (i.e. no selects or other complex things)
Thanks in advance.
@kiler129: how did you get the embedded controller to work in your "current workflow" video?
Wouldn't it more "EasyAdmin" way to have a new QUICK_EDIT action which would add "Quick edit" button which would open modal window with the selected fields in the quick edit form?
Wouldn't it more "EasyAdmin" way to have a new QUICK_EDIT action which would add "Quick edit" button which would open modal window with the selected fields in the quick edit form?
Would probably. The real EasyAdmin way is to open the page of course but users do request this sometime to make edits a lot quicker than opening a modal or page.
Very interested ! Could this feature be implemented with Symfony UX Turbo ? Or is it a better idea to not increase the number of dependencies of the the bundle ?
Any progress on this awesome feature?
Cool feature, would like to have it
Overview (aka. TL;DR)
Editing fields in-line/on list is a common functionality present in systems where users' workflows require editing simple textual data at-mass over multiple entities. This RFC aims to bring support of editing fields directly on
index
lists in EAB:https://user-images.githubusercontent.com/1227834/215312128-90e67a59-410a-4463-a1ed-d7cfea2506de.mp4
In-line edit UX π
Ignoring the obvious spreadsheet-driven workflows, there are a myriad of scenarios where in-line edits are prevalent. Examples include:
One of the concrete examples in the app I'm developing is adding common measurements to animals. The physical workflow mandates mass-entry after measurements are taken for multiple animals.
π The current workflow can be seen below:
https://user-images.githubusercontent.com/1227834/215312171-204d6de1-692c-4be3-9dc8-deb068d8ea15.mp4
π Now, let's try with inline "edits":
https://user-images.githubusercontent.com/1227834/215312244-3e079fef-df93-4418-addb-d660642d00f6.mp4
This is way faster π It offers a realtime and non-intrusive feedback to the user as well. Naturally, these two ways are not 1:1 comparable, as the full edit contains many more options, but the in-line style can eliminate the majority of "full edits".
Scope π
This feature can get quite complex very quickly. To make it useful I needed to go beyond just simple editing of a text field, as from the beginning my use-case required actually adding a new related entity (as you can probably see on the video).
The planned scope:
InlineEditableField
which is able to transparently submit a value to the backendTextField
orNumberField
Implementation π¨βπ»
What is shown in this RFC isn't a mock-up. It is a working implementation tested in my project. The code isn't PR-ready just yet, however it was written specifically with upstreaming in mind ;) The changes needed aren't extensive.
Data persistence
To support the data persistence changes need to be made to
new()
andedit()
to supportPOST
/PUT
/PATCH
withapplication/json
payload. While using the standardPOST
and normal form handling seemed feasible at first, it quickly became a nightmare in our project. There were many reasons like issues with JSFormData
not handling arrays, or Symfony Forms not expecting a partial update w/PATCH
. The changes to properly support this part include:Form::submit()
protected function getResponseAfterAjaxSave()
(draft name) method onAbstractCrudController
, which serves a purpose similar togetRedirectResponseAfterSave()
and provides a new display valueField construction
Providing the new field is actually more complicated. The new fields supports the following options:
Action::EDIT
by default, can be changed toAction::NEW
PATCH
for edit andPOST
for newThe frontend went through many revisions in my case. Currently, the form for each field is lazy-created as needed by a vanilla JS. The reason for that is provisioning for displaying a list with 5+ editable columns and 100+ rows. That would introduce a severe DOM pollution and a heavy backend load to render something which isn't used 99% of the time (i.e. when browsing lists). Nevertheless, it uses standard Bootstrap popovers &
<form>
elements. The only custom thing is supportingEsc
to abort edit.The form creation process support setting a size of the field, postfix, name of the "save" button, as well as the optional field placeholder.
Known limitations
Rationale π
I saw this asked in many issues, I was able to quickly locate one: https://github.com/EasyCorp/EasyAdminBundle/issues/365. In addition, this feature doesn't set a precedent due to already-present "AJAX".
The only dynamic list field present in EAB is
BooleanField
, which can be rendered as a "switch". While changing it in any way is out of scope for this issue, it can easily be done. The one-off code inAbstractCrudController::edit()
could be removed. The current implementation will certainly be able to handle1/0
update with just minor JS changes toBooleanField
.WDYT?