♊️ GemiNews 🗞️

Demo 1: Embeddings + Recommendation Demo 2: Bella RAGa Demo 3: NewRetriever Demo 4: Assistant function calling

🗞️Validating Forms in Semantic UI React

🗿Semantically Similar Articles (by :title_embedding)

Validating Forms in Semantic UI React

2018-07-09 - Kevin Randles (from Kevin Randles on Medium)

I’ve been working recently on fleshing out the app I built for my final project at Flatiron School, and thought I’d share some of what I learned over the last few days while adding validation to the forms that make up a significant part of this app. In order to build the initial version of this app in a relatively short time, I used the React version of Semantic UI, which provided me with clean, responsive styling without having to put too much time into rolling my own CSS. Unlike the original jQuery-based version of Semantic UI, which has built-in form validation support, Semantic UI React requires you to write your own validation methods — thankfully, this isn’t particularly difficult.After a little bit of Googling, I found this great answer at Stack Overflow that got me pointed in the right direction, and got started with the part of my app that every user will encounter first, the new user signup form.My first step was to add a disabled prop to the submit button, which checks to make sure that all of the required fields (in this case, all of them) are filled out with some value, valid or not, before enabling the button — most of the validation will be carried out when a user attempts to submit the form.This simply checks the part of the form’s state that corresponds to each field, and returns a boolean value of false, thereby enabling the button, when all of the fields are filled.Next, I added a bunch of new key-value pairs to the forms initial state, all set to false, to keep track of any errors that come up when attempting to submit the form.Then, on each individual form field, I added an error prop, checking for the errors which apply to that field, which will put the field into an error state if the entered data is invalid.All pretty straightforward so far, right? But where the real work gets done is in the method that handles submitting the form to the back end. This method is about 80 lines long right now, so I’ll spare you the wall of code and just cover the basics of what I had to add to the existing method.First, I declared an “error” variable, set to false, that will track the global error state of the form — if any errors are found this will be set to true, and prevent submission of invalid data to the back end (I’ll show the code that manages this down below).Then, for each possible error I want to check for, I wrote an if/else statement. The examples above check for the presence of a value in the email field (this should, ideally, also be checking to make sure that it’s in a valid email format-TODO: find a regExp that does that), and that the entered password is at least 8 characters long. I’ve got another half dozen or so of these, checking that the password and confirm password fields match, that the entered ZIP code is a 5-digit number, etc., etc.After all of the validation checks are complete, we check to see if “error” has been set to true. If it has, we set formError in our state to true, then “return” to end execution of the method — the return here is critical, as it prevents the rest of the handleSubmit method from executing, and submitting what we already know to be invalid data to the back end. If no errors were found, we set formError to false, and continue with creating the new user account.We’re almost finished here, but there’s one potential case that could, even if everything looks correct, prevent our new user from being created, that we can’t account for until we actually attempt to create the new user— what if the user already has an account?I won’t go fully into how I implemented checking for this, as it involved adding some code to my reducer and my API call for creating a user (and the way I implemented it feels a little hack-y, if I’m being completely honest-but it does the job for now). Essentially, if the server’s response to the POST request is an error, instead of the expected JSON object, (and because I’ve implemented robust validation to make sure no potentially invalid data will be submitted) the action returned by our reducer will not contain a payload, so I check for this like so:I have one final bit of code to show here, which deals with providing detailed feedback to the user about what they’ve done wrong.I’ve added a ternary statement here which renders an error message on the form if createUserError is true.And so, there you have it…relatively comprehensive validation on a Semantic UI React form. This still needs some work, in order to provide more detailed feedback on other error cases, but I need to refactor my form layout to comfortably fit multiple error messages on screen (TODO: one more thing on a really long list), and it isn’t really comprehensive without server side validation as well, which I wrote about implementing in Rails here a few months back.

[Technology] 🌎 https://medium.com/@krandles/validating-forms-in-semantic-ui-react-a057957f1dd6?source=rss-d451d084d34a------2

🗿article.to_s

