JS, DIC, Proxy, LOL, MTF, BBQ…

JavaScript logotype in Magenta
MagentaScript

The day I joined the Magenta side of the force…

As most of you know, I’m a backend guy… and sometimes I try to bring my backend experience to the Magenta frontend side of the force.

These days I’ve been coding the web application for eblock.ca and had some challenges to make all that spaghetti code full of duplication and bunch of responsibilities prototypes in something readable, useful and comprehensive for any developer that would be joining my team.

Questions and more questions…

To figure the best approach, I decided to dig into my memories from 2011 and make some comparisons between the first ECMAScript6 draft till what it is nowadays… with this, I could see the language evolution, the acceptance of all the proposed changes, and how the developers were accepting it and using it.

I had the chance to talk and work with amazing people whose helped to define a path to follow.

Answers and more answers…

The first task was to figure a way of making all that JavaScript files in re-usable components, and for that, why not take some advantage over Class Definition and Inheritance?
I used to code in PHP and Java at that time and I love interfaces…
When we made this decision I remembered about the ECMAScript6 draft, and it didn’t mentioned interfaces, nor type hinting – that is the moment when I HATE my Spidey-sense – and I was most likely need to make usage of the instanceof operator, making me look to my nasty past checking some PHP object’s type using the same operator – I know, blame me for not using type hint when PHP5 came out – and desiring to have type hint support.

class ThatsWhatSomeJSDevsCallAnInterface
{
    public function execute()
    {
        throw "Implement me";
    }
}

class Implementation extends ThatsWhatSomeJSDevsCallAnInterface
{
    public function execute()
    {
        return "I think I don't know the difference between extends and implements anymore...";
    }
}

Stop talking, do it MTF!

So, we figured that we could separate the participants and its responsibilities in a classy way – thanks babel, love ya! – and being able to inject all the external participants as dependencies and being able to breath!

class Notifier
{
    constructor(transport)
    {
        this.transport = transport;
    }

    notify(event)
    {
        this.transport.dispatch(event.name, event.data);
    }
}

See the beauty? now I can implement a rest based transport layer, or a websocket transport layer, or anything that you can imagine!

my biggest issue now would be the fact that I don’t want to use instanceof to check the transport type neither make the transport to inherit from a class that behaves like an interface – luckily we can find some babel plugins to be able to type hint, which I’m not a fan to be honest… IMHO this should be supported by the Engine/VM not a transpiler.

At this point, I rely at the developer’s common sense.

DIC

Now that I have the cracker, I need a knife to spread the cream cheese on it and blend it on my mouth!
Codewise, now that I have all my participants holding just one responsibility, a clean code, I need something to keep it cleaner and easier to understand.

I won’t talk about Dependency Injection Container neither how good/bad they can be… but what you need to know is:
I NEED IT!
and from the need, with some google searching skills, I found the amazing BottleJS and figure that it could help me somehow – Especially when its founder helps you somehow.
Now I was able to configure my services, inject all the dependencies, and guess what?
– Nothing, just call the services… but at least, now I can have a place in heaven to configure all my services, inject some dependencies, inject configuration, and even configure my WebSocketNotificationService that is the exact same class as my RestNotificationService receiving different transport layers that guess what? are configurable also!

Proxy

There’s a magic  – and well known – operator called import, and that’s how you import a JS module – There’s 9999 ways out there, and this is important due to standardization – in other modules/files/whatever.
Now that I have my container with all my services working fine, I want to be able to import them using the fancy import but without importing the entire container for that.

That’s where Proxy joins my team to play with us!
Not only a good player, Proxy opens the possibility of implementing new patterns –  and cool stuff, can you imagine DoctrineJS?- on JS apps.

Everything wired up… our node apps was practically loving it…
But how about the browser?
Well… that’s the downsize of having an amazing architecture in a non-controlled environment… guess what? we will need to wait a bit more to use it in prod, but at least our backend JS apps are collecting as much coins as a Hedgehog.

Thoughts

It’s hard to a backend developer to assume that being on the Wireless side of the force is kinda cool…
This project is bringing me back to university times and is showing me how good was to keep track of the language specification, specially in 2011 when the ECMAScript6 was in its initial draft.

I’m hoping to see even more changes to bring better code to the web, and to see even more developers dedicated to change the world… or at least, the web.

PS: I didn’t joined the Magenta side… I’m actually colour blind.

Advertisements

2 thoughts on “JS, DIC, Proxy, LOL, MTF, BBQ…

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s