DEV Community: DigitalCrafting

Angular vs React

DigitalCrafting — Thu, 25 Dec 2025 10:09:53 +0000

I'm not going to compare features of each, because it doesn't matter. You can write good applications in both. What I will compare is: how easy it is to maintain the project after the initial burst of code finds its way to master/main branch.

Let's cut to the chase: Angular is easier to maintain in the long run when you have people come and go to the project that lasts for a few years. It gives you everything you need (it's a framework after all) and it's well structured, even if you have to write a bit more code.

That being said, React is nicer to write in, and you could successfully write a large project in it, however, it is more demanding and requires great discipline to do so. It's just a library, you need to add to it to create something resembling a framework, and you need the strong will not to chase the new shiny solution, but to keep being consistent for the whole duration of the project.

Now, how did I get to that conclusion?

Projects

Angular

I've worked with Angular since version 2.0-RC in Banking industry. I wrote code for the Customer Service (in Bank branches, franchises, call center and some stand alone mini-apps). It was all in a single monorepo, it was basically one application consisting of many modules (Customer File Management, Transfers etc), all lazy-loaded, all configurable via admin panel. The modules were very Form heavy, but isolated from each other.

React

In React I've worked with deceptively small applications that had a lot of intersections between components and non-trivial business logic. I've used version 16-18 and Next.js. The most demanding was application for Airlines Call Center, which didn't have that much individual pages, but was very feature rich and the individual business components (ex: Tables and Forms for Flights and Services etc.) were reusable across the application.

Teams

In both environments I've worked in projects with teams consisting of 4 individual sub-teams, where the level of individual developer varied from junior to senior.

Why Angular wins on maintainability?

It's because people confuse React with a framework.

Let's get one thing straight - React is a library. When you visit React.dev, you see:

The library for web and native user interfaces

Whereas if you visit Angular.dev, you see:

The framework for building scalable web apps with confidence

And this makes ALL the difference.

Developers, even some of the senior FE developers, seem to think that React is all you need to write good application, and hooks (looking at you useEffect) are a god-sent. The React courses or tutorials are not helping by suggesting you should be calling API in the useEffect on state changes.

Tracking the cause-and-effect of React hook dependencies is a nightmare. It might work in small, short lived project like a portfolio website, but when we get more and more requirements and features in our application, it very quickly spirals out of control.

In order for React to work well for your project, you need to compose a set of libraries that work well together. You need to understand which patterns work in certain scenarios and which don't. You cannot just slap useEffect everywhere and hope for the best.

Little to no one cares about how many times the component re-evaluation is triggered, least of all the creators of libraries for React. One of the form libraries triggers the re-evaluation all the way from the root component at least 2 times, simply because the internal form state is defined as useState and is updated every time the input value changes. That's not acceptable.

Where React shines

React can be very nice for a team of seasoned developers, who understand that not everything needs to be written "the React way" - meaning hooks.

JSX is amazing for writing components. children prop is my favorite feature of the whole library, it was so refreshing to easily write wrapper components without having to worry about lifecycle.

With React you can easily shed all the dead weight slowing your application down but it comes at a cost of having to manually control pretty much your whole components life cycle, and most developers are not used to that.

Where Angular fall short

As pretty much every single article comparing the two states: Angular can be a bit harder to start with, mainly because of all the files you have to create, and all the life cycle methods you need to understand, but they are there for a reason. They work really well in a large, corporate projects.

Don't mistake standalone components for a full replacement of modules. Modules still are the go-to solution for structuring your code, especially in larger projects. Let's take a Money Transfer as an example, where you would have at least a few components, services and configurations, each for every type of Transfer (Own, Internal, External, Cross-Border etc.). You could take that module and lazy-load it as a coherent whole. Not only that, but you can assign modules to a specific teams, which would be responsible for their modules without conflicting with other teams.

Final Recommendation

For small applications, like a Portfolio, it doesn't matter, because the impact will be minimal, and you will likely be the only developer there.

For anything bigger, you should consider all the points above - will you choose Angular and have easier time maintaining it regardless of developers seniority? Or will you opt for React and deal with the future complexity yourself?

If you still opt for React, I have following suggestions:

Limit useEffect to a minimum. Prefer explicit calls on an event (such as click) to implicit call on state change,
Separate business logic from React components. Keep complex logic in services, so that React components are only responsible for rendering,
Keep the project consistent. - avoid new patterns or libraries in the middle of it, unless the business requirement demands it. Consistency matters.

Programming from Top to Bottom - Parsing

DigitalCrafting — Mon, 18 Mar 2024 15:28:30 +0000

In the previous article we saw that there is quite a gap between what we write and what CPU does and we also saw a simplified flow diagram of interpreted and compiled languages.

We will start with interpreted languages, and then move to VM and natively compiled ones, as they are progressively more complicated.

But before all that, let's ask ourselves more general question:

What is programming language built of?

Well, let's start with spoken language. It is built of words and grammar. Words are used to name/describe things/actions, and grammar defines how it can be done. For example, expression high mountain, consists of two words high and mountain. Grammar tell us, that:

high is an adjective,
adjectives describe things,
mountain is a noun,
nouns name things,
adjective must come before noun.

Thanks to those simple rules, we know how to decipher the expression high mountain, and many more like that.

Getting back to programming: programming language is pretty much the same, only the grammar is simpler. Also, when talking about programming languages words are called tokens, and the types of tokens are named differently (although, you could name them adjectives and nouns if you wished).

Much like for spoken language, programming language grammar, aside from naming types of tokens and what they look like, tells us what we can do with them. For example, for this expression: int x;, it tells us that:

int is a type,
when the expression starts with type, it's also a declaration,
x is an identifier,
type must always come before identifier,
; marks end of expression,

If you compare the high mountain with int x; side by side, they are not that different in how they are described.

With more words comes the complexity, so in order to group them together, we form sentences, and it's no different in programming - it is called an expression or a statement. As in natural languages, an expression can be simple or complex consisting of 1 or more other expressions or statements, but we will get to that.

To summarize:

word is called a token in programming language,
sentence is called an expression or a statement,
other elements differ from language to language.

That's all well and good, but in order for CPU to actually do something, we have to parse programming language and transform it into machine code. So, the next natural questions is:

What is parsing?

Simply put: it's translating text into a data structure, based on some specification.

That's it. In case of programming languages, the specification is called grammar, which we explained in previous section. If you are interested in more detailed explanation, you can check this article.

Parser itself is made out of 2 components: tokenizer (also called lexer) and AST generator (actually it's called parser in other sources, don't ask me why parser contains parser, we probably run out of names).

Tokenizer

Tokenizer is responsible for taking in file containing some text, and dividing it into tokens (words).

Token is much simpler than a spoken word. Unlike in the spoken language, there can be no confusion about the meaning of a token. Let's look at a bit more complicated example, a code like this:

int x = a + b;

Can be divided into following tokens:

You can never mistake type_declaration with an identifier, otherwise the program will not work. Aside from that constraint, you are free to name them whatever you like, there is no one standard, and each parser has it own naming conventions, unless you are planning to use something like LLVM. If you are interested, you can see examples of naming in different language parsers in the AST Explorer.

Actually, there is one more token type that's not presented on the diagram: white_spaces. Unless it's Python or YAML, we will simply ignore the whitespace characters, their only purpose is to divide other tokens that would otherwise be indistinguishable, like int value from intvalue.

So, a tokenizer goes through a file, and reads all the tokens one by one, returning them to parser. How does it know which token it read? By using regex. Each token definition has regex expression associated with it, and we check if the beginning of our string matches one of the token types, otherwise we return null or throw an error. You could write it simply checking each and every character in order to avoid nested looping, but for this article we are not be doing that.

Notice that we didn't yet touched on the grammar defining the order of tokens, that's the AST generator's task.

AST generator - actual parser

But wait, what is an AST? It's an acronym for Abstract Syntax Tree, and it's a intermediate representation of our code in a form of... well... a tree (finally those data structure courses can be of some use).

Why do we even need that? For type and grammar checking, optimizations, and it's easier to traverse than an array of tokens.

In our example, the code:

int x = a + b;

Will be represented as:

You may notice the missing ; - that's because it's only a delimiter - it marks the end of a single expression and is not relevant for further processing. Also, in this diagram I don't show the metadata for each node, such as type of the token, but it's there.

Going from the top, the expression can be easily interpreted as an assignment expression, where we declare a new variable called x of type int, and assign to it the result of adding value from variable a to value from variable b.

Let's see more complicated example with a function declaration:

int square(int y) {
    return y*y;
}

The AST for that piece of code would look something like this:

Well, that became quite big really quick, didn't it? If we added a class on top of that, the diagram would be twice as big, so from now on, we will switch to JSON representation of a tree, and only for parts that we actually need.

Thing to note in this example is that a function has 3 children nodes:

return type,
parameters,
body.

A body node is just a list of expressions in order of appearance, ending with optional return statement.

Given that information, you can probably guess what a class declaration would look like, it would have:

identifier as a name,
access modifier - public, private or protected,
body which would a list of expressions.

You can see where this is going. Each structure and expression in a programming language is well defined and has a set of parameters that it consists of. It also has a defined order in which they can appear, for example: a class name identifier must appear after a class keyword.

And that is called programming language grammar.

Grammar

Grammar can be defined using a Backus-Naur Form, which is a meta language that for me became readable only after I actually implemented parser, but nevertheless, let's go through a brief introduction now.

Let's use our original piece of code as an example, which was variable declaration: int x;

This is called a declaration expression, and as name suggests, it's used to declare a variable.

The grammar for this type of expression, can be described as:
"A type identifier, which is a keyword, followed by a name".

In Backus-Naur Form (BNF) it can be written as:

<declaration-expression> ::= <type-identifier> <identifier>

Let's look at another example:

int x = square(x)

In BNF, this type of expression, can be defined as:

<assignment-expression> ::= <declaration-expression> '=' <expression> | <identifier> '=' <expression>

Meaning: "An assignment expression is a declaration followed by a '=', followed by an expression, or, an identifier, followed by '=', followed by an expression".

This can go on and on, and as the expressions become more complex, so does the BNF notation, however, when written right, the BNF can reflect the code quite well, which we will see in the next article.

Summary

Finally, the theory part is over, at least for the parsing that is 😉

In the next article, we will dive into the tokenizer and parser code.

Also note, that what I wrote about is applicable to any resource, not just programming language. You can use this knowledge to parse JSON, XML, HTML, CSV and whatever else you need, it only comes down to defined grammar.

See you in the next one!

Programming from Top to Bottom - The Basics

DigitalCrafting — Sun, 18 Feb 2024 10:40:03 +0000

As promised in this article, we are going to dive into how programming actually works from top to bottom. Or in other words: how a CPU can understand what you are writing.

Disclaimer: this series of articles is supposed to be a high-level overview, that gives you an idea of how programming works, and a starting point for future learning. As such, it will contain many simplifications.

What is programming language?

Let's start really high: what is programming?

It's a way of telling computer what to do.

Kind of obvious, right? Let's go a bit deeper: how do you do that?

By using a programming language like Java.

Correct! Well, mostly. That's because a computer, or rather a CPU, doesn't understand language as you understand it. It doesn't matter if it's Python, Java, C or Assembly, a CPU doesn't understand what you are writing. What does the CPU understand then? 1s and 0s. And it's not even a word function represented as 1s and 0s, the CPU does not have a concept of function or class, or any keyword for that matter. What we, the programmers, understand as a "programming language", is soooooooo far from what actually happens, that it's really hard to imagine it.

And that's mostly ok. You don't need to understand how circuitry works to be a good developer, however, you should be aware of how much extra work a CPU needs to do in order to interpret high-level programming language, and how you can write code that's easier to process by CPU.

You might think that compilers should take or of that, but compilers are simply translators. Much like CPU, they do not understand what you want to achieve, they just process text. Of course, there are some optimizations that they can do, but they will not rewrite your code to 100% efficiency, not even close.

In order to understand why though, we first need to understand:

What does the CPU do, actually?

At the core of it, the CPU only does few things:

binary operations,
math operations,
reading from memory,
writing to memory.

That's mostly it. If you are interested, you can check the Intel 8086 Assembly Manual. It's old, yes, but:

the CPU didn't change that much in terms of what it basically does, the instructions you find in there are still present in the modern CPUs,
thanks to being limited to 8086, it's easier to wrap your head around it, since compared to modern ones it's quite simple.

In order to perform those operations, the CPU has to somehow store values in needs to operate on. For that, it has internal storage, called Registers, you can see it in the Manual at page 24. Each register in 8086 has 16 bits (modern CPUs have 64 bit registers). Which means that an 8086 CPU can operate on chunks of data that are at most 16 bits at a time. That's 2 bytes.

Think about that for a second.

In a world where we operate on whole objects containing various data, how does a CPU handle that?

That's quite a jump in perception, isn't it?

Memory

We now know, that CPU can only operate on very small data chunks, which are stored in memory. So, what does a memory look like?

You can think of memory as a huge array of bytes, like this:

Each byte has unique address (12345 - 12351 in the picture), and holds, well, single byte. What happens when data occupies more than 1? It just spills over to the next one and it can occupy as many as it needs, provided there is enough space, of course. For example, string "Hello" would be stored like this:

The \0 character denotes end of string, otherwise we would never know where to stop when reading it.

That's it. At the lowest level, that's pretty much how it looks like, just an array of bytes and a piece of hardware that moves it around.

Even given, that it's a simplified explanation, that's not a lot to work with, isn't it? And yet, we somehow create very complicated programs that do amazing things.