------------------------------
Title: Validating Forms in Semantic UI React
[content]
I’ve been working recently on fleshing out the app I built for my final project at Flatiron School, and thought I’d share some of what I learned over the last few days while adding validation to the forms that make up a significant part of this app. In order to build the initial version of this app in a relatively short time, I used the React version of Semantic UI, which provided me with clean, responsive styling without having to put too much time into rolling my own CSS. Unlike the original jQuery-based version of Semantic UI, which has built-in form validation support, Semantic UI React requires you to write your own validation methods — thankfully, this isn’t particularly difficult.After a little bit of Googling, I found this great answer at Stack Overflow that got me pointed in the right direction, and got started with the part of my app that every user will encounter first, the new user signup form.My first step was to add a disabled prop to the submit button, which checks to make sure that all of the required fields (in this case, all of them) are filled out with some value, valid or not, before enabling the button — most of the validation will be carried out when a user attempts to submit the form.This simply checks the part of the form’s state that corresponds to each field, and returns a boolean value of false, thereby enabling the button, when all of the fields are filled.Next, I added a bunch of new key-value pairs to the forms initial state, all set to false, to keep track of any errors that come up when attempting to submit the form.Then, on each individual form field, I added an error prop, checking for the errors which apply to that field, which will put the field into an error state if the entered data is invalid.All pretty straightforward so far, right? But where the real work gets done is in the method that handles submitting the form to the back end. This method is about 80 lines long right now, so I’ll spare you the wall of code and just cover the basics of what I had to add to the existing method.First, I declared an “error” variable, set to false, that will track the global error state of the form — if any errors are found this will be set to true, and prevent submission of invalid data to the back end (I’ll show the code that manages this down below).Then, for each possible error I want to check for, I wrote an if/else statement. The examples above check for the presence of a value in the email field (this should, ideally, also be checking to make sure that it’s in a valid email format-TODO: find a regExp that does that), and that the entered password is at least 8 characters long. I’ve got another half dozen or so of these, checking that the password and confirm password fields match, that the entered ZIP code is a 5-digit number, etc., etc.After all of the validation checks are complete, we check to see if “error” has been set to true. If it has, we set formError in our state to true, then “return” to end execution of the method — the return here is critical, as it prevents the rest of the handleSubmit method from executing, and submitting what we already know to be invalid data to the back end. If no errors were found, we set formError to false, and continue with creating the new user account.We’re almost finished here, but there’s one potential case that could, even if everything looks correct, prevent our new user from being created, that we can’t account for until we actually attempt to create the new user— what if the user already has an account?I won’t go fully into how I implemented checking for this, as it involved adding some code to my reducer and my API call for creating a user (and the way I implemented it feels a little hack-y, if I’m being completely honest-but it does the job for now). Essentially, if the server’s response to the POST request is an error, instead of the expected JSON object, (and because I’ve implemented robust validation to make sure no potentially invalid data will be submitted) the action returned by our reducer will not contain a payload, so I check for this like so:I have one final bit of code to show here, which deals with providing detailed feedback to the user about what they’ve done wrong.I’ve added a ternary statement here which renders an error message on the form if createUserError is true.And so, there you have it…relatively comprehensive validation on a Semantic UI React form. This still needs some work, in order to provide more detailed feedback on other error cases, but I need to refactor my form layout to comfortably fit multiple error messages on screen (TODO: one more thing on a really long list), and it isn’t really comprehensive without server side validation as well, which I wrote about implementing in Rails here a few months back.
[/content]

