Forem: Valentino Pellegrino

Regular Expressions made easy: a declarative approach

Valentino Pellegrino — Mon, 06 Apr 2020 10:12:20 +0000

Be honest: every time you find a regular expression in the code, you start wondering if you can avoid to change it, or maybe if a colleague can help you to understand it.
How many seconds do you need to understand that
<(\[A-Z\][A-Z0-9]*)\b[^>]*>(.*?)</\1>
is a regex to grab HTML tags?
If you are searching for a smart way to write and maintain a regular expression, relax and continue reading.

First of all - What is a Regular Expression?

“A regular expression (regex or regexp for short) is a special text string for describing a search pattern. You can think of regular expressions as wildcards on steroids. You are probably familiar with wildcard notations such as .txt to find all text files in a file manager. The regex equivalent is `^..txt$`" - https://www.regular-expressions.info/

There are a lot of use cases where regular expressions fit well:

You want to analyze command lines.
In general, you want to parse user input.
An huge text file: let’s parse it to find some useful stuff (e.g. specific logged errors).
Pattern matching (e.g. you want a password to follow a specific format).
Replace a repeating sub-string in a characters sequence.

In order to use regex, you have to understand and remember a lot of symbols and methods:

Why Regular Expressions are used so much?

The reason why regex are widely used is for their performance. The more precise your regex is, the less likely you are to accidentally match text that you didn’t mean to match.
Regex are really fast when they are accurate. Good regular expressions are often longer than bad regular expressions because they make use of specific characters/character classes and have more structure. This causes good regular expressions to run faster as they predict their input more accurately.

VerbalExpressions

