Skip to main content

Reactive and Component Frameworks for "Old Fart" Programmers

One of the great challenges for experienced developers when confronted with new concepts is being able to map one's existing knowledge to the new concept. As they say, there is nothing new under the sun, that is often more true for new development methodologies.

Even when new jargon is brought to bear on new methodologies, often upon closer inspection you recognize that it is something that you already know that is being described in a new way (unfortunately sometimes in a convoluted way to make it seem new).

Reactive/Component UI/UX frameworks are one such development, while their particular implementations may be new and novel, almost all of the underlying concepts are not new.


This is hardly a thorough presentation of Reactive/Component frameworks, but rather an attempt to fill in some gaps for developers who have experience but might find themselves confused by some of these new kids on the block.

The top 3 reactive component frameworks being React, Angular and Vue. All of these frameworks more or less do the same thing but generally go about it in different ways. The question of which to go with would probably depend both on your own developer taste and what you wish to accomplish.

At their core, these are component frameworks that are reactive, ie they allow you to turn what used to be tag-soup into things that have rigorous semantics, they automate state-to-view (data binding) maintenance and provide some other nice to have features.

In other words, you go beyond a div tag which has no inherent meaning, to a toolbar tag which has a definite meaning. Of course standard html tags can be imbued with meaning but these frameworks provide a systemic way of doing that without having to reinvent the wheel.

How they define Components

React
Uses Javascript functions directly as a way of defining components. The function takes as arguments, the properties of the component. The function is then responsible for making sure that component materializes with the help of the framework. With React the name of the function (or class) becomes the name of the component that you can reference in JSX.


Angular
Uses a class declaration to represent a component. You need to "decorate" (for java programmers, this is annotations) the class to signify that it is a component. In other words Angular also uses Javascript functions to define components since the semantics of classes in Javascript are the same as doing new FunctionName of yore, the new class syntax is mainly syntactic sugar.


Vue
By creating new instance as an extension of the core Vue class. The way this is presented can make it seem different but really components in Vue are functions because Vue.component(...) returns an extension of the core Vue class which can then be used to instantiate the component via new MyComponent. The main thing Vue.component(...) does is allow you to tie a name to the returned instance, a round-about way of signifying a class :)


So by-and-large, all three frameworks in fact use Javascript functions to define components but go about it in their own round-about ways.

Using Components

If components are functions then it makes sense to view their usage in terms of function invocations. Every component reference can be viewed as an invocation of the corresponding function and the props are just arguments to that function. React's API kinda makes this fact obvious, if you look at the compiled result of JSX you can see the invocation chain.

About slots and content distribution.

Additionally, Vue and Angular use the notion of slots, ie the inner content of a component's tag. slots should be simply viewed as additional arguments passed after props to the component function (JSX makes this obvious).


Slots can also be "scoped", meaning you can sort of change the local variable context of the slot's content, ordinarily it uses the context of the component invoking it, this is not unlike Javascript function scoping.

The way the slot scope concept is presented by the Vue documentation is confusing so it is better to think of slots not as content that get passed to a component but rather as callbacks that get passed to a component.

The component would then invoke the callback to get content, if the callback is passed an argument when invoked, then you can use this passed argument as the "scope" of the template and return the resulting evaluation as the content of the slot.

The Vue documentation seem to present this concept in a way that suggests that the user of a scoped-slot needs knowledge of the internal details of a component, this would seem like a solid violation of a major component design principle, ie encapsulation.


Viewing components as the Javacript functions they are, helps simplify the thinking model required for addressing everything else from state management to event propagation, to scope management. Without such a model, I personally find it impossible to think properly about the component tree as a whole; when I envision a structure of nested functions and function calls, things are a lot easier.

Logic

VueJS
Vue is the most Javascripty of these frameworks, it has no particular requirement for how you integrate application logic with components, as long as a function/object is somehow accessible within the scope of a Vue instance you can use it to drive application logic. There are of course best practices for how to do this but the framework doesn't impose one.

React
React is mid-way, you can incorporate application logic however you wish, in addition you can use JSX to integrate such logic quite seamless. The problem with mixing JSX with core logic is that it seems to violate the concept of separation of concerns, ie don't mix presentation with logic, except JXS is Javascript! I am sure there is an interesting debate to be had about JSX with regards to the topic of separation of concern but we won't get into that here.

Angular 2+
Angular is the least Javascripty and most Java-ee of these frameworks. You need "dependency injection" to integrate application logic into components...you remember dependency injection right (any Springers reading this?)? yeah that thing that whenever you see it mentioned it reminds you of a song with great melody but whose lyrics you don't quite get.


Modularization

Vue
Uses Single File Components (ala .vue files) to manage packaging of components. Basically a way to manage the CSS, Javascript and HTML that form the building blocks of a component.


React
Uses Javascript Modules.

Angular
Uses ngModules: A pseudo Javascript module that has special meaning to the Angular engine and thus is processed differently but otherwise it is better to just think of them as you do Javascript modules.


Reactive/Component Frameworks, what are they good for...


At least from our perspective at Codesolvent, we don't see these frameworks as things that should be used primarily as they are, in other words we think the real power in these frameworks is in using them to build higher-order developer tools.

These frameworks provide the type of constraints that make it relatively easy to build tooling that goes far beyond text editors that are the bread-and-butter of traditional IDEs.

Below are examples of what we are building based on these frameworks:






















Comments

  1. If you want to try a lightweight, fully specced buy tiny reactive / functional framework I recommend https://thesephist.github.io/torus/ it's easy to learn and helped me with groking other frameworks

    ReplyDelete

Post a Comment

Popular posts from this blog

The feds need to shutdown the bitcoin scam now.

I live in Baltimore, let's say I have some hypothetical friends who are always looking for a good hustle.

Now imagine if my friends got together for a new get-rich-quick-scheme, the scheme is very simple. They invent something called cracken (bitcoins) that they start selling on a few blocks in Hamsterdam.

The way you get crackens is to do laps around the blocks in Hamsterdam. Initially when the scheme was setup, you could get a whole lot of crackens by merely doing a few strolls around the block. Needless to say my friends made out like bandits, since, after all they created the scheme and could take advantage of the first-come-first-serve rules.

Unfortunately for the rest of the hood, the number of laps required to get the same number of crackens keeps going up and after a while even the fittest folks in the neighborhood cannot do the lapse required to earn crackens.

Cracken mania takes hold and infects the whole city. Those with crackens start trading these crackens for exor…

Why Not Signed Password Authentication?

It is now universally acknowledged that basic password authentication does not offer sufficient security. 2-Factor authentication is a major improvement and hopefully would become the standard form of authentication over time.

Another approach that might work well would be to use public key cryptography to authenticate with a signed password instead of just the plain password.

An application (web or native) would generate the public/private key pair and store the private key locally while storing the public key along with the user's password on the server. This key generation can happen for instance during account sign up when it is clear the owner of the account is the one accessing it. Of course a key rotation mechanism can be devised to allow for a flexible way of rotating keys. This would all be transparent to the end user.

Instead of the user submitting just the password, they'll submit both the password and a timestamp based signature, ie plainpassword+curre…