It’s the result of constant and seemingly endless changes, reinventions and releases of tooling and frameworks that you feel you need to keep up with.
But things are going to change …
Dependency Injection or ‘DI’ is a mechanism used within Angular2 to provide instantiated services or other objects to the components (and other services) that need them. It allows a class to ask for just what it needs without needing to know about the entire tree of dependencies in order to create them itself.
The idea of DI is based on design principles intended to help us write better, cleaner and easier to maintain software. Unfortunately, there are certain limitations in the implementation of the Angular2 DI system which mean it’s not always obvious how to get all the benefits we should.
So, we’ll explore these principles using DI with the
Http and an
implementation as an example to show how it is still possible to achieve.
What makes a good client-side router? What do we even want a router to do? What is Angular2’s Component Router like and should you plan on using it?
I’ll share my own thoughts on this based on my experience of using it so far.
Once you move beyond the quick-starts and examples and start building a real app with Angular2 you soon find you need to handle things that the examples often leave out or pass over.
Securing routes with the new component router is one of these and it can be difficult to figure out. Here’s the approach I’m using which seems to be working well for me and has been reusable across multiple projects.
It shouldn’t be difficult to read rows from a database and render them on a web page – it’s a pretty fundamental operation that most web apps have to do but a surprising number don’t get quite right, especially when the volume of data grows and it can’t all be loaded and rendered within a single request. I’ve recently come across several ‘enterprise applications’ that simply fail to get it right – one extreme example loaded all the database rows into session state and then used LINQ to get and display the pages from that (!) and another took the approach of simply not paging the results at all which meant huge pages that were incredibly slow to load and as the data grew beyond the simple developer-test dataset.
So, I’m going to try and explain the technique I use for paging through rows which I’ve found works efficiently and is easy to re-use. It works well for both traditional and AJAX requests and handles sorting and filtering requirements as well. This is based on ASP.NET MVC, jQuery and NHibernate + SQL Server but the principals will be the same for other technologies (I’ve used the same basic approach with MongoDB as the back-end data-store).