In the last post, I showed you how to export WebGrid results to CSV. This week, we reply to a reader's question as how to perform a lazy load on a WebGrid.
For those who aren't familiar with a lazy-load, a lazy-load is a process that is more ad-hoc (records pulled upon request) that all at once and displayed without paging.
Google+ and Pinterest users should be familiar with this type of retrieving records. As you scroll further down the list, a new set of records appear. It's almost considered a never ending list of content (Has anyone EVER seen the footer of Facebook?)
Today, we get into a WebGrid that can have a large supply of users, but we are only displaying 5 users at a time.
Benefits: Why do this?
Why would we implement such a feature into a Web Grid?
Minimal amount of bandwidth
Quicker access pulling smaller records (easier to pull 5 than 500)
Depending on how you display your records and if it's a sort by relevance, there's no need to go to page 2 or 3, meaning you are saving CPU cycles by not requesting another page of data. Ask Google!
Of course, we could also include paging as a lazy-loading technique which would accomplish the same thing, but as I said in the first WebGrid Series post, I want to push the limits and show all of the crazy things we can do with a WebGrid to impress our users.
Overview
For those wondering how to do this, the only way to load the records without doing a postback is to implement AJAX with jQuery. We definitely don't want to interrupt the user's experience with a hard postback.
First, we need to focus our efforts on the initial display of records in the WebGrid. The two immediate pieces of code that stand out are the UserRepository and the UserController.
In the UserController, we need to make sure we can display the first set of records with paging. So we replace this:
with this:
If you wanted to, you can even remove the page parameter and hard-code a '1' into the GetPagedUsers method so the user doesn't page ahead.
Next (and it should be obvious) is the UserRepository. We need to create a paging method and adjust our interface.
Our interface now looks like this:
and we add our implementation of the method in UserRepository.
For demo purposes, I'm using a quick paging technique for Entity Framework (Notice the OrderBy? It has to be there for the Skip to work).
Web API or SignalR?
You may be wondering if we aren't doing a postback with ASP.NET MVC, then how do we get the data?
Ahhh, the joys of being a developer...so many choices.
There are two choices: Web API or SignalR.
While Web API is not new, it is in the latest version of ASP.NET MVC. In vNext, Microsoft combined MVC, Web API, Bootstrap, and ASP.NET Identity and are calling it One ASP.NET.
SignalR is another library that I've grown quite fond of since Codemash 2012. SignalR is a two-way communication library that uses Web Sockets. When one client sends a request back to the server, the server acts on it and then optionally broadcasts actions to the every client that is connected. If you want to see an example of SignalR, check out this post about making your own real-time like button.
Both are viable solutions and it depends on your use.
Use WebAPI if:
You have other pieces of code that will call this API (code reuse)
The ultimate decoupling of components (make a web call and you get data)
You want to create Single Page Applications (no postback required)
Use SignalR if:
You are using a more coupled architecture (it can't be a separate library)
You require a real-time application where everyone connected has to be notified of events (100,000 simultaneous connections can be achieved)
You want to create Single Page Applications (yes, I said it again)
Today, I will show you how to use the Web API in your WebGrid and then focus on SignalR later in the week.
Web API Implementation
After creating a new item (under Add Item -> Web API Controller Class (v2.1)) called UserController.cs, we get our template.
api\UserController.cs
Ok, notice the GetPaging? We'll be renaming that method signature and adding our own return values. But before we do that, we need to make a couple of modifications to this project.
Add a reference to System.Web.Http.WebHost
Add App_Start\WebApiConfig.cs
Call WebApiConfig.Register(GlobalConfiguraton.Configuration) in your Application_Start() in file Global.asax.cs
Because we are adding this Web API to an existing project, we need to include some modifications to our output. Let's remove the XML returned from the WebAPI.
And finally, we need to set the JSON serialization settings for our User object or else we get some wierd "K__BackingField" issues returned to our browser.
Let's finish up our UserApi Controller.
The finished template looks like this:
A lot of work for something so small, huh?
Now, when you run the app, you should be able to type:
and receive records in JSON.
Let's head to the client and finish the job.
Working the Client with jQuery
The client side should be relatively easy since we just need to plug in an AJAX call to our new Web API service and we already have a JavaScript file already started in our User\Index.cshtml View.
But we seem to have a problem with our thinking. How do we keep track of what page we're on when we're ready to make a call to the server? We can use the number of rows displayed to calculate the page number.
Here is our updated JavaScript:
Let's go through the moreButton click.
To calculate the next page, we take the list of TR elements in the body and divide it by the page size which we set to 5 in the previous line and then add 1 to request the next page.
After the calculation, we create a row template. This template has the very basics of our row without data included but with CSS formatting.
Next, we execute the Web API GetPaging method and get our JSON User records back. If we receive ANY user records, we populate the WebGrid. If we don't receive any records, we replace the Load More button with an alert that says "No More Records."
Conclusion
In today's post, we went over how to perform lazy loading in a WebGrid using the Web API and jQuery to achieve quick loading results to your WebGrid.
This makes the user's experience even better because they don't have to wait for a huge HTML View to return. They just wait for data to return and the browser takes care of the REST (Get it?) ;-)
If you have any question regarding how to implement something in a WebGrid, don't hesitate to comment.
Series: Enhancing the WebGrid
Introduction
Batch Processing
Export Data To Excel
Export Data To CSV
Lazy Loading with Web API
Lazy Loading with SignalR