As everybody is entitled to their opinion, your article is obviously fine. However the graph at the end is seriously misleading:
In the first case it clearly depends: is there a probable cause some time you need to switch? And will your abstraction completely support that switch? Or do you still have to have to change a lot of other code?
The latter case is basic code evolution. Or do you also abstract over all other Angular things (a directive or a…
Although I like the idea of useful abstractions, the examples are not that well thought out.
For the company we work we just set the appropriate headers in email so most out of office and email bounces are not sent back (but handled through our API). Valid emails end up in the support queue.
Once a week support passes a list of tickets to dev, which may add headers or filter for a subject like ‘out of office’ so…
It looks nice to me, but the management of any dynamic state (manual rendering triggers for example) seems as it would require an awful lot of bookkeeping between components. That bookkeeping seems likely to slow things down.
Are there any ‘standard todo mvcs’ apps available? I’m curious to see how it works out in practice.