I will only mention, that the bulk of the job is done by compilers (we will learn about them) and hardware. In the future we will take a look at how hardware communicated - how a monitor knows which pixels to light up, how a network card knows when to send data, etc, but for now let's stay in software realm.

Let's look at the other side of programs now - programming languages.

Types of Languages

There are few ways to categorize programming languages. For the purpose of this series, I will categorize them like this:

Interpreted - like JavaScript or Python. Meaning, you just feed what you wrote directly to interpreter,
Virtual machine languages - like Java. Meaning you still need to compile it, but you feed the compiled code to VM.
Compiled - C, C++, Odin. Languages compiled to machine code for a specific system and CPU architecture.

These are the 3 things I will cover: language interpretation, VMs and machine code compilation. Again, this will be simplified version, which is supposed to give you an idea, not a complete solution.

Basic flow

For interpreted languages, the flow looks like this:

For VMs and Compiled languages it's actually not that different:

Each step can be further divided, but we will talk about that in separate articles. For now, let's just say that whether it's interpretation or compilation, the first step is parsing.

This looks relatively simple, and it mostly is. It's not that hard to interpret:

int c = a + b;

The tricky part is how do we represent something like this:

public class Test {
    private int x = 3;

    public int multiply(int y) {
        return y*x;
    }
}

Test tester = new Test();
int result = tester.multiply(7);

In the memory and CPU instructions?

Spoiler alert: the class does not exist

Summary

That was a very brief and (hopefully) simple explanation of what the CPU actually does, and it showed the gap between the CPU and what we write. In this series I'm hoping to close that gap just enough for every developer to have a general understanding of the whole process, as I believe it will benefit us in the long run.

From the next article, I'm going to explain how it's done from the top in much more detail, starting with parsing.

I hope this article piqued your interest and you learned something interesting 😃 See you in the next one!

Java Benchmark Adventures - ArrayList vs LinkedList

DigitalCrafting — Sun, 04 Feb 2024 16:01:33 +0000

Classic interview question:

"What is the complexity of ArrayList vs LinkedList?"

Usually answered with something along the lines of:

"Removing items from LinkedList is O(1) while ..."

And that's probably it, however, this doesn't reflect the actual performance of them, and it may lead to a substantial slow down in your code.

But before we get to that, let's discuss some important implementation details for ArrayList and LinkedList in Java. Keep those in mind when looking at the benchmark results.

The Implementation Details

ArrayList

It uses primitive array underneath to store values,
Primitive array is stored as a continuous chunk of memory.

LinkedList

Each element holds value and reference to next and previous element,
It holds references to both first and last element of the list,
It optimizes get by index: if the index is less than half the size, start from the beginning, else start from the end,
Elements are scattered around the memory.

The Benchmark

You can see the code for the benchmark in this repo. I used objects instead of usual integer just to have something looking a bit more like a real world example, and I used JMH for benchmark.

Test cases are what you would expect in a normal project:

findByReference
getByKnownIndex
iterateOver
removeByKnownIndex
removeByReference
addFirst
addInTheMiddle
addLast
removeFirst
removeInTheMiddle
removeLast

The benchmark creates 2 Lists with 1 million objects each, LinkedList and ArrayList, we also store reference to one of the objects in each List, from around the middle.

My laptop is IdeaPad Gaming 3 15IMH05 with Intel i7-10750H (12) @ 5.000GHz and 32GB of RAM. I run Azul Zulu 17.0.6 Java.

So, what are the results? On my laptop they came to:

Benchmark                             Score          Error  Units
arrayList_findByReference       2696499.728 ±    32202.502  ns/op
linkedList_findByReference      7028258.295 ±   411854.774  ns/op
arrayList_getByKnownIndex             1.355 ±        0.020  ns/op
linkedList_getByKnownIndex     14109357.750 ±  4523485.134  ns/op
arrayList_iterateOver           4241855.707 ±    51949.429  ns/op
linkedList_iterateOver         18701734.963 ±   153427.714  ns/op
arrayList_removeByKnownIndex      23807.499 ±    22832.530  ns/op
linkedList_removeByKnownIndex  13611894.721 ±   415849.451  ns/op
arrayList_removeByReference     5446367.115 ±   116991.612  ns/op
linkedList_removeByReference   13715672.076 ±  1153278.238  ns/op
arrayList_addFirst              3220312.800 ±   428670.631  ns/op
linkedList_addFirst                8515.000 ±    24870.360  ns/op
arrayList_addInTheMiddle         815357.800 ±   282617.391  ns/op
linkedList_addInTheMiddle     142979327.200 ± 18151974.063  ns/op
arrayList_addLast                  4606.600 ±    23419.256  ns/op
linkedList_addLast                 1620.400 ±      680.293  ns/op
arrayList_removeFirst           1933858.000 ±   127364.646  ns/op
linkedList_removeFirst             5216.600 ±      713.334  ns/op
arrayList_removeInTheMiddle      824331.600 ±    53493.129  ns/op
linkedList_removeInTheMiddle  143313481.400 ± 34759711.042  ns/op
arrayList_removeLast               3943.600 ±      834.749  ns/op
linkedList_removeLast              5973.800 ±      972.878  ns/op

As we can see, in only 2 of them the ArrayList was clearly slower than LinkedList, and it was only cases at the start of the List. It was similar at the end, and in all others it was at least few times faster.

You might say: "wait, but that's not what the Big O Notation says, LinkedList should be faster in deletions and inserts", and you would be right, that's exactly what it says.

So, where does the performance hit come from?

The Reason

The Big O

The O(1) for deletion doesn't count finding the element you need to delete. Yes, the operation itself is just moving around few references, but you need to find the object first. Some articles, like this one, actually take this into consideration, however, some don't.

Overall, you need to be aware that removing references is just part of the algorithm for deletion, if you include searching, then you will come to correct O(n) value for elements in the middle of the List.

As for the last element: the performance for ArrayList and LinkedList is pretty much the same, because Java implementation of LinkedList holds references to both beginning and end by default. If, for some reason, you would use LinkedList without the back reference, you would need to iterate over the entire list to get to the last element.

However, that's still not everything.

The CPU and Caches

You've probably heard that CPU has Caches - L1, L2, L3 and sometimes even L4, then there is RAM and finally disk. It looks (in great simplification) like this:

When you want to access some data in your program, like iterate over an array of elements, it is loaded into the CPU Cache for quick access. The arrows on the diagram show order in which the caches are checked for the data, if it's found in L1, great, if not go check L2 and so on, until finally it checks the disk.

What helps with loading data into caches is Cache Prefetching, but that in itself is not important for us.

The important bit of information is this: the prefetching is optimized for continuous memory access, so that it can load entire array at once, if it fits into to the cache.

Focus on the word: continuous.

Array is stored as continuous block of memory, and CPU is optimized for continuous memory access.

Here is another important piece of knowledge: accessing RAM can be 10 to 100 times slower than accessing cache.

That's the whole trick.

