Quota count when editing in detail view

Hi there :wave:,

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 for your help!

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 :

It’s seems to work when I create a form container though.
Looks strange to me, maybe a bug ?

I can’t add a row to a form container
Also, if I delete a reference from a form, it closes my form.

So the first video with the “Add” button doesn’t actually submit any rows to your data? If so, it would be considered a bug.

That’s right.
I wondered if that was a limitation, but the behavior is strange indeed and very confusing.

Please submit a ticket here.


Done, thanks

1 Like

Closing the loop here.

After a pretty long discussion, Glide’s support decided it wasn’t a bug :cry:

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

So that “Add” button you show in the first video actually is an edit screen, not a form screen?

If that’s the case, why don’t you use a form screen instead? It will also only count 1 against your quota.

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.

However, it seems that if I open the form in “main” instead of a modal, the “Thing” is created :thinking:

So your form screen is placed inside an edit screen?

Yes, so I can add new Things from here.

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.

1 Like

Let’s take a popular app like Doodle :

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.