Meteor JS (Part 4): Editing & Input Validation

This is a post in a multiple part series on getting started with Meteor JS. If you don’t have Meteor JS installed you will want to start at  the first post in the series. Part 2 is where we start building the application.

Today we are going to talk about editing items in our price book and about validating the data that is being entered. The UI is still very rough but we will get to it in another post.

In Line Editing

This feature will allow the user to edit an item that has been added. We will add an edit button. When the user clicks the edit button the data will be replaced with inputs. The user can either click save to save the changes or cancel as shown below.


To make this possible we will modify the item template. Then we will add the events and helpers needed to make everything work.

First modify /client/views/items/item.html by replacing it with the following markup.

The lines of code that need to be added have been highlighted. The first thing you should notice is the {{#if editing}} block. We will be creating the editing helper in our JavaScript. When editing is true the editing portion of the item template will be shown. The item’s values will filled in each input.

Adding the following code to /client/views/items/item.js will add the editing helper used in the if block. Also let’s go ahead and add the event for the edit item button.

This brings us to a new concept. Session is a client side, global, reactive dictionary that survives hot code pushes. Session has three methods: get, set, and equals. This means that whenever the Session variable of editItemId changes we will fire off the editing helper function. Our template has a dependency on the editing helper and therefore will update itself. This is what it means to be reactive. We don’t have to do things manually to the DOM to change between a normal and editing states.

Also we are going to add the click event for the edit button. The only thing we need to do is set the session editItemId variable to the current ID. This is all we need to do to get the edit form to show up.

Next, let’s make the Cancel button work by adding the following code to our item.js file.

All we need to do is set the session variable editItemId to null. As soon as this happens the input fields will go away.

Next let’s wire up the save button. First let’s create a method to save the item.

All this function is doing is pulling the values out of the input controls. Then we run an update on the item. After that is done we switch back to a normal view by setting our session variable to null.

Now let’s add the event handler for the save button.

Finally, we are going to wire up a couple of keyboard events. When a user presses enter let’s save the changes and when a user presses escape let’s cancel the changes.

That is pretty much it for editing. Next we will visit input validation.

Input Validation

Right now we are not validating anything. Go ahead and try sending back a word for price. I promise it will work. So we need to add input validation. For this project I have chosen to use a package called collection2. The nice thing about collection2 is that it adds the validation rules to the insert on the client and server. You only have to write the validation rules once.

To install the collection2 package just run the following in a terminal within your project’s directory.

Documentation for collection2 can be found on the project’s github page.

Next we will create SimpleSchema object with the validation rules and then we will attach it to the collection. Add the following code to the /both/collections/items.js

Now we have a schema with our validation rules. Next we need to update our insert and update calls so we will be able to intercept validation errors. Let’s modify our /client/views/items/additem.js file to look like the following.

All we have done is updated the insert method. The new signature takes an object that let’s us name our validation context and a callback to handle the response. As you can see if we don’t find an error we just run the code that was already there.

We need to do the same to the update call, within the saveItem function, in /client/views/items/item.js.

Now let’s create a template that will list our validation errors. This is incredibly easy. Once we have created the template all we will need to do in our additem and itemlist template is add the following.

{{> itemerrors contextName=’name of our context’ }}

Here is the HTML file. /client/views/items/itemerrors.html

There are a couple of things going on here. First, we are looping a helper called errors. Next, we are creating a div with the message text within it. Last, we are setting the class attribute of the div using the contextName parameter that a was passed in. You might be wondering what is up with the ../contextName syntax? An #each block creates a new data context based on the item in the loop. To access parameter contextName we have to use the ../ syntax to access the parent’s data context.

Here is the JS file. /client/views/items/itemerrors.js

We create an errors helper that is going to return a reactive list of error messages. After that, we create the attributes helper that will set the class to include the context name. This will allow us to style all errors or we can be more specific based on the context name.

Next we need to call our errors template within the itemlist and additem templates.




At this point we should have the ability to edit items and validate our insert and update operations. Over the next couple of posts we will visit data security and ui styling. And as always the code from this post is up on Github.

Thanks for stopping by.

Leave a Reply

Your email address will not be published. Required fields are marked *