Since LinkedList can be randomly scattered around memory, there is no way to load it into the cache at once. You need to first get an element and check the reference of next one before you can get it. Each element has to be accessed separately, 10 to 100 times slower than the elements in ArrayList.

That is the reason for performance difference.

Is LinkedList useless then?

No. There are cases where LinkedList would be better. From the top of my head: double-ended linked list can be used as a queue with unknown number of elements, in fact a Deque is exactly that. Thanks to having references to both beginning and end, you add elements at the end, and remove at the front with the performance promised by Big O notation.

Summary

The biggest lesson here, at least for me, is to remember that the programs we write are executed by the CPU, and we should not forget that. Understanding what happens in the CPU, even generally, can be very valuable. I might not know how the prefetching works, but it's enough to know how it affects my program.

The other take from this is that ArrayList should be used pretty much everywhere by default, unless you have specific requirements that would benefit from LinkedList.

Hope you found this article useful :)

A Journey to Prevent the Collapse of the Web

DigitalCrafting — Tue, 30 Jan 2024 09:23:54 +0000

This article is an introduction, or rather, a starting point to a tree of articles, that will (hopefully) explain how the software actually works from top to bottom.

Inspiration

As some of you probably guessed, title of this article is inspired by Jonathan Blow's talk Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc) on YouTube.

I highly suggest you watch it, even if you've seen it before, because Jon explains everything much better than I ever could in an article.

Here is the gist of it: civilizations collapse, when there is no longer transfer of knowledge between generations, causing younger people to not understand how things that they are using work, and when those things break, they are unable to fix them and so the collapse happen.

Jon also gives a number of examples of software failing as a proof of there being something wrong with software development nowadays, and they are spot on.

Second talk that inspired me is The Thirty Million Line Problem by Casey Muratori (actually, the first 0.5h mostly).

In this one, Casey focuses on where the current problems with software come from, giving an excellent hypothesis on the origin of said problem.

The gist of it being: when the USB and "Plug and Play" was introduced, it became the OS's responsibility to handle all different kinds devices that could now be plugged into the computer, which caused exponential increase in the lines of code in the OS, which spilled over into other areas, which causes people to not understand what is happening in the said systems, as there is simply too much code to allow anyone reason about it. They can reason about part of the code, but it's unlikely they can reason about everything. And if you can't reason about it, it's effectively a magical black box that hopefully works fine if you just leave it alone.

These 2 are the videos that sparked my interest and pushed me into learning in depth about how software actually works, and how can we minimize the number of Lines Of Code (LOC), which I would like to share with you in the future articles.

The Problems we face

Moore's Law is dead

Transfer of knowledge and the number of LOC come from the fact that we, programmers, became too comfortable writing code that is nowhere near what actually happens on CPU and the reason for that is the Moore's Law.

In short (and simplified): the speed of processors doubled every 2 years or so, RAM improved, and we could get away with getting more and more away from the actual hardware, because it could compensate for abstraction. And so, you didn't have to allocate memory manually - there's VM and Garbage Collection. Then you didn't even have to worry about types - you have dynamically typed languages like Python and JS.

Here's the thing though: this law is dead, and has been for quite some time. The CPUs are not getting any faster, and to battle that they got more cores now, but they are not faster. And since most of programs are still single-threaded, that doesn't help anyways. However, it looks like software development didn't caught up onto that fact. We keep creating more and more complicated frameworks, which abstract away many problems but introduce other ones. The software is not getting better, in fact, we might be regressing in some areas, not every area, but most of them.

The websites are slow as hell, backend systems fail with cryptic messages, Windows update forces itself onto you, "smart" phones are getting slower with each update forcing you to buy new phone, the same with "smart" TVs. And these are just the things you probably experienced yourself, there are also fails we will never hear about, because they're just too embarrassing for the companies, like failures in the plane software.

It's also kind of interesting that we all experience those things, but we're so used to it, that we just go "Eh, let's buy newer faster phone/laptop/pc", "Let's refresh the page and try again", "Let's restart the system", and I was like that too. It wasn't until I saw Jon's video, that I actually stopped thought about it, and decided that that's actually pissing me off quite a bit.

Companies value speed

Another problem is that companies, especially startups, value speed over quality, at least until it comes back to bite them in the behind. And it will come to bite them, but it's usually too late to quickly switch framework or programming language.

It might not be apparent right away, after all, you build a new app and it's great - it's fast, easy to manage, what not to love?

Well, until it grows and you need to scale up. Suddenly, Python or JS is not enough, but you are not going to rewrite it in C or GO, right? Microservices are a solution for scaling, or at least, that's what you were taught so far, so you do that, and then it becomes a nightmare to manage. You introduce Docker, K8S, you suddenly loose ability to debug whole process easily, changing anything at all becomes super hard and the spiral of death starts.

And it's not my imagination, I've seen this. This is how it goes when you start with a programming language that is easy and quick to write in, and it grows faster than you anticipated.

Casey Muratori in yet another video gives examples of when companies actually cared, however, it was usually a large company that could afford it.

The Stack

There is a quote I once read and it stuck:

Fullstack is not an achievement, it's a minimum f*****g requirement

And I think it should be a standard, but how can it? The minimum requirement for a job went from algorithms and a programming language (+ css in case of frontend) to a whole stack of stuff built on top of another stuff. Let's try to list what a Fullstack position would require nowadays, shall we?

Angular/React, Typescript, NodeJS, UI library, Websocket, REST, gRPC, Java, Spring BOOT/Micronaut, JPA/Hibernate, SQL database, NoSQL database, Docker, Kubernetes, AWS/Azure/GCP...

And probably something I forgot about. That's around 15 things to grasp. Even if you combine backend and frontend to just using Javascript, it's not feasible for anyone to learn about anything deeper than just using those things in less than a few years. And I'm not even talking about memory management, I'm talking about things like all the possible HTTP Headers you can use, and what you would do with them, or lesser known classes in Vanilla Java.

Getting the knowledge is kind of hard

The videos or articles I usually see on YouTube or LinkedIn are targeting Junior Devs. It seems like every month I see the same articles shared again and again: "How to create CRUD application in Spring BOOT", "How to handle errors in Spring BOOT" and similar in other frameworks/languages. How many times are going to repeat the same stuff, instead of going forward?

Don't get me wrong, there are people with the knowledge willing to share it, there are videos, articles and books, that explains how software works, however, what I found is that there is no single resource that would explain it in relatively simple terms, from top to bottom. Meaning, if I write code a certain way, how does it look on the CPU and in the memory? All the resources I found either explained only one small part and left it at that, or were a full fledged books with intricate details right from the start, which took way too much time to go through for someone like me, who likes to learn by example, get a general understa and get the details later.

So, what now?

Well, first of all, start with yourself. The title of this article doesn't contain word "journey" just for show. All these issues that I listed, bothered me greatly. The videos I posted at the beginning, launched me on a journey to understand how software works, and the last problem I listed gave me an idea to create something like this myself.

I already implemented a simple language parser, interpreter and VM. I wrote a disassembler for Assembly 8086 and very simple 8086 CPU simulator, and tried to learn many more things, which was quite a journey. And it's still going.

What I found out is:

It's way easier than you think

It's just a bit tedious sometimes, and developers hates tedious. But it's also rewarding, by understanding how things work, you will be able to make a better decisions.

A quick example: LinkedList vs ArrayList in Java. Which one to use? Text-book answer would be that LinkedList is better if you add and remove a lot's of elements, however ArrayList is better if you mostly iterate over it. However, that answer only takes into consideration the Big O notation and not what actually happens on the CPU. If you dig a bit deeper, the ArrayList is usually the best solution, and it's because of how CPU accesses data.

Performance awareness

There are a number of resources you can use to learn about internals of programming, but the one that gave me the most, is this one: Performance-Aware Programming Series by Casey Muratori. It's unfortunately paid, but the money is well worth the content, especially because Casey gives a very detailed explanation of how CPU works and gives excellent examples to get you started.

I actually learned Assembly 8086 from this course, and it was super easy thanks to Casey's explanations.

The articles

I will try to write a number of articles which, hopefully, will provide people with useful insights into how the software works and how to use this knowledge in everyday programming life.

I will update this section with articles as I go, there will be few different topics, including:

How programming works top to bottom
How to implement stuff from scratch (HTTP Server, DB, etc)
Performance benchmarks and explanations of different structures/programming styles (this one in Java mostly)

As I am a Java and Angular developer mostly, most of the code will be written in, well, Java and JS :) with some addition of C, C++ and Assembly when needed.

Also, note that my explanations will contain many simplifications. It's not feasible to write every single detail accurately, and it's not even that useful, since we tend to forget details anyways. I'm aiming this articles at web developers, both backend and frontend, so that they can get a better understanding of what they're actually writing, and maybe think if it's worth it before jumping onto the next new and shiny thing :)

Happy reading! :)

Java Benchmark Adventures

ArrayList vs LinkedList

Programming from Top to Bottom

The Basics

Let's create microservices system from scratch - post mortem

DigitalCrafting — Tue, 02 Aug 2022 12:08:57 +0000

The last part of this series was posted almost 1.6 year ago and I am way overdue with the post mortem. So, what happened?

I tried to bite more, than I could chew.

That's pretty much it. It's not going to be another 10-minute long story about that. Instead, I have 3 simple things I learned:

1. Start simple

Instead of going straight to microservices, start with monolithic application first, and then expand it as needed. This would apply well in your professional job as well.

Since this series died, I actually completed another project doing exactly that - started with monolith, and when the functionality was done, I split and refactored the code.

2. Do small increments every day

If you want to finish a project, don't do marathons on weekends, instead, force yourself to do at least a single commit every day. It doesn't even have to be a big one. I had commits where I just renamed a class or moved it to another package. Focus on one step at a time, and before you know it, you will be done.

3. Focus on a single technology

My initial idea was to try writing microservices in different languages since this is one of the big selling points of that architecture - you can have as many different languages interacting with each other as you need. While this might be a good idea on paper, in practice it's unmaintainable (this point comes both from this project and my job experience).

While the languages themselves are not that hard to learn, the frameworks and ecosystems are a nightmare. Each has a different toolset, different philosophy behind them, and different problems they come with. Avoid that as much as you can.

Additionally, if each team uses different technology, you can't just switch teams if you are bored or exhausted with your project - you have to look for another job. You also don't have anyone, besides your teammates, who can take a look at a problem with a fresh eye and ideas.

As mentioned before, this failure was not in vain, as I actually created and finished another project, about which I will talk in another set of articles.

I hope this post will help someone finish their project :)

Let's create microservices system from scratch - part 4

DigitalCrafting — Sat, 20 Mar 2021 15:18:26 +0000

As stated in the previous article, this one will be more of an overview about testing the microservices. As it turns out, this is equally if not more complicated than managing them and took me quite a lot of time to go through various articles and YT videos, but in the end, it boils down to few simple steps.

First things first, we can just ignore unit testing for now since this is done on a single class/method, as well as System/UI testing since this is usually done on the whole system and there is no debate here - you start the whole system and test it end to end.

The type of testing that is a bit tricky in microservices is intergration testing which should test interactions between the components of the system, in our case - between the services, and that's where the trouble begins.

The problem

The problem is with setting up the testing environment for integration tests. Since we should test only specific interactions there is no need to run everything, especially locally on your own machine. We should just start some of the services - but which of them? How much of the environment do you need to successfully test some features? And in the case of The One system - how much do you need to run in order to test if API Gateway works properly?

The approach

The step-by-step approach is crucial here - yeah, I know, obvious, but I've seen people doing everything at once more than a few times. So, without further ado, here's what my approach is right now.

Ask yourself some questions

Which feature do we want to test?
Which services are needed to run?
Do we need a database to run?
Which services do we need running and which can be mocked?
Which database do we need running and which can be mocked?

These are the first questions, you should ask yourself to determine the next steps.

As an example: in The One project, we want to test, whether the proxying requests work properly. The answers to the above questions will look like this:

Proxying request to correct service,
API Gateway, Service Discovery, one of the business logic services, let's say, User Service,
No,
Two-part answer:
- Need Running: API Gateway, Service Discovery
- Can Be Mocked: User Service
Not applicable

Determine the environment you need

So, we need 3 services running, 1 of which can be Mocked or Stubbed. Since at the time of writing this article, the User Service doesn't have any actual logic in it, we could just start it, but, to humor ourselves, let's pretend it already has database connection and complex business logic and we need to somehow mock that.

The additional questions to ask yourself would be:

Mock or stub the service?
Mock or stub connection to DB or the whole DB? (ask only if we need DB)

Stub vs Mock

As for the difference between the Mock and Stub, I find this StackOverflow answer very helpful. As I understand it:

Mock - the response from mock is configured and can vary between runs (like in Mockito)
Stub - the response is hardcoded and always the same

Stub

So, as I see it, if you decide to use Stub, you essentially need to create a second service with the same API and hardcode the responses to always return the same data. In a monolithic application, you would just create a second implementation of an interface, in the case of microservices, I would suggest creating a second microservice or adding a profile to the existing one. Each approach will have its own benefits.

If you create a second service:

it will be lightweight, with no if statements to determine what to do,
the original service will be unaffected, no redundant code in production,
but you will have to support two implementations in case of refactoring.

If you just add a profile:

no need to support two implementations,
you can have stub implementation right next to the actual one,
but testing it will be a bit slower since you will have more code to start.

Mock

Mocking will be primarily used in the test file itself, you will basically say:
When I call method X with these parameters, I want that response

For Java, the most popular library is Mockito which is easy to use.

In the case of our example, if we wanted to test only the proxy, we would mock the call to Discovery Service and check if proxied request points to correct ip, but I think it's pointless to test it that way. I want to know if User Service registers itself with Discovery and will be available through Gateway.