VerbalExpressions is a set of libraries that represents an easy way to write readable regex. It can ease the pain of regex, and actually make writing expressions fun again.
VerbalExpressions has been ported to so many other languages that a GitHub organization (https://github.com/VerbalExpressions) was created just to host them all.
Obviously, there is also an implementation of such library for JavaScript (https://github.com/VerbalExpressions/JSVerbalExpressions).
Given a complex regex that checks for valid URL /^(http)(s)?(\:\/\/)(www\.)?([^\ ]*)$/
Let’s see how it easy to write it, using such library:

const urlTester = VerEx()
    .startOfLine()
    .then('http')
    .maybe('s')
    .then('://')
    .maybe('www.')
    .anythingBut(' ')
    .endOfLine();

How to use it

There are several ways to use such library:

You can download it and import using a standard script tag:
You can use a Content Delivery Network, like http://www.jsdelivr.com/projects/jsverbalexpressions
You can install it, using NPM and use it in any Node based application: npm install verbal-expressions

You can also use it live on the site https://verbalregex.com/

Chatbot Expenses - Simple bot for collecting expenses typed in the terminal

In that example (https://github.com/vpellegrino/chatbot-expenses), I show how to build complex parsing features, used by a simple NodeJS application, with a prompt interface, used to collect and report expenses from a group of users.
Imagine you want to offer a list of commands, like the ones defined below.
Store expense

<EXPENSE>=<PARTICIPANT>\[,<PARTICIPANT>...\][ "<MESSAGE>"]

For each participant, you can also specify a different split for the costs, by using the modifiers + and *.
Examples:

84.20=MR,VP+0.20 "Pizza"

This means, VP has paid 84.20 USD for a pizza, where 42.00 USD is in charge of MR.

MR> 20=VP "Hamburger"

In that example, MR has paid 20 USD for an Hamburger eat up by VP.
Retrieve the list of expenses

HISTORY

Retrieve the group balance

BALANCE

This is the most important command, since behind the scenes an algorithm similar to Bin Packing and Partition Problem is used. The goal is to print the minimal set of transaction in order to pay all debts inside the group.
Example:

Alice -> Bill $10
Bill -> Alice $1
Bill -> Charles $5
Charles -> Alice $5

Solution would be:

Alice = $4 Bill = $-4 Charles = $0

Declarative Regular Expressions

The service that is responsible for providing all checks for well-formed commands and for grabbing user input is src/services/regExpService.js.
A series of constants (that can be reused in other complex expressions) have been defined. For instance:

const twoLetters = new VerbalExpression()
                  .then(new VerbalExpression().range('A', 'Z').repeatPrevious(2));

The combination of such constants get assembled in more complex functions, that are still easy to read (or at least, easiest than the related regex).
For example, given a line of text, the function below is able to return an array containing two elements: the sender initials, and the message he sent:

function parseSenderInitialsAndText(line) {
    return new VerbalExpression()
        .startOfLine()
        .beginCapture().then(twoLetters).endCapture().then(ARROW).maybe(WHITESPACE)
        .beginCapture().then(new VerbalExpression().anything()).endCapture()
        .endOfLine().exec(line);
}

It is quite easy to switch from standard regex to VerbalExpression() and viceversa. So, it is definitely easy to combine them when you don’t know exactly how a specific regex works, but you still need to extend it.

Conclusion

Regular Expressions are mathematically sound and fast. But they suck 😁 really hard in terms of ease of use and maintainability.
So, for good performance, we need longer regular expressions. 😮
But, for good maintainability, we need shorter regular expressions. 🤔
VerbalExpressions represent a good solution 😎, that enables you to use regex, without the pain of maintain them. With a declarative approach, you can simply write your statement, describing the way you expect to check or grab a certain character/group of characters.

Web Components: a Frameworkless solution

Valentino Pellegrino — Fri, 06 Dec 2019 11:11:27 +0000

Whenever you adopt a framework, you must take in account that you are locking your project into an already defined road-map, that probably has been defined by a third party company/development team.
Frameworks can “die”. The community could move to another technology or a new tool. But things can get worse: a security issue gets found on a framework that is no more maintained.
Adopting a framework, you are also adopting a risk: your project is going to be legacy sooner or later. This is disruptive, especially in an enterprise scenario.

Frameworkless Movement

“The Frameworkless Movement is a group of developers interested in developing applications without frameworks. We don't hate frameworks, nor we will ever create campaigns against frameworks, but we perceive the misuse of frameworks as a lack of knowledge regarding technical debt and the availability of alternatives given by the vanilla language or by dedicated libraries.” - http://frameworklessmovement.org
This movement does not think that frameworks are evil.
Let’s start from a simple principle: if you are able to code without a framework, you are also able to decide whenever to use or not to use them. This decision is based on the knowledge of strengths and weaknesses of the framework itself.
Have you ever asked how a particular framework acts behind the scenes? For example, how IoC (Inversion of Control), in the popular Spring framework, works?
Have you ever tried to build your home-made i18n service?
Do I really need to adopt Angular framework, just because I need client-side routing in my Single Page Application?
If I adopt VueJS, just because it is a growing trend, are my colleagues ready to leverage it?
When this kind of questions come to mind, you are starting to think of frameworks in a critical way.

Web Components - a brief introduction

The goal of this section is not to give you a full overview about Web Components. There are a lot of resources in the web that you can rely on. We just need some basic concepts to understand the next proof of concept.

What is a Web Component?

“Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.” - https://www.webcomponents.org
Building blocks of Web Components are:

Custom Elements: custom defined types of DOM elements (you can create a new HTML tag).
Shadow DOM: encapsulation of style and markup in a Web Component (you have an isolated DOM structure).
ES Modules: reusable JS modules (you don’t have to use third party libraries such as SystemJS or requireJS).
HTML Template: fragment of markup that could be dynamically loaded (you can exploit a lazy loading strategy).

How can I use a Web Component?

There are several ready-to-use components, provided for example by the Polymer library (https://www.polymer-project.org/).
The good news is that you don’t need to adopt an entire framework, to use a particular component.
For example, if I want to use a slider that follows Material Design (https://material.io/design/components/sliders.html), I just need to:

Install it: npm install @material/mwc-slider

Include in my page:

import '@material/mwc-slider';

<mwc-slider value="25" min="10" max="50"></mwc-slider>

Et voilà:

Can I customize a ready-to-use Web Component?

If such Web Component is well designed, the answer is definitely yes.
For instance, if you don’t like the style, or you need to listen to the change event of the slider defined above, you just need to look at its APIs (https://github.com/material-components/material-components-web-components/tree/master/packages/slider).

Ok, but the Web Component in my mind does not exist.

No issue with that: you can just build your custom Web Component. Look at next section!

Parking Widget - A Frameworkless, custom and reusable HTML element

In scenarios where I need a Web Component that is highly customizable, and near to my business requirements, you can also define a coarse grain component.
In that proof of concept (https://github.com/vpellegrino/parking-widget) I show how to realize an interesting UI widget, without using any framework (VanillaJS).
The requirement was to realize a widget to show a collection of parking slots and let the user buy one. Such widget should be easily embedded in any Web application.

Technical Details

The Parking widget is a simple, light and framework-less web-component (HTML CustomElement).
It can be added to the DOM:

<parking-widget id="my-parking-widget"></parking-widget>

Initialization is simple, via two properties:

model is the JSON definition (e.g. src/assets/model.json), used to fill and render all widget dynamic areas.
onSelectionCallback is the function provided to the widget that will be called each time a parking slot selection takes place. That function is expecting one argument: the object related to the selected parking slot.

Communication mechanism

Can be represented as below:

Conclusion

In a well designed architecture, business logic should be separated by the specific project configuration or framework usage.
How many times you, as developer, are making estimations based on a particular framework? It does not make sense!
Functional requirements like budget, usability, domain-specific constraints should guide architectural choice and hence estimations.
And remember: you don't need a framework to build a good web application.

Adopting Angular (2+) framework

Valentino Pellegrino — Fri, 06 Dec 2019 10:58:46 +0000

As you may know, AngularJS framework is no longer supported. Creating new pages using that framework is discouraged.
How can we handle existing pages, written with older framework? How can we handle new pages?
There are different strategies that can be used to obtain this goal (at least partially)

Re-coding from scratch the whole AngularJS application.
Bootstrap an hybrid application that has both Angular and AngularJS frameworks.
Keep the older AngularJS as is, freezing it from new-feature-development, and booting an Angular app to be kept side-by-side with the older one, by using the micro frontends paradigma.

Re-coding from scratch the whole AngularJS application

PROS

Easier maintenance: only one framework (Angular).
Performance improvement for "legacy" part.
While rewriting the legacy part, you have the possibility to restructure it in a more maintainable way and to write tests for uncovered components/service.

CONS

A lot of time will be needed. No incremental value.

Hybrid Application (ngUpgrade)

When you need a new library or external capabilities, most libraries (Angular wrapper etc.) are now only targeting Angular 2+. Angular offers a series of built-in tools for efficiently migrating AngularJS projects over to the Angular platform, a piece at a time.
One of the keys to a successful upgrade is to do it incrementally, by running the two frameworks side by side in the same application, and porting AngularJS components to Angular one by one. This makes it possible to upgrade even large and complex applications without disrupting other business, because the work can be done collaboratively and spread over a period of time. The upgrade module in Angular has been designed to make incremental upgrading seamless. A detailed guide is on https://angular.io/guide/upgrade.
Built-in APIs offered by Angular are described here: https://angular.io/api/upgrade. They supports the upgrade path from AngularJS to Angular, allowing components from both systems to be used in the same application.
Migration steps
There are different migration strategies, but the most preferred one is to run side by side with Angular being the main application.

Create Angular application using Angular CLI
Copy an existing AngularJS app (should be 1.6.x and refactored so that the structure of the code is feature based and each file has a single implementation)
Migrate JS dependencies (Switch to npm)
Fix template paths for the legacy AngularJS app, in both JS and HTML
Migrate css files and fix import paths
Fix minor CSS issues caused by an introduction of view-container and view-frame
Regression test (It seems all working at this stage, have a good test by QA)
Add Angular Routing and introduce a new page
Switch between AngularJS page and Angular page

PROS

Upgrade can be gradual, even if difficult
Low regression risk
Using the upgrade/downgrade Angular functionality, it's possible to use legacy components/services inside Angular app

CONS

"Fast" start but slowness on the mid-long term
Graphical issues: "legacy" app uses AngularJS and Bootstrap 3. We cannot have on the same page Bootstrap 3 and 4
Initial loading time of the application could represent a performance issue
Build issue - built-in ng build from angular CLI does not understand that we are including AngularJS
The application becomes significantly larger compared to the previous release (4 times larger than AngularJS app)
Need to apply upgrade/downgrade on existing AngularJS components/services
If you use UI bootstrap on AngularJS, it seems there is no simple way to have side by side two different versions of Bootstrap

Micro-frontends

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end, from database to user interface.
Something often not mentioned in discussions is that micro-frontends can be split horizontally or vertically.
Horizontally would mean the case described here: Multiple independent apps on one view. I really don't want to see the resulting bundle-size for this approach.
Vertical splitting means you have one app for one view, and separate e.g. by subdomain where login.app.com, news.app.com, editor.app.com each have their own app. DAZN works like this, for example.

The tool

Single SPA is a JavaScript framework for frontend microservices. It enables you to use multiple frameworks in a single-page application, allowing the code split by functionality and have different frameworks (Angular, React, Vue, etc.) all living together.
There is a recommended setup, to boost code performance and bundle size. You also have the possibility to interactively configure the Single SPA entry point, with a playground. A bunch of tutorials and coding examples are available here.
Most interesting features:

use of multiple frameworks on the same page without refreshing the page,
lazy load code for improved initial load-time,
top-level routing.

Here is a Proof of Concept about utilization on the same single page application of multiple (separated) frontend application: https://github.com/Pragmatists/microfrontends
In that POC there is also an example of applications communication, performed by using global events, where data exchange is supported. Also other sharing mechanism are possible.

PROS

Setup of the project should be painless, with the exception of all the initial boilerplate setup
For the micro-frontend solutions, Single SPA seems like the most mature framework
There is the possibility to have CSS stylesheets independence by automatically wrapping CSS rules in a namespace dependent on application name (look at https://github.com/ruslansavenok/postcss-wrap)
Each SPA app can have its own repository and different teams can work w/o conflicts
Open Points

CONS

Should we deploy applications as independent frontend or bundle everything together? In the first case we need to expose them, for example, in different ports. In the second case, if one - of such application changes, you have to rebuild all together.
Take care also of file system total size for both solutions, as well as total size of downloaded resources by the user (via the browser)
In the single bundle approach, is it possible to have conflicting libraries side by side? (e.g. bootstrap 3 and 4)
How to manage common dependencies?

Conclusion

Working on legacy AngularJS projects, you will soon start to elaborate a migration strategy to a modern framework.
If you are thinking to switch to Angular, React or VueJS, there are different strategies you can follow, depending on both technical and business requirements.
There is an optimum way, that is writing from scratch the entire application. It can be very time-wasting and I am sure that your boss will not easily give you so many time to rewrite something that more or less works, w/o adding any customer value.
Angular’s Upgrade APIs represents a good compromise, that can be leveraged only if you are thinking to migrate to Angular.
The Micro Frontends strategy allow you to create the right abstraction between a specific application implementation, which is highly coupled with a framework, and its functionalities that should be exposed with the outside world. The community, overall, is going in that direction.
The last suggestion that I want to give you is: while you are migrating an application or you are adopting an hybrid approach, why don’t you encapsulate your components/services with Web Component standard? Next time that the framework will change, it will be more easy to perform an upgrade.