Aurelia slickGrid query structure

I did manage to get slick grid going with a basic call in “aysnc attached” which worked however I wanted to implement pagination…

I understand that the structure in the viewmodel is as follows:

defineGrid() {

Grid options as follows…

this.gridOptions = {
  enableAutoResize: true,
  autoResize: {
    containerId: 'demo-container',
    sidePadding: 15
  enableCellNavigation: true,
  enableFiltering: true,
  enableCheckboxSelector: true,
  enableRowSelection: true,
  pagination: {
    pageSizes: [10, 15, 20, 25, 30, 40, 50, 75, 100],
    pageSize: defaultPageSize,
    totalItems: 0
  backendServiceApi: {
    service: new GridOdataService(),
    preProcess: () => this.displaySpinner(true),
    process: (query) => this.getCustomerApiCall(query),
    postProcess: (response) => {
      this.statistics = response.statistics;

Its here that I loose understanding… I am using a fetch and I can structure the return viewmodel anyway I want however I am unsure of the structure of the query that I need to send to the API and what to send back - its signature.

I am also unsure as to what the statistics refers to and finally if I want to include filters into the mix how to do that on the client end?

I have RTFM and its not immediately apparent to me how to structure “query” in the “getCustomerApiCall(query)” function and exactly what to send back etc.

I should preface this by saying, I’ve never used slickGrid. But after looking at the code and examples on the repository, hopefully I can help at least a little.

I will say, it appears that their documentation isn’t exactly “friendly”. slickGrid appears pretty complex and I think your best bet is going to be dissecting the examples.

I will be referencing the following example:
Example 4 HTML
Example 4 Script

Note in the example there is a “mockData” method used to generate the data for the example.

  1. slickGrid doesn’t appear to require any specific structure for your API call or its response, as it shouldn’t. Instead, your .NET Web API route determines its inputs and outputs and you define the shape of the expected data to come out of the call in the columnDefinitions config. See lines 59 - 186 and reference the mockData method for the shape of the example data.

    Their example getCustomerApiCall(query) is really just a method call to make the fetch request. See the OData documentation at the bottom of the Code section.

    If you’re not using OData or GraphQL, it looks like you can omit the backendServiceApi config altogether if you desire and just bind to the dataset as seen in Example 4 HTML line 14.

  2. From what I can tell, Statistics is not required. It appears to be a feature of slickGrid to display performance data if provided.

  3. Filters are defined client-side, in the columnDefinitions config. See lines 69-71 and 76-79, among others. The Filters documentation seems pretty well fleshed out fortunately as it looks to have a lot of functionality built-in.

    There’s no base page for Filters, but that link will take you to the wiki and the other docs can be found below it in the tree on the right.

1 Like

Pagination is not currently available for local dataset (like a JSON dataset coming from Http). I might add it in the future, but it is really low, low, low priority. The reason, is that with local dataset, all the data exist locally in your browser cache anyway, so there’s not much point in adding pagination for it since you won’t save anything in download.

On the other end, the backend service (when using the grid optionbackendServiceApi with the GridOdataService or the GraphqlService), do use pagination simply because they are built with pagination in mind. That is to say, unless you have a backend server with OData (mostly with .Net), then only at that time you would add the backendServiceApi to your grid option. If you’re planning on using something else than OData or GraphQL, you could in theory create your own backendServiceApi (1 guy did it with Angular-Slickgrid with an Oracle DB which uses different querying strings). The process method is a callback which uses the GridOdataService to build the query string, so the query comes from the Service and is what you typically connect to your Http call.
The statistics are simply metadata showing certain statistics of the grid like the size of the dataset, how long it took to get the data, and things like that, maybe the name isn’t too good, I was out of idea at the time on how to name it (if you have a better name, send it over and I might go for a rename).
If you think some of the Wikis can be improved, then please open an issue on the project and I’ll update them with your comments.

When you say

I will say, it appears that their documentation isn’t exactly “friendly”. slickGrid appears pretty complex and I think your best bet is going to be dissecting the examples.

That is kinda sad to see this comment considering that I spent months in doing Wikis for this library. However what you need to know is that Aurelia-Slickgrid is a wrapper of SlickGrid (a core library which uses jQuery), it adds a lot on top of SlickGrid but still has the core lib in mind. The goal of Aurelia-Slickgrid is to make it easy to use SlickGrid within an Aurelia project, for example you can easily add Filters, Editors in Aurelia-Slickgrid while that is all done by hand in SlickGrid itself. It also adds TypeScripts Types, as much as I could, which don’t exist in the all but JS SlickGrid core lib.

I spent months, and still spending quite a lot of time (recently focusing on unit testing), on this library and I’m a single person who is providing this library free and open source (look at my year contribution on GitHub and that should prove how much time was spent). So please be gentle in your comments… oh and I’m the author of Aurelia-Slickgrid if you haven’t noticed already.

1 Like

I’m extremely sorry, I meant no offense, nor claim I could do any better. My intention was to say that Aurelia-Slickgrid/Slickgrid offers a lot of functionality and isn’t as simple as “pop it on a page and watch it go”.

I can say that, unless my answers were completely off-base, I managed to put together those answers without having to dig into the codebase, which isn’t something I can say for a lot of open source projects. So that’s something.

My only advice, for what it’s worth, would be to provide a “bare minimum” implementation inline with the result. Something like this page with the source HTML and TS/JS displayed in code blocks. I personally feel a lot more comfortable diving into something new when I’m presented with a “taste”.

That said, I wasn’t aware of your project until today, and after looking into it for these questions, I will likely use it in the future. I’ve used Aurelia Table for similar functionality, but it comes nowhere close to having the feature set.

Please, don’t take my comments too harshly. I can tell there’s a lot of love and work involved here. Plus, I never expected anyone related to the project to read my comments. I’ll take this exchange to heart.

If you want to feel better, check out my repositories and see the half-assery I can’t be motivated to finish or maintain.

1 Like


It’s all good, no offense taken, open source community is great (most of the time), when everyone helps each other. The Aurelia community might be small but is still very friendly and helpful.

Also worth to know that Aurelia-Slickgrid exists because I support as well Angular-Slickgrid (because of the need for an enterprise datagrid at my work, you know they chose Angular because of the name…). You can also imagine that the Angular one has 4x times more users (stars that is) compare to the Aurelia one. Nonetheless, the code base of both libs is 90% the same which helps in making them in sync feature wise. I’d be happy if it could be used more in the Aurelia world :slight_smile:

So far in the open source projects that I have, most of the bad users I had usually comes from the Angular side lol.

I can tell there’s a lot of love and work involved here.

Sure is, I’m very passionate about SlickGrid (the core lib) in general (I’m also a contributor on the SlickGrid fork as well, for example I made the grid menu, aka hamburger menu plugin and a couple more). I was quite happy in having it ported to Aurelia, because Aurelia is my favorite framework, even though I can’t use it at work (sadly).

1 Like

Thanks for the comments guys… For my part I am a single person who picked Aurelia after having a crack at Angular 2 and then React… I hated both of them. I love Aurelia… its simple and consistent and the idea of staying out of the way of JavaScript means the more you learn the more you learn vanilla.

Re slickGrid I am the first to admit I am slow and very much on the beginner end of the bell curve but I persist.

All I wanted is to make calls to my API and the API to send them back using Fetch… I am personally having a hard time grounding myself with SlickGrid and this is in no way a reflection on the module… more on me. @ghiscoding there are datasets I feel are too big to simply download in their entirety (or will be) and a paginated option is required. The problem is I cant quite relate what I had with Fetch (which I dont want to change) to the options here… and I am also getting the feeling I am missing something with how I can put my fetch statements into a paginated example…

Is it that we download the total list and then add pagination? or do we just download the first 20 items, the total number of items and page number as an object and and do a call every time we click on another page? I get the impression its the first option - download the lot and paginate over whats in cache - based on your commentary above…

By the way I do see a number of projects I would “like” to use but with the absence of any documentation I often don’t bother. AT least you did some detailed docs and thats why I am looking and intend to use this… Simon


Aurelia-Slickgrid is probably 3/4 of the time used with regular JSON datasets (that is just a simple Http Fetch that returns a JSON dataset).

If you’re talking about over 10k rows, then you should start thinking about pagination, then again Aurelia-Slickgrid offers 2 services (through the backendServiceApi) for OData and GraphQL (your backend must implement whatever necessary to support either or). These 2 are built-in and are the best to pick, however if you need to go with something else… well that would be requiring more work, it’s doable but it’s more work. So I strongly suggest you to go with OData or GraphQL on your backend if you have the choice on that side.

1 Like

Well it turns out I am the projects owner/writer etc so… I have just started to examine Odata and GraphQL on the off chance its not a nightmare to implement into aspnet core… I guess any suggestions on this would be appreciated…

1 Like

We used to be with OData with ASP .Net 4.7 but when we switched our project to .Net Core, OData was not working, neither ready at the time with .Net Core. I heard it is available now though. So we want with GraphQL because we didn’t have much other choice, however the big benefit of GraphQL is that it’s query language (query input) is very similar to JSON (result), GraphQL is really amazing (built by Facebook) but implementing a GraphQL Server is not a small feat… The easiest and fastest to implement would be OData if you are on .Net, though it’s worth noting that GraphQL is more flexible and a lot more used compare to OData

1 Like