Component Based Architecture
As implemented in ReactJS, Vue JS and Angularjs 2.
Front-end development has evolved over the past couple of years. From DOM element ID referencing (Vanilla JS), to query Selectors (jQuery & Vanilla JS) to the 2-way data binding we saw in Angularjs 1.X.
I’ll discuss below the problems unlocked in Angularjs 1, as Google tried to eliminate the tedious DOM Element referencing:
2-way Data binding overhead
The 2-way data binding seemed super cool. You have data automatically updated in your View from your Controllers via your model (scoped variables), thus eliminating the DOM referencing.
This is super ingenious, only problem here is that poorly managed scopes get so large, it deters the application’s performance. A common quick fix here will be to
- Manually manage the scope, only scoping what needs to be rendered.
- Using 1-way data binding for scopes that only get updated from the Controller.
Un-modularity of the Controllers
Controllers are written and designed to tie to just a single View. None the less, you could bind a Controller to several Views, making it reusable. All you’ need to do is reference the scoped variables required by the View, while the other variables are left to fly.
Yet again, the problem here would be the unused scoped items, they’ll introduce an overhead, consume memory (could be negligible) leaving you with a ton of unused functions and variables hanging-out in the stack.
Another quick fix here would be to refactor your Controller, initializing the functions and variables required for the current View and binding them to the scope when the View is initialized. The scoped items would be unique to the View, eliminating the redundancies that would have been introduced.
Components on the other hand, help solve the problems discussed above with a single strike whilst keeping your code base DRY.
Blocked Scopes + Modularity
If you are familiar with Android development (native Java, not that weak hybrid s**t) Fragments are akin to Controllers, keeping their Views and underlying functions, modular and self scoped (like a closed loop system in Control Systems Engineering).
Very recently I tried to release an old Android app I worked on a couple of months ago (and yes, it obeys the Material design specs) using the latest Android Studio. I got a warning about a Fragment I created, because it was an abstract class with an abstract function called in the Parent Activity. I got to understand that this breaks the beauty of Modularity and i’ll have to refactor the Fragment.
Like Fragments, Components are designed like feedback control systems with some minor modifications. The variables (input / outputs) are scoped within the system itself, responsible for the state of the Component alone.
In ReactJS
Components are self-contained Views and Controllers that get their data from triggered events or as inherited property from their parent Component.
They can be used multiple times around your application by just simply importing the component and populating it with properties as required.
I’ll drop a very simple demonstration of a component I used to keep my code base DRY. I needed to use the anchor tag in several places in my website whilst persisting an attribute of the tag to avoid repeating myself. The target attribute.
See below, the React Component I created to solve this problem:
Context: When I need to use the Anchor Component Action: all I do is:
<Anchor href=”http://medium.com” label=”Medium”/>
without having to repeat the target attribute. The default target attribute gets populated when the Component is rendered(as defined in line 12) as it’s not a required property (line 23).
This is a simple example(probably the simplest ever) of how you can keep your code DRY using Components.
A more complex example (for intermediate front-end developers) will be the usage of the Portfolio Component in the Home Component in the source code of the same site, practicing the reusability and scoping preached in this sermon.
Think Components, think Modular, think React.
