As President Kennedy implored:
“My fellow developers, ask not what your Framework can do for you. Ask what you can do for your framework!”.
Yeah, I know, not quite the exact quote. But sometimes it feels that you have to do more to help your framework work than your framework does to help you.
Maybe it’s time to ask yourself, what is your Framework really doing for you … and do you still need it?
While we’re used to systems nowadays being distributed and running across multiple services on multiple platforms when it comes to front-end web clients many people still have a rather “monolothic” outlook on things.
Many times this is down to technology imposing restrictions on us - it’s difficult enough to make some frameworks and all their component pieces work together to deliver an app without also throwing in the challenge of making multiple different frameworks coexist (part of the problem with the rise of “frameworks” instead of libraries).
It can be particularly problematic when an aging app needs to be upgraded. You may have an Angular.JS app and be faced with the choice of whether to re-write it as an Angular v2 / v4 app or switch to using the Redux / React stack instead.
Both represent a lot of work and the difficulty making frameworks coexist can be a real challenge with any attempts at doing things incrementally. This is where WebComponents can really help.
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.