When you need a paginated list of records in a web application it's probably best to use a third party library. The grids that DevExpress has are, for example, pretty robust and have enough whistles and bells to do mostly anything you might need. The other alternative is to roll your own. You rationalize it like this: "Well, those DevExpress grids are really overkill. We don't need to do all that! We are just going to have a table layout with pagination, oh and just a few more easy features." That works great all the way until the end of that story, but then, a sprint away, the grid needs to be tweaked so that it can do just a little bit more. Soon your monster will be growing more and more tentacles. I don't recommend this, but if you have the opportunity to work on something like this I think you'll find that it's a lot of fun to build something like this out even if it doesn't make a lot of sense. I've learned a lot. If a column in a grid has hyperlinks for all of its data points and the links all do something row specific, you have to find a way for the grid (assuming you are building something repurposable across all comparable scenarios and you’re not tying your creation to one need and one shape of recordset) to allow a user to hand in a method that can be run upon "hyperlink" (i.e. button) click. In TypeScript this takes the shape of having an interface (at the grid mechanics) that has a property for a method signature allowing JSON objects to be handed in from the outside to match against it that have a function hanging off of them to hydrate this need case by case. Once I actually built something like this I realized that if I were to build something comparable in C# that this would be one of the elusive use cases for a Func! An interface in C# would take a Func for what to defer to to do upon the click of a button at a row. Again, the goofy puzzle is also an interesting one and a lot of fun. What if you have an n+1 problem in which nine out of ten columns are hydrated by an initial query but all of the line items in the grid each require an independent call to hydrate the data point for the tenth column? Well, fortunately if you are using a canned solution like DevExpress you will not be allowed to do anything too stupid and you'll just be damned to deal with the data aggregation issue upstream or have the extra data points hydrate at expandable areas for each row as they are expanded by the user. If you are doing your own thing you can get silly. The items in the tenth column can just start appearing one at a time sequentially and asynchronously. If there is a search box at the top of each column for filtering then the filter for the tenth column starts out greyed-out and unlocks once you have all of the records! Now that's ghetto fabulous! Things can get really strange. You'll have to restrain yourself to keep the UX under control and not make something that obviously smells to users as dysfunctional and Mickey Mouse. The proverbial "You have enough rope to hang yourself." saying applies here. Try to use good judgment. Get others to nod their heads at your bad ideas, etc. Good luck!
No comments:
Post a Comment