newsletter monthly

Community feedback

• 

  P

  Fluffy Kas•7,695

  @FluffyKasPosted about 1 year ago

  Hey there,

  There are a few problems with your code but the main issue that's causing this behaviour is where you placed your preventDefault:

  btnOne.addEventListener('click', function (e) {
    errorMessage.innerHTML = '';
    if (!emailRe.test(email.value)) {
      e.preventDefault();
      errorMessage.innerHTML = 'valid email required';
      email.style.borderColor = 'hsl(4, 100%, 67%)';
      email.style.color = 'hsl(4, 100%, 67%)';
      email.style.backgroundColor = 'hsl(4, 100%, 90%)';
    } else {
      container.classList.add('hidden');
      subscribing.classList.add('show');
    }
  });
  

  So preventDefault will only trigger if the regex test fails. Really, it should be always triggered, no matter the test outcome:

  btnOne.addEventListener('click', function (e) {
    errorMessage.innerHTML = '';
    e.preventDefault();
    if (!emailRe.test(email.value)) {
      errorMessage.innerHTML = 'valid email required';
      email.style.borderColor = 'hsl(4, 100%, 67%)';
      email.style.color = 'hsl(4, 100%, 67%)';
      email.style.backgroundColor = 'hsl(4, 100%, 90%)';
    } else {
      container.classList.add('hidden');
      subscribing.classList.add('show');
    }
  });
  

  You should read the MDN article about preventDefault but basically the problem is the following:

  The default behaviour of any form would be to trigger an action (defined by the action attribute in your html) and make a call to the backend. This action would take a pre-defined route to create, update, etc the database with the data within the form. It's all defined in the backend. Validation checks would also happen in the backend. Depending on what framework you're using, you can catch these validation error messages and display them on the frontend.

  What we're doing in these purely frontend challenges is something different. What we want is to prevent this default behaviour, no matter what, as we have no backend to call. We don't define an action (you can remove the action attr entirely from the html), we just add an eventListener and first we always specify that we don't want the default behaviour (see second code snippet). After this, we can play around however we see fit, implement frontend-only validation checks, apply classes, etc.

  What I described here is obviously a basic scenario, backend isn't always called by the action, there are more "controlled" methods to do that depending on the framework but you'll see that once you try React, Vue, etc.

  Hope the explanation was clear enough, if not ask away.

  There are a few other problems with the code that might cause bugs in the future. I keep it simple because this feedback is getting long already :D

  CSS specificity: I'm sure you've heard of this. We always want to keep specificity as low as possible. Consider the following:

  .information {
    padding: 3rem;
  }
  
   /* INSTEAD OF THIS: */
  
  main .container .information {
    padding: 3rem;
  }
  

  The 2 selectors do the same thing, but the first one has a lower specificity. Higher specificity can lead to unexpected behaviour (like, if you didn't use main .show class but just .show class, it wouldn't overwrite the original CSS rules which had a higher specificity).

  Also, your hidden and show classes don't ever get removed by the JS. If you go back to the main card from the success card, you can see that it has a show AND a hidden class as well. For now this isn't causing bugs, but it could. It's best to add rules to remove them when they are no longer needed.

  Hope this was helpful. Good luck!

  Marked as helpful

  2
• 

  Mohammed Elkharadly•550

  @Mohammed-ElkharadlyPosted about 1 year ago

  I have modified it, please take a look

  0