Author: Kevin Randles
PublishedDate: 2018-07-09
Category: Technology
NewsPaper: Kevin Randles on Medium
Tags: javascript, semantic-ui, react
{"id"=>3145,
"title"=>"Validating Forms in Semantic UI React",
"summary"=>nil,
"content"=>"

I’ve been working recently on fleshing out the app I built for my final project at Flatiron School, and thought I’d share some of what I learned over the last few days while adding validation to the forms that make up a significant part of this app. In order to build the initial version of this app in a relatively short time, I used the React version of Semantic UI, which provided me with clean, responsive styling without having to put too much time into rolling my own CSS. Unlike the original jQuery-based version of Semantic UI, which has built-in form validation support, Semantic UI React requires you to write your own validation methods — thankfully, this isn’t particularly difficult.

After a little bit of Googling, I found this great answer at Stack Overflow that got me pointed in the right direction, and got started with the part of my app that every user will encounter first, the new user signup form.

\"\"

My first step was to add a disabled prop to the submit button, which checks to make sure that all of the required fields (in this case, all of them) are filled out with some value, valid or not, before enabling the button — most of the validation will be carried out when a user attempts to submit the form.

\"\"

This simply checks the part of the form’s state that corresponds to each field, and returns a boolean value of false, thereby enabling the button, when all of the fields are filled.

Next, I added a bunch of new key-value pairs to the forms initial state, all set to false, to keep track of any errors that come up when attempting to submit the form.

\"\"

Then, on each individual form field, I added an error prop, checking for the errors which apply to that field, which will put the field into an error state if the entered data is invalid.

\"\"

All pretty straightforward so far, right? But where the real work gets done is in the method that handles submitting the form to the back end. This method is about 80 lines long right now, so I’ll spare you the wall of code and just cover the basics of what I had to add to the existing method.

\"\"

First, I declared an “error” variable, set to false, that will track the global error state of the form — if any errors are found this will be set to true, and prevent submission of invalid data to the back end (I’ll show the code that manages this down below).

Then, for each possible error I want to check for, I wrote an if/else statement. The examples above check for the presence of a value in the email field (this should, ideally, also be checking to make sure that it’s in a valid email format-TODO: find a regExp that does that), and that the entered password is at least 8 characters long. I’ve got another half dozen or so of these, checking that the password and confirm password fields match, that the entered ZIP code is a 5-digit number, etc., etc.

\"\"

After all of the validation checks are complete, we check to see if “error” has been set to true. If it has, we set formError in our state to true, then “return” to end execution of the method — the return here is critical, as it prevents the rest of the handleSubmit method from executing, and submitting what we already know to be invalid data to the back end. If no errors were found, we set formError to false, and continue with creating the new user account.

We’re almost finished here, but there’s one potential case that could, even if everything looks correct, prevent our new user from being created, that we can’t account for until we actually attempt to create the new user— what if the user already has an account?

I won’t go fully into how I implemented checking for this, as it involved adding some code to my reducer and my API call for creating a user (and the way I implemented it feels a little hack-y, if I’m being completely honest-but it does the job for now). Essentially, if the server’s response to the POST request is an error, instead of the expected JSON object, (and because I’ve implemented robust validation to make sure no potentially invalid data will be submitted) the action returned by our reducer will not contain a payload, so I check for this like so:

\"\"

I have one final bit of code to show here, which deals with providing detailed feedback to the user about what they’ve done wrong.

\"\"

I’ve added a ternary statement here which renders an error message on the form if createUserError is true.

\"\"

And so, there you have it…relatively comprehensive validation on a Semantic UI React form. This still needs some work, in order to provide more detailed feedback on other error cases, but I need to refactor my form layout to comfortably fit multiple error messages on screen (TODO: one more thing on a really long list), and it isn’t really comprehensive without server side validation as well, which I wrote about implementing in Rails here a few months back.

\"\"",
"author"=>"Kevin Randles",
"link"=>"https://medium.com/@krandles/validating-forms-in-semantic-ui-react-a057957f1dd6?source=rss-d451d084d34a------2",
"published_date"=>Mon, 09 Jul 2018 03:44:42.000000000 UTC +00:00,
"image_url"=>nil,
"feed_url"=>"https://medium.com/@krandles/validating-forms-in-semantic-ui-react-a057957f1dd6?source=rss-d451d084d34a------2",
"language"=>nil,
"active"=>true,
"ricc_source"=>"feedjira::v1",
"created_at"=>Wed, 03 Apr 2024 14:31:18.199335000 UTC +00:00,
"updated_at"=>Mon, 13 May 2024 18:48:07.624643000 UTC +00:00,
"newspaper"=>"Kevin Randles on Medium",
"macro_region"=>"Technology"}
Edit this article
Back to articles