forms
forms copied to clipboard
add multiple options with one paste #337
Signed-off-by: hamza221 [email protected]
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 37.67%. Comparing base (
8e0f7e0
) to head (b378a00
).
:exclamation: Current head b378a00 differs from pull request most recent head ad1ac93
Please upload reports for the commit ad1ac93 to get more accurate results.
Additional details and impacted files
@@ Coverage Diff @@
## main #1407 +/- ##
============================================
- Coverage 45.02% 37.67% -7.36%
+ Complexity 720 514 -206
============================================
Files 61 49 -12
Lines 2776 1911 -865
============================================
- Hits 1250 720 -530
+ Misses 1526 1191 -335
I pushed a quick POC of @jotoeri 's idea.
... How about a modal here, too? Just keep everything as it is with simple inputs and add a modal(-component) to the actions-menu, that has one large textarea? Or even better the NcRichContenteditable then...
If everyone agrees this is the way to go, I would appreciate some design advices. from @jancborchardt or anyone who has an input on the matter.
Happy holidays everyone 🎄
@hamza221 I like the modal 🎉 Especially the representation of the options below the input field. I think it might be useful to show a text that makes it clear that you have to use new lines for new options.
I only rebased and fixed conflicts, still not ready for review
@susnux @hamza221 I did some rebasing and refactoring of the code. The modal/dialog itself works like expected. However the functionality and design still needs some more love. I think we could get this ready without too much effort for 4.3.
The bubbles below with the recognized options (that's what it is, right?) could be using the regular tag style like in Mail. :)
Yes, that's what these are for :) good idea 👍🏻
@jancborchardt I think the NcSelect component fits our needs here as well and is less code to implement. I also added a loading indicator as it might take some time until all options get created on the server.
- [ ] The loading time on adding the options is quite long, can that be optimized somehow?
@jancborchardt We already looked into it. The problem is that we can only submit one option per API request at the moment. So we could do three things:
-
send all requests at basically the same time and await all responses to then store the server ID/order of the options to the front end. -> Options won't keep the original order from the input. (optional with checkbox?)
-
keep it that way and adjust API in the future to post several options in one request
-
keep it that way and adjust API in the future to add the order to the post request
- [ ] "Entered options" wording is a bit strange, maybe better "Options summary"
What about just "Options"?
What about just "Options"?
:+1:
keep it that way and adjust API in the future to add the order to the post request
I think this is hard as setting the order requires to know the total amount of options which is hard to validate on the backend, e.g. if option 5 arrives before option 4.
send all requests at basically the same time and await all responses to then store the server ID/order of the options to the front end. -> Options won't keep the original order from the input. (optional with checkbox?)
For the mentioned reason this is bad UX
keep it that way and adjust API in the future to post several options in one request
I think this is the way to go
@susnux ok, so we merge this and do a follow up for the new API version?