What is the best way to "React" to "Validation"?

help
1

Which approach to validation is the “best”?

As it stands today the current “most common” ways to approach data validation are the following: Allow/Deny, Simple-Schema/Collection2, Astronomy and possibly MongoDB 3.2 Validation - with a question mark for the last one.

Defining “Best”:

For the purposes of this conversation, best is defined as:

  1. Simple to understand/use
  2. Maintainable
  3. Long-Term Support
  4. Using packages/codebase which is currently being well maintained.
  5. Offers server AND client side validation
  6. Custom error handling (for the user experience)

Concerns about the aforementioned approaches:

Allow/Deny

I have found this method to be confusing in the past, and I have seen other complains which seam to resonate with how I feel about allow/deny. Maybe, however, this is the best way for me to achieve what I’m trying to do - and it is at least well documented and well maintained and I believe will be supported by meteor for a long time.

Simple-Schema/Collection2

Simply put, It’s questionable to me that this package is going to stick around and be maintained well. This is actually why I set out on a different way to achieve my goals in validation for this application I’m building now.

Astronomy

I can’t find a single tutorial on how to use this - and I highly doubt that one exists. Trying to search for something that talks about this lead me to one of those elusive google searches that turned up only 3 results. It also feels “heavy” and seams like it comes from that “I want to do things in meteor, but I love PHP too much to change” perspectives (mentioned in the actual documentation). Even though Eric Dobbertin (AKA Aldeed) said “If this package were around when I created SimpleSchema, I would have used it instead of creating SimpleSchema”.

MongoDB 3.2 Validation?

This actually is my favorite of all of the ways, because it seams to me that the folks over at MongoDB generally know what they are doing, and I feel like a method derived from using this pattern would simply be elegant. However I can’t find a SINGLE mention of anyone actually using this in real development.

If anyone could provide an example on how to use this for validation in meteor, with bonus points in react - I would owe you a beer, or a soda, or whatever your poison is. Heck, I’d buy you dinner.

Help!

For the purpose of this conversation, I’ll also add that right now I’m building a fairly simple application. I want to do a few simple form validations in receiving data as input from users.

Specifically, I need to:

  1. check that a “slug” is unique within the collection so that I can use it as a reliable identifier.
  2. check word/character count limits.

I do need to make sure these checks happen both server and client side. I also expect this list to grow in the future and become more complicated as the application grows.

Also, note that I am using React, and React-Router on the front end of things here.

Any input on these topics is welcomed. After doing all of this research today I’m feeling kind of lost as to the best way to approach this. And if you’ve read this far - thanks for your time and attention.

2

As for your uniqueness requirement: You can circumvent that and simply use GUIDs. If you’re creating those properly you may get a collision before the heat death of the universe. You merely have to use a good random number generator.

1 Like
3

@rhywden Thank you so much for your response. Those look great!

Unfortunately for this project the url pattern I would like to use is something like

thissite.com/something-user-friendly/with-something-else-logical-after-it

Such that people can actually read the URL, and it make sense.

Certainly “38ef8ffc-2573-a4f8-0c4a-6256db462270” would serve the purpose of being unique, but it’s not really human readable. “No no, I mean’t 2574 in the second set of randomness”

I’ll file this way for the future though, and use it for something else, thank you!

4

Well, since you cannot lock a MongoDB collection, you can’t really reliably check for uniqueness.

You can only hope that between your query and the insert no one else comes first.

1 Like
5

@rhywden truth, but if I’m checking every time somebody interacts with that database, and this application is the only thing interfacing with said database, I feel like I have good hopes that I won’t have a problem. Is my thinking correct here?

Server Side Validation - for to protect the database.

Client Side Validation - what so that we can have a nice user experience “Hey, you idiot, this slug already exists”. (Maybe said in a nicer way)

6

I’m not sure, however, how useful human-readable URIs beyond the toplevel (i.e. “edit”, “articles”, etc) really are.

You do know that you can use both?

7

They are a requirement of the build from my client. And they make sense as this is a sort of “blog” where people should be able to type the url in themselves. Take a look at the forum we’re using right now for example. “/what-is-the-best-way-to-react-to-validation/” I’m interested in having something that looks just like this - for the same reasons.

8

That’s not the id, however, and actually irrelevant.

Try it out. Change only the URI part where it says “what-is-the-best-way-to-react-to-validation” and press enter.

You’ll end up here again.

9

@rhywden I never claimed it was the ID - the point is that it’s stored in the URL so that people can find it easily through typing - if you just remember a few keywords you can get back to where you wanted to go. Anyways - thank you for all of your comments. I’m not interested in debating this further.

10

If anyone else has comments on the actual question at hand, it would be greatly appreciated.

11

Well, sorry if I’m telling you that having to type in your URIs by hand is … a sub-optimal UX. Again, you can have both - but the human-readable part doesn’t and shouldn’t matter.

12

The check package is good : https://docs.meteor.com/api/check.html, and there’s some new es6 features that make checking types a bit easier, e.g. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isInteger

For checking things like unique-ness, personally I put that logic in a meteor method on the server and return a custom error or response to the client. Simple Schema has some features that cover that case, but I think it’s just as easy to write your own method.

On the client using Meteor reactive vars is a great way to give user feedback for validation errors, you can put most of that logic inline in your html template which is nice. I never really found a client library that made form validation UI easier than just using normal Blaze style of coding.

13

@looshi - I think you’re right. I’ve thought a lot about this issue over the past few days and I think I’m going to have to use check and Match (as you suggested) for maximum effectivity.

Also, to note - it looks like Simple-Schema is perfectly fine as far as “maintenance” is concerned. Eric (aldeed) came online today announcing his version 2.0 of simple-schema.

He’s putting all of his new logic into a generic npm package and then releasing a new simple-schema 2.0 atmosphere package which will wrap the generic package injecting reactivity where needed. I think this is the right way to go for sure.

It sounds like aldeed saved the day again. What a great guy - we all owe him a beer or coke (or whatever) IMHO.