Hi
Here is my use case: I have a form and a table on the same page. That page has a recordId (which is used for a hidden field in the form and a conditional filter in the table)
The form pulls data in the table. Everything is well set up. Nothing fancy
The only (annoying) problem is that I want the new record to show up directly in the table below.
A way to do it is to use the “open page” option of the form. Except that it doesn’t take the right recordID of the page, it just reloads the primary url slug and so, the conditional filters of the table are not taken in count… Everything is a mess at the end.
Any solution ?? (I mean, before forms2.0 release)
I know this has been asked a lot, even by myself… But I’m very stubborn on that specific issue
I think the root of the problem is that today there is no way for the browser to get the recordId of the Airtable record that has just been created as a result of the form submission. I spent some time a while back trying to figure out a hack, and came up empty.
@dcoletta And let’s say the recordId already exists? As in my use case I want to use the “open page” option of the form to reload the current page… which has already a known recordId.
I want to reload the page with a slug which won’t have the recordId of the new record… But the existing recordId of the page where the form is.
I thought that way it could work , kind of a workaround that wouldn’t have to take in count the newly recordId but an existing recordId (the one of the page where the form is)
Because if I do it manually = I fill out the form, I click on the submission button. I choose the option “show message” (so, no reload). Then I reload my page myself = the newly created record appears in the table.
OK, I think maybe I misunderstood. You just want the current page to reload with its existing record id, you don’t need to get the record id of the newly created record?
Exactly, David! As the newly created recordId will appear in a table where the conditional filter is set with the current page recordId (Well at least, this is my use case. for UX purpose, I just don’t want the users to click on their browser reload button each time they create a new record, in order to show this record in the table or list below).
Here is a screenshot with the form and table below. What is submitted in the form goes to this table:
OK, this is a more tractable problem. The problem now is, what should this page do when it is loaded with out a recordId parameter. So if there were a way to stash the record id that the page had been previously opened with, and then recover it in the case where the page is loaded without a recordId parameter, then we’d be closer to a solution. Good so far?
Yes.
Well, in most of the cases, this page should always have a recordId…
But I noticed that if the user opens a page too fast, sometimes the recordId is not taken…
And in my case, yes, you will always, always arrive on that page by passing by an other page that has the same recordId.
Let me show you how looks the app because it’s pretty complex
Have you tried a hack where, when the page loads with a recordId on the URL, you save that recordId somewhere, and then when the page subsequently loads without a recordId on the URL, you add the saved recordId to the URL and do a location.replace() with the new URL?
There are a few different ways to stash that recordId but for ease of hacking I’d suggest storing it in a cookie.
EDIT: just in case it’s not clear, you would also need to set the form so that upon successful submission it reloads the current page. That reload will omit the recordId parameter but then you’ll immediately restore it with the above hack.
Fair enough, I think you have told me this before and I just forgot because you are so expert in other areas!
Here is some raw material you could crib from.
This tip has some of the code you would need in order to implement what I’m suggesting. Use the getCookie and setCookie functions to save and restore the record id.
And this tip is basically doing the same thing you want to do except it uses a hard-coded record id instead of one loaded from a cookie.
Between the two of these code snippets I think you have everything you need.
Well, I didn’t figure out how to solve it. Complete fail . My level is too poor and I am really not comfortable with custom code.
Just good to find UX improvements when I have a polished one.
I absolutely need to get more serious with this book… and finding the time to do so.
So, at the end, my use case would be even easier: after a form is submitted, just reload the current page with the correct recordId.
The case where there wouldn’t be a recordId won’t be treated, as it’s almost impossible. (And if it happens, well, I will figure out later).
@artur or @dcoletta , if you have a solution that wouldn’t take you too much time … That would be a great use case before forms 2.0 as many people would find a workaround to display the newly created record not inside an other page but inside the same page.
@matthieu_chateau@dcoletta here to help. Checked the video. Have you tried to have open page on form submit and put the same page url. Lately we added a code to preserve the recordId if the same page is used on form submit is used.
@artur Yes!
But here is the problem: The hide/show custom code is trigerred by a button. But when a user clicks on a button… it instantly reloads the page.
So I had to find a workaround: I added an action for this button to scroll to a section (the exact section where the buttons is, aka a CTA. That way, what’s going on is almost invisible for the user).
But what happens next… the “open page on form submit” effectively reloads the url path… with the recordId … but also with the #section… As a result = no reload. Logic.
That’s why I added in “bug reports” section of the community the fact that buttons without any action shouldn’t reload the current page, or anything else, but should be totally inactive (but visible).
That way, I would have been able to trigger the hide/show custom code, without adding a #section at the end of the url path…
As it is not the case, I tried to use this tip and re-arrange it in order to cut the #section part of the url, when the page is reloaded.
One last video to explain the whole process in details to have, at the end, a nice and neat hide/show behaviour for UX purpose (or, at least, what it should be)
, kind of a workaround that wouldn’t have to take in count the newly recordId but an existing recordId (the one of the page where the form is)
… That would be a great use case before forms 2.0 as many people would find a workaround to display the newly created record not inside an other page but inside the same page.