Database

As for the database, you can also Mock it, Stub it, use Test Environment Database or provide an instance for the duration of the test only. I would suggest avoiding Test Env DB if you can do that because it is usually used by the QA team and may be unstable.

The rule of thumb for DB will be:

if you need only to get values from db - Mock or Stub the methods called on DB,
if you need to check how different services transform the data in DB - provide special testing DB if you can, if not, use Testing Env DB

Implement it and run it

The last step is to implement what you decided on. Create testing docker-compose.yml, mock or stub services, provide database if necessary and run the tests. I will do that in the near future, but one idea is to create another Java project which will only contain integration tests.

Summary

Testing is huge topic which adds another layer to already complex topic of running and managing microservices. I hope this overview will be of some help in your projects.

Let's create microservices system from scratch - part 3

DigitalCrafting — Tue, 16 Feb 2021 16:11:19 +0000

In the last article we decided that the most important thing while developing microservices system is to have a good way of managing and running them.

After that, the first feature I wanted to implement was to create proxy and service discovery mechanism. How would that work ?

The first to start should be discovery-service which will hold the list of available services and their location,
After discovery is started, all other services should start and register themselves with it using REST Api,
Requests to the services will go through api-gateway which will query discovery for the location of the service and then proxy the requests.

Sounds simple, and the actual implementation is, but there are a few things that needed to be done before I could finish it:

Create Rest API standard to follow,
Control startup order,
Tell each service where it is,
Connect services to each other,
Be able to test it, which is the reason we need to #6,
Refactor the CLI

Let's walk through them.

REST API standard

For our proxy to work, it needs to be able to somehow connect the request to a specific service. We should also consider the versioning of our services. What I came up with for root URI is this:
GET /api/<service-name>/<version>
In example:
GET /api/user/v1

Which is pretty straightforward, the gateway can just split request URI by / and use the second value to determine the target service.

As for versioning there are actually few methods to do this:

