It's strange this doesn't support plain nosql databases. I'm not sure I see the value in a full blown relational setup for... form submissions.
Form to DB
71–80 of 129 posts
Re: Form to DB
#72Earlier quoted context omitted.
Let me tell you something about this fancy HTML tag you are talking about. It has an "action" attribute that points to a server you need to own and run a code you need to code in order to validate the input and store it in the database. If you are comfortable doing this, which no doubt you are, then you are not the target audience of this tool.
> It has an "action" attribute that points to a server you need to own and run a code you need to code in order to validate the input and store it in the database Pure-HTML forms work exactly like React forms; React does the lifting but it doesn’t change anything to the fact that the data eventually needs to be sent to a server to be stored in the database.
> Pure-HTML forms work exactly like React forms
This should probably read "React forms work exactly like pur-HTML forms" seeing as HTML came first and react ultimately spits out either an HTML form or a form request.
The original point still remains though, reaching for react just for forms is really heavy handed. It works fine if everything on the site is react already, though that's an assumption that I wouldn't make and that I hope will die soon enough if devs finally start moving away from massive react apps.
Re: Form to DB
#73Earlier quoted context omitted.
Because it is. It can be very frustrating not to be able to fill a form on mobile with a 3G connection just because some random dev decided that downloading 150kb of JS to render a simple form is fine. I mean it’s a form; we already have all the HTML elements already; why do you need React for? This is why nowadays we end up with Electron apps that take 6GB of RAM to display a chat.
It's really not that simple. What about complex validation rules? Do you really think it's user friendly to require them to send the whole form just to tell them "sorry no" 10 times over until they get it right? What about multi-value selects, potentially with rules? E.g. form field like "choose up to 5 locations in the radius of 10km". What about form fields like "pick a point on a map"? Etc. Don't act like every fo…
React isn't required for client-side validation or non-spec form inputs.
Doing form validation in event handlers for DOM events works very well, and a simple script tag or custom element is all that's needed to build a multi-value select.
Re: Form to DB
#74These types of projects always remind me of MS Access. Access is forms on a database, and really easy to use. It obviously has its drawbacks but nothing has come close to it. I've never understood why MS didn't capitalise on it by extending and improving it.
I never saw an Access database that didn't become a regretful mess after a couple of years - the person that made it left, no-one knew how to update it. Fancy validation built into the form that just got in the way when requirements changed.
Thus I came to the conclusion that any Access database is probably better off being a spreadsheet, even with all the chaos that not having forms as a front end and not having relational structure entails. At least people can understand other peoples spreadsheets (up to a point)
Re: Form to DB
#75Earlier quoted context omitted.
So, you didn’t feel comfortable relying on “another SaaS” app, and then go on to suggest Retool Workflows, which is itself part of another paid SaaS app? All those “shoddy” alternatives also have free tiers.
Not sure that is fair? The difference seems to be the data is squarely in your own DB. You can use their SaaS for validation. You might pay for something (surprise?).
It would be pulling in another SaaS, what isn't fair?
It actually sounds like an interesting service in my opinion, but it is another SaaS that is giving me an API for a form handler that I could otherwise host myself.
Personally I wouldn't see the use case of using your own DB as helpful, if you already have your own database the odds that you aren't hosting APIs as well seems low.
Re: Form to DB
#76Earlier quoted context omitted.
It's really not that simple. What about complex validation rules? Do you really think it's user friendly to require them to send the whole form just to tell them "sorry no" 10 times over until they get it right? What about multi-value selects, potentially with rules? E.g. form field like "choose up to 5 locations in the radius of 10km". What about form fields like "pick a point on a map"? Etc. Don't act like every fo…
Doing validation in the frontend is a bad idea. You'll have to do in the server, if you're sane. I bet Retool Forms does in the server. You're worried the page will refresh with an empty form, if it fails. It's simple, just collect the data and return the form pre-filled using the value attribute, along with the error message. If you don't want to refresh the page, you could even use something like htmx, which is a L…
Of course you have to validate on the server. That's a given, always.
But you want to provide better UX to the user.
Htmx is not simpler than React. I can't deploy that without a server that knows everything about the frontend. React allows me to decouple. Templates are hell. I lived in it for many years, never again.
Re: Form to DB
#77These types of projects always remind me of MS Access. Access is forms on a database, and really easy to use. It obviously has its drawbacks but nothing has come close to it. I've never understood why MS didn't capitalise on it by extending and improving it.
Because the single-system paradigm doesn't work any more. However, modern replacements do exist, Airtable is one of the first; it's basically the notion of a "spreadsheet with more structure", and then building forms and such on top of that. I've recently been playing with Grist and like it, although it is rough around the edges. https://www.getgrist.com
I love Grist, and relevant to this discussion, it now has forms: https://www.getgrist.com/forms/
Grist is open source, Python scriptable and each project is stored in a SQLite database.
Re: Form to DB
#78Earlier quoted context omitted.
It's really not that simple. What about complex validation rules? Do you really think it's user friendly to require them to send the whole form just to tell them "sorry no" 10 times over until they get it right? What about multi-value selects, potentially with rules? E.g. form field like "choose up to 5 locations in the radius of 10km". What about form fields like "pick a point on a map"? Etc. Don't act like every fo…
React isn't required for client-side validation or non-spec form inputs. Doing form validation in event handlers for DOM events works very well, and a simple script tag or custom element is all that's needed to build a multi-value select.
It's not simple. I made multi-page forms with dozens fields where your suggestion would lead to intangible mess of spaghetti code - I know because I worked with the web way before React. Even with the best coding standards and a team of seniors it's just too hard to maintain - and seniors usually don't write forms.
I really don't want to go back to the jQuery days. You do you, but don't say it's easier - it really isn't.
BTW you can just use Preact if you're worried about the bundle size. I do that, it's perfect and just a little performance impact, usually not visible in small apps.
Re: Form to DB
#79How new is this Retool product? The idea that OpenAI, Amazon, NBC, Mercedes, and Doordash all use it seems dubious.
Re: Form to DB
#80Earlier quoted context omitted.
React isn't required for client-side validation or non-spec form inputs. Doing form validation in event handlers for DOM events works very well, and a simple script tag or custom element is all that's needed to build a multi-value select.
It's not simple. I made multi-page forms with dozens fields where your suggestion would lead to intangible mess of spaghetti code - I know because I worked with the web way before React. Even with the best coding standards and a team of seniors it's just too hard to maintain - and seniors usually don't write forms. I really don't want to go back to the jQuery days. You do you, but don't say it's easier - it really is…
Oh that's interesting, multi-page forms are actually my least favorite form use case for react.
I reach for a state machine whenever possible to manage the complex flow of the multi-page or multi-step form, even if react is still used for custom inputs.