I’m creating an app like Doodle, in which I can create date options inside a new survey.
Since I couldn’t submit a form (new option) from a form (new poll), I actually
created a new row in poll
opened the detail view for this row
used text fields in the details view and a form for the options
Does anyone know how the quota is counted in this case though ?
Since there is no more submission, I’m not sur what would count as an update.
If you want to try the app (and hopefully this won’t use all my quota), here it is :
Thanks, I’m familiar with this list, but there is indeed some important information here :
When a user changes data via a component on a details screen - for example, changing a toggle - that’s one update.
I’m not sure when this is counted for text fields, but I’ll make the assumption it’s when I leave the text field. I’ll have a look if I can use an edit screen instead of a detail screen and still create new options from there.
An edit screen will be better for your updates count, since it only commits the update when you “submit” it, not like a “details view” entry when it can commit an update every few seconds.
Indeed, but I couldn’t find a way to create something else from an edit screen.
The form to create “Options” opens, but nothing is created when I submit it :
After a pretty long discussion, Glide’s support decided it wasn’t a bug
The new row will be not added because you are sending the data from an Edit screen. The Edit screen is just a copy of the detail screen but it will not allow to add data.
In order to accomplish what you need, you need to do it from a detail screen as I showed in my previous video. […]
However, why do you need to use the edit screen as opposed to the detail screen?
I tried to explain that using a detail screen was using more quota
Good question.
In my application, the form is a lot more complex.
I may have 15 editable fields.
If I use a detail screen, each edit will be counted against my quota.
I’m very concerned I could reach my limit quickly.
If I could use an edit screen, I would count only for 1 edit.
That would make it a lot more scalable.
Does that make sense?
The edits made in a form are counted as 1. If you change, say 15 columns in a form, the change will count as one because the form will sync once.
That’s what I said isn’t it.
It’s not the case for detailed views. Each field edit will count as 1.
This is not a bug on our part. This is the expected behavior. Unfortunately, you need to find a different flow for you to accomplish what you need.
I’m feeling a little bit let down.
I’ll keep using a detailed view, but I definitely disagree with the conclusion here.
a form shouldn’t submit and do nothing without error
this limitation should be documented somewhere
we shouldn’t be able to add an “add” button from an edit view
Form screens and edit screens have the same behavior actually.
In my video, the category screen is an edit screen, and the add button goes to a form screen.
Generally I would not recommend having an add screen inside an edit screen.
With Glide, edit screens are tied to the behaviour of “I can go into the edit screen, make these edits, then either commit it or cancel, go back and return to the state before I enter the edit screen”.
It might be just me, but having a form inside an edit screen, apart from technical problems like you have experienced (albeit I still think it should work), would create a false sense of “I can revert these added rows”, while obviously that’s not the case.
What I usually do is have the collection inside the details view, and have a form action tied to the collection level to open a form and add related items.
You can add time slots directly from a poll.
Even though time slots are a collection, it’s only accessible from within a poll.
I could maybe use something like an array instead of a relation, but the logic would be pretty complex : I can vote/un-vote on a time slot and keep a list of voters.
The alternative would be :
a form screen to create the new poll, but not the options
then I open a view
then add time slots
Which is a bit cumbersome.
For most users, time slots are an attribute of a Poll and should be in the initial form
I’ve already tried to work around it with :
add a new row in Polls with a temp unique id
open automatically the new Poll in a detail view to fill the information and slots
It works, but I have the quota consumption issue.
A last option would be to do some kind of stepper.
I could maybe override the submit button on the intial form to display a view to add / edit time slots.
When editing a poll, I would have an editing button for the information section.
It felt a bit too complex, but I keep it in mind.
,