through URI path (that's what I did)
through header of a request
through query parameter
through content negotiation

While #2 is probably more correct from a RESTful point of view, I feel that #1 is more natural and easier to implement. As for the others, I didn't even consider them as they seem weird to me.

This is by no means the complete standard, just something to let me finish current feature.

Controlling startup order

While this feature is available from docker-compose.yml configuration it doesn't work as expected because it waits for the container to start and not the service.
Pretty neat solution is to use bash script and curl to determine whether the discovery-service is up or not. If yes, then we can start other services.

The discovery-service URL will be different on localhost and in docker-compose so, for now, I created 2 different scripts with different URLs (yeah, I know, I could use one and pass parameters, but the problems were piling up, so I just used what works for now, I will refactor it later) which will be copied to a correct place by CLI when building the project using:
theonecli (local|docker) build

The script itself is rather simple:

serviceUp=false

for (( i=0; i<10; i++ ))
do
  if $(curl --output /dev/null --silent --head --fail http://the-one-discovery:8081/discovery/v1/)
  then
    serviceUp=true
    break
  else
    echo "Service not up - try $i"
  fi
  sleep 2
done

if [ $serviceUp == true ]
then
  echo "Service is up - starting command"
  exec $@
else
  echo "Service is unavailable"
fi

And the example usage can be look up, for example in the user service Dockerfile.

Services location

This is actually something, that would be done by administrators. Each service should have it's own IP and PORT, which should be passed to them via config file. They should also know the location of the discovery-service, which will be one of the few that have not dynamically assigned IP, but a static one. I did that by extending the config files from previous article.

Interservice communication

This part is actually the easiest one. On localhost the services are available, well, on localhost so the only think we need to do is to assign different PORT numbers.

When using docker-compose.yml it's almost as easy - we just just need create internal network in the config file:

networks:
  the-one-network:
    driver: bridge

and specify this network, as the one, each service belongs to:

the-one-user-service:
    build: ./python/user-service
    container_name: the-one-user-service
    ports:
      - 8083:8083
    networks:
      - the-one-network

Testing the proxy and discovery mechanism

Now, that's where all the hell broke loose when I started developing this feature. As it turns out, testing microservices is the second biggest obstacle right after managing them and there are some solutions to consider but I'll leave that topic for another whole article. Suffice to say, there is no easy way to do this, and the most complete approach would be to start everything you need to and test it then. In my case, I need to start 4 services:

discovery-service
api-gateway
user-service
outpost-service

And check if user and outpost are correctly registered withing discovery, and if the api-gateway correctly proxies the request. That's when I realized that my CLI Tool is not good enough to actually do this and I had to refactor it. After that, I simply run:
curl localhost:8080/api/user/v1
and checked if the response is what I expected. This is by no means sufficient testing strategy and I will work on that.

Refactoring the CLI

First of all, I decided to move docker-compose functionality to docker command in the CLI, meaning, when typing:
theonecli docker start
we will actually start docker-compose.yml configuration. After killing it, we have to call
theonecli docker stop
and there is no option to run individual docker images right now. After that, I also had to:

fix the build process, so that wait-for-service.sh script will be copied into correct directory of each serivice,
change the Dockerfiles so that the services start in correct order
fix starting multiple services on localhost by spawning new gnome-terminal for each service

After all that, we end up with 2 levels of configuration files:

project level
service level

On project level we have the wait-for-service.sh scripts for each environment and on the service level we have service specific configurations, again, for each of our environments. Right now we only have 2 environments and it will probably not change, since it's only personal project and not a commercial one, but we can already see that the amount of configuration needed for running this project is going to bubble up, especially when we add databases and UI application.

Summary

All of that took me waaay to much time to finish, but, I'm learning about these challenges right now 😉

This article was more of a log of what happened, the next one will be more theoretical, probably about testing options for microservices.

I hope this article will be of some help, and will let you avoid some problems with your projects. Current version is available on my github, feel free to download it and try it out.

Let's create microservices system from scratch - part 2

DigitalCrafting — Mon, 18 Jan 2021 10:02:01 +0000

We ended my previous article with a basic architecture diagram as well as a tech stack which we want to use and a rough idea for the first milestone we want to achieve.

Having that, I happily started coding. Created basic REST Apis for few services (just "I'm alive"), dockerized them and even connected Gateway to Service discovery using docker-compose which was pretty easy. But that's not what we are going to talk about in this article. We are going to talk about something that I feel is not stressed enough when talking about microservices - how do you manage them?

Granted, for some of us developing services, there will be whole another team of DevOps Engineers managing and running everything BUT there is still an issue of testing this thing locally.

For some reason I thought that simply using Docker will solve all my problems. Boy, was I wrong.

The problem

The problem lies in the number of things you need to do to start even the simplest test case. Suppose we need to start just 2 services connected to each other using Docker, say api-gateway and user-service, for each of the services we need to:

Remove old docker image
Rebuild the service
Rebuild the docker image
Start the docker image

Which means 8 steps for 2 services. It gets worse if you forget to run docker image with --rm flag set - you will have to clean up the docker containers (unless you force clear everything later). Also, step 1 is required because docker image is rebuilt when it detects the changes to Dockerfile which will not happen if we only rebuild the app. Even with Docker-compose, the remove old image still applies since, at least for me, Docker-compose will sometimes not pick up changes.

With 3 services it becomes unbearable and we start to create some scripts to ease the task. And so, we create the script, and then another, and another... After a while, there comes a problem of running these scripts one by one which basically means we are back to square one, only this time, we run scripts and not individual commands. Then we write scripts to run other scripts... and suddenly! A lightbulb moment! We should create a CLI Tool! And that's what I did.

The solution

The CLI Tool will allow us to run everything from terminal, but we need to take it into account when designing the architecture of each service. In order to do that, we need to back up a little (not too much fortunately, we didn't write that much code yet) and design a proper structure for our services so that we can easily add new ones in the future.

As for how do we design it, there are few questions we need to answer regarding the CLI:

What do we need the CLI to do ?

Rebuild the projects and docker images
Run the projects and docker images
Run Docker-compose configurations

Simple enough.

What do we need in order to be able to do that ?

Well, it might depend on your needs but since services can be build and deployed individually by different teams (that's the whole point, really) I came up with following list:

build script for each service
start script for each service
Dockerfile for each service
docker-compose.yml files to run different configurations

What environments are we going for ?

Now, we actually have 2 environments we want to build for: local and docker, for my project both will be build with dev configuration. To achieve that, I'll use profiles (like maven profiles):

dev-local
dev-docker

Which will determine what properties are going to be used in our services.

Project directory structure

Having decided on that, it's time for the services folder structure. Ultimately, the structure I went for looks like this:

The first level is language directory. It serves as the root for the projects in that language, thanks to which all python services will use one virtual environment, java services will have common pom.xml and so on.

The second level is the service itself, containing Dockerfile for each service, since that is the standard.

The third level are the directories:

src which contains the source files of the service
scripts which contains build.sh and start.sh scripts for each service

Each script will handle the profiles on its own, the profile will be passed as a parameter, ex:

build.sh dev-local

Having that out of the way...

In what language do we write the CLI ?

My first thought was to simply do it in bash scripting language since it comes by default in linux but, ultimately, I went with mix of bash and Python with click library. Python also comes with linux nowadays (at least with most popular choices) and it only lacks the click library, which is easily installed using pip.

Most of the CLI will be written in Python for ease of writing and the simple start and build scripts will be written in bash.

These are the sources I used to write a simple CLI:

pymbook
click website
plus occasional google search which usually led to concrete subpage of click website
and of course bash tutorials

What the interface will look like ?

It can be done in a various different way, what I settled for, for now, is something similar to docker commands. I divided the CLI into 3 major commands, each with subcommand:

local (build|start) (--services|-s) SERVICES
docker (build|start) (--services|-s) SERVICES
docker-compose
- start - for now it only runs docker-compose up
- stop - for now it only run docker-compose down

For the version 0.0.1 of the CLI, I left the services config inside the script but I intend to move it to some json or yml file in the future. And, of course, the division I did might change in the future.

The source code for the CLI can be seen here

Summary

If you decide to move from monolith to microservices, before you start coding, think how are you going to build and run them, both locally and to production. Thinks of it as the foundation of the whole architecture. Without it, the number of microservices would soon make the development unbearable and the project would crumble.

Hope you enjoyed this one and that it will help you 😉
The source code for the whole project is on my github. See you in the next part.

Let's create microservices system from scratch - series intro

DigitalCrafting — Tue, 12 Jan 2021 17:33:13 +0000

Intro

Well, the title seems like a bold statement, so let's clarify what I mean by microservices system. I do not mean a framework of any kind to be used in production, only a project to learn about the challenges of the microservices architecture and how it might work under the hood.

I do not intend this series to be step by step guide since it would probably be at least 100 articles long by the end. I will, instead, try to write about design choices, how to write some of the mechanisms and highlight some interesting problems (from full stack developer point of view) I stumble upon along the way.

What are we building

First of all, what type of system are we aiming for ? This will determine what kind of services we will need, as well as non-functional requirements of the system.

Recently I've been playing Middle-earth: Shadow of War and I thought to myself: why not create management application for the Saurons army ? Hence the idea for The One System to Rule Them All (The One for short). Then I decided to turn it into a learning experience and so I will not limit myself to Java and Angular which I know, but will also try to learn other languages along the way.

Technology stack

The technologies I intend to use and learn at least the basics of, are:

For services:
- Java (Zulu) and Spring BOOT (there is a limit to what I can write from scratch ;))
- Haskell - because I never used Functional Language before
- Python - because it's widely popular
- GoLang - because why not
For frontend:
- Angular for the UI
- Java (Zulu) and Spring BOOT for the server side
For deployment:
- Docker and Docker-compose
Architecture pattern:
- Microservices for the services
- SPA for frontend

Now, having decided that for a start, are we going to use libraries such as Netflix Hystrix, Ribbon ? Are we going to use RabbitMQ ? Well, no. Since this is a learning experience, we will try to implement it ourselves. It may not end up being the best code ever, but it will give us overview of how this libraries are implemented which in turn, can help us debug or implement other solutions better in the professional life.

The architecture (v0.0.1)

Ok, having more or less decided on the tech stack, we now need to design the actual architecture. The One is basically a resources management system where the resources range from uruks through the outposts up to the food chains and weapon storages.

Every management system needs to have some kind of users database to allow access control, authentication and authorization services and UI app to allow user friendly access. But since the chosen architecture is microservices, we cannot simply write one Spring BOOT app and be done with it, we also need:

API Gateway to connect to different services
Service Discovery to allow us dynamically starting and stopping services
Logger Service to aggregate logs from every service
Service monitoring
And a few other things

The basic diagram will look like this (I omitted some things in order to make it a little smaller):

It may seem like it won't be much work - and normally in a company it probably wouldn't - but we are going to build this from scratch, therefore, the first milestone will be:

Create API Gateway Service, that proxies requests to User Service, to address obtained from Service Discovery.
User Service and API Gateway will wait for Service Discovery startup before starting themselves.
After startup, User Service will register itself with Service Discovery, passing the IP and PORT on which it's available.
There will be script to build and run everything either locally or using docker.

Summary

I think the milestone we've set for ourselves is relatively easy but will be a bit challenging to implement from scratch :) See you in the next part.

Here's the repo for this project. Feel free to copy it and tinker around :)

A case for extending Angular Forms - part 5

DigitalCrafting — Wed, 18 Nov 2020 13:10:57 +0000

Intro

In my previous article we changed the reset() methods of angular forms and added clear(). This time, we are going to differentiate the user input from the programmer (or code) input.

The how

We have actually two options to do this, both of them require adding at least one new method which we will call: setControlValue() since we will be changing the FormControl value:

Add another method setInputValue() which will signify that the input has changed
Use existing setValue() as the one for the user input

Since the first option is only viable if you, for some reason, separate input from the forms, we are going the second path which is also easier to implement.

In the setControlValue() we will enable setting the value even if the control is disabled, because sometimes it's nice to have. We will also use the setValue() method to change the internal value but we will not trigger the valueChanges event unless programmer wants it. Hope this becomes clearer with the implementation.

Implementation

Similarly to previous functionality, we first need to declare extra method. We will do that in the AbstractControl for compatibility with formGroup.get() method, and in the FormControl for actual functionality:

declare module "@angular/forms" {
  interface AbstractControl {
    ...
    controlValueChanges: EventEmitter<any>;
    setControlValue(value: any, options?: {emitEvent?: boolean, emitValueEvent?: boolean});      
  }
  interface FormControl extends AbstractControl {
    setControlValue(value: any, options?: {emitEvent?: boolean, emitValueEvent?: boolean});
  }
}

In the AbstractControl we initialize the EventEmitter and just proxy the setControlValue arguments to setValue for compatibility:

AbstractControl.prototype.controlValueChanges = new EventEmitter<any>();

AbstractControl.prototype.setControlValue = function (value: any, options: { emitEvent?: boolean, emitValueEvent?: boolean }): void {
    let opt = options ? {emitEvent: options.emitValueEvent} : null;
    this.setValue(value, opt);
};

And in the FormControl we actually implement the desired functionality:

FormControl.prototype.setControlValue = function (value: any, options?: { emitEvent?: boolean, emitValueEvent?: boolean }): void {
    if (this.disabled) {
        this.enable();
        this.setValue(value, {emitEvent: options && options.emitValueEvent});
        this.disable();
    } else {
        this.setValue(value, {emitEvent: options && options.emitValueEvent});
    }
    if (options && options.emitEvent) {
        this.controlValueChanges.emit(value);
    }
};

And that's it. We now have an option to override user input even for the disabled control.

Conclusion

This concludes this series. During just few articles, we have extended the Angular Forms quite a bit. We can show and hide controls from a single place (and also do not consider hidden controls for validation), we can reset the control to default value or clear it completely, we can determine whether the value change came from user input or from our internal logic. And it wasn't even that hard when using prototype.

Obviously there might be some corner cases which I forgot about and it needs a lot more testing, especially automated, but otherwise, it works.

Hope this series will be of use to you and that you learned something new along the way :)

A case for extending Angular Forms - part 4

DigitalCrafting — Mon, 09 Nov 2020 12:36:12 +0000

Intro

Previously we added visibility to AbstractControl, but, we are missing one crucial part - treating hidden control as VALID. After that we will add another missing functionality: defaultValue and clear() method.

As always, full code examples are on my github.

What I also forgotten before is that in order for our application to apply all this changes, we must import our file in app.component file as such:

import "../../../core/forms/dc-forms";

Handling hidden control

As it turns out, this part is the easiest one by far. We simply need to if statement in updateValueAndValidity method:

AbstractControl.prototype.updateValueAndValidity = function (opts: { onlySelf?: boolean, emitEvent?: boolean } = {}): void {
    ...
    if (this.visible === false) {
        (this as {status: string}).status = 'VALID';
    } else if (this.enabled) {
        ...
    }
    ...
}

Note that we add the if (this.enabled) as an else to our if because there is no need to run any validators on a hidden control.

Default value

When we first create FormControl we can pass options to contructor, either as a initial value or value and other parameters. So why isn't this value treated as default when we reset the control? This only makes sense in the FormControl so we will not do it FormGroup and FormArray (but of course you can).

First, we declare another interface in our augmented module:

declare module "@angular/forms" {
    ...
    interface FormControl extends AbstractControl {
        readonly defaultValue: any;
    }
}

And then, override the _applyValue method, adding another line just below the visibility handling from previous article:

(this as {defaultValue}).defaultValue = formState.value;

And that's it for storing the defaultValue. Now we can enhance reset() and clear() methods.

clear() and reset()

For compatibility, clear and reset will be declared both in AbstractControl and in FormControl interfaces:

interface AbstractControl {
    ...
    clear(value?: any, options?: Object);
    // @ts-ignore
    reset(value?: any, options?: Object);
}

interface FormControl extends AbstractControl {
    readonly defaultValue: any;
    clear(options?: Object);
    // @ts-ignore
    reset(options?: Object);
}

The reason for different signature is that, as mentioned before, defaultValue is mainly useful in FormControl. For compatibility's sake the AbstractControl.clear() method will be declared as follows:

AbstractControl.prototype.clear = function (value?: any, options?: Object) {
    this.reset(value, options);
}

Now, for the actual functionality, we implement the FormControl methods:

FormControl.prototype._applyValue = function(value: any, options?: Object) {
    this._applyFormState(value);
    this.markAsPristine(options);
    this.markAsUntouched(options);
    this.setValue(this.value, options);
    this._pendingChange = false;
};

FormControl.prototype.reset = function (options?: Object) {
    this._applyValue(this.defaultValue, options);
};

FormControl.prototype.clear = function (options?: Object) {
    this._applyValue(null, options);
};

The _applyValue() method is basically what reset() looked liked before, so in terms of Vanilla Angular:

our new reset() method sets the FormControl value to defaultValue
our clear() method sets the FormControl value to null

What else ?

Now we can enhance our visibility functionality by:

calling clear() when we hide our control
calling reset() when we show our control

declare module "@angular/forms" {
    interface FormGroup extends AbstractControl {
        reset(value: any, options: {onlySelf?: boolean, emitEvent?: boolean}): void;
    }
}
...
AbstractControl.prototype.hide = function () {
    if (this.visible) {
        (this as { visible: boolean }).visible = false;
        this.visibilityChanges.emit(this.visible);
        this.clear();
        this.updateValueAndValidity();
    }
};
AbstractControl.prototype.show = function () {
    if (!this.visible) {
        (this as { visible: boolean }).visible = true;
        this.visibilityChanges.emit(this.visible);
        this.reset();
        this.updateValueAndValidity();
    }
};

One other thing we can do is to override the FormGroup.reset() method to account for different signature of reset() and clear():

FormGroup.prototype.reset = function (value: any = {}, options: {onlySelf?: boolean, emitEvent?: boolean} = {}): void {
    this._forEachChild((control: AbstractControl, name: string) => {
        if ('defaultValue' in control) {
            (control as FormControl).reset(options);
        } else {
            control.reset(value[name], {onlySelf: true, emitEvent: options.emitEvent});
        }
    });
    ...
};

Summary

Doesn't this look more natural in terms of usability ? We clear control when hiding it, and restore default when we show it again. Also, the hidden control is treated as VALID, hence not iterfering in the FormGroup as a whole.

In the next article, we will tackle the last shortcoming of Angular Forms: lack of differentiation between user and programmer input.

Hope you found this article usefull :)