DEV Community: Kirill Novik

Computational Prime Number Framework Proofs

Kirill Novik — Sat, 22 Mar 2025 06:43:25 +0000

This article introduces a specific way of thinking about prime numbers and twin prime pairs using step-by-step filtering methods, like using a sieve. We call this the "Computational Prime Number Framework".

Our goal is to show how defining primes based on these filtering processes leads to interesting conclusions, particularly about whether these types of primes go on forever.

Important Note: This framework uses its own specific rules and definitions. The results we discuss are based only on these rules. This isn't intended as a proof using standard mathematical methods but rather as an exploration of ideas based on computational processes. More detailed explanations and rigorous arguments are available in further readings (Levels 2 and 3).

The Basic Filter: A "Sieve"

Imagine a tool that filters lists of numbers. You give it:

A "block list" (e.g., [2, 3]).
A list of numbers to check (e.g., [2, 3, 4, ..., 20]).

The tool removes any number from the check list if it's a multiple of any number in the block list.

# This function acts as our number filter or "sieve"
def sieve(block_list, numbers_to_check):
    """Keeps numbers that are NOT multiples of anything in block_list."""
    survivors = []
    for num in numbers_to_check:
        is_multiple = False
        for blocker in block_list:
            if blocker != 0 and num % blocker == 0: # Check divisibility
                is_multiple = True
                break
        if not is_multiple:
            survivors.append(num) # Keep numbers that survived
    return survivors

# Example 1: Block multiples of 2
print(f"Sieving with [2]: {sieve([2], list(range(2, 15)))}")
# Output: Sieving with [2]: [3, 5, 7, 9, 11, 13]

# Example 2: Block multiples of 2 OR 3
print(f"Sieving with [2, 3]: {sieve([2, 3], list(range(2, 15)))}")
# Output: Sieving with [2, 3]: [5, 7, 11, 13]

Finding Primes by Repeating the Filter ("Sifting")

We can find prime numbers by using this sieve repeatedly:

Start with an empty block list [] and numbers [2, 3, 4, ...].
Filter the list. Smallest survivor is 2. Add 2 to the block list [2].
Filter the remaining numbers with [2]. Smallest survivor is 3. Add 3 to the block list [2, 3].
Filter the remaining numbers with [2, 3]. Smallest survivor is 5. Add 5 to the block list [2, 3, 5].
Keep repeating this: filter, take the smallest survivor, add it to the block list.

# This function performs the step-by-step prime finding
def recursive_sifting(block_list, numbers_to_check):
    """Finds primes by repeating the sieve process."""
    survivors = sieve(block_list, numbers_to_check)
    if not survivors:
        return [] # Stop if no numbers left

    next_prime = survivors[0] # The smallest survivor is the next prime
    # Continue the process with the rest of the survivors
    remaining_primes = recursive_sifting(block_list + [next_prime], survivors[1:])
    return [next_prime] + remaining_primes

# Example: Find primes up to 50
print(f"Found primes up to 50: {recursive_sifting([], list(range(2, 50)))}")
# Output: Found primes up to 50: [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47]

This step-by-step "sifting" process generates the familiar sequence of prime numbers.

Why This Prime-Finding Process Never Stops

A key result, similar to Euclid's ancient proof, applies here: this sifting process for primes never has to end.

Why? Because no matter how many primes you've found and put in your block list, there's a proven method (explained in more detail in further readings) to construct a number that is guaranteed to survive the next filtering step. Since a survivor can always be found, the process can always continue to find the next prime.

Conclusion within the framework: This prime-generating process continues infinitely.

Finding Twin Primes with a Special Filter

Twin primes are prime pairs separated by 2, like (5, 7) or (11, 13). We can devise a similar step-by-step filtering process for them.

Potential twin primes (except 3, 5) come in pairs like (6n - 1, 6n + 1), where n is an index number (1, 2, 3,...).
- n=1 gives (5, 7)
- n=2 gives (11, 13)
- n=3 gives (17, 19)
We create a "twin sieve" that filters the indices n.
This twin sieve uses blocker numbers derived from the pairs corresponding to previously found indices p (specifically, numbers like 6p-1 and 6p+1).
It keeps an index n only if neither number in its pair (6n-1, 6n+1) is divisible by any of the blocker numbers.

# The special filter for twin prime indices
def twin_sieve(found_indices, indices_to_filter):
    """Filters indices n based on twin prime rules."""
    if not found_indices: return indices_to_filter
    last_found_index = found_indices[-1]

    # Create block list from numbers 6p-1 and 6p+1 using found indices p
    block_list = set() # Use a set for efficiency
    for p in range(1, last_found_index + 1):
        num1 = 6*p - 1
        num2 = 6*p + 1
        if num1 > 1: block_list.add(num1)
        if num2 > 1: block_list.add(num2)

    if not block_list: return indices_to_filter

    surviving_indices = []
    for n in indices_to_filter:
        pair_num1 = 6*n - 1
        pair_num2 = 6*n + 1
        is_blocked = False
        # Check the pair (6n-1, 6n+1) against all blockers
        for blocker in block_list:
            if blocker != 0 and (pair_num1 % blocker == 0 or pair_num2 % blocker == 0):
                is_blocked = True
                break
        if not is_blocked:
            surviving_indices.append(n)
    return surviving_indices

# The step-by-step process for twin prime indices
def twin_recursive_sifting(found_indices, indices_to_filter):
    """Finds twin prime indices step-by-step."""
    survivors = twin_sieve(found_indices, indices_to_filter)
    if not survivors:
        return []

    next_index = survivors[0]
    remaining_indices = twin_recursive_sifting(found_indices + [next_index], survivors[1:])
    return [next_index] + remaining_indices

# Helper to see the actual pairs
def generate_pairs_from_indices(indices):
    """Turns indices n back into pairs (6n-1, 6n+1)"""
    return [(6*n-1, 6*n+1) for n in indices]

# Example: Find twin prime indices up to n=50 (conceptually starts with index 1)
indices = list(range(1, 50))
found_twin_indices = twin_recursive_sifting([1], indices[1:]) # Start process after index 1
all_found_indices = [1] + found_twin_indices # Add index 1 back

print(f"Found twin indices: {all_found_indices}")
print(f"Corresponding pairs: {generate_pairs_from_indices(all_found_indices)}")
# Output will show indices like [1, 2, 3, 5, 7...] and pairs like [(5, 7), (11, 13), ...]

This "twin sifting" process finds pairs that behave like twin primes according to our framework's rules.

Why This Twin Prime Process Also Never Stops

Similar to the process for single primes, this step-by-step process for finding twin prime indices (and thus pairs) also never has to end.

The reasoning is analogous: no matter how many twin prime indices have been found, there's a method (detailed in further readings) to construct a new index n whose pair (6n-1, 6n+1) is guaranteed to survive the twin sieve's filtering step. Since a survivor can always be found, the twin sifting process can always continue to find the next twin prime index.

Conclusion within the framework: This twin-prime-generating process continues infinitely. Furthermore (as shown in detailed proofs), the pairs generated correspond exactly to conventional twin primes (except 3,5).

Summary

This framework defines primes and twin primes based on specific, repeatable filtering processes ("sieves").

The process for single primes matches known primes and demonstrably never stops.
The process for twin primes identifies pairs matching known twin primes and also demonstrably never stops within this framework's logic.

These results follow logically from the way the filtering processes are defined. While this approach is different from standard mathematics, it provides a computational perspective suggesting the infinite nature of both primes and twin primes. For the rigorous mathematical details behind the "always find a survivor" claims, please consult the more advanced levels of this documentation.

Simplified Q&A

What's a sieve in this context?
- It's a defined process (like a function) that filters a list of numbers, removing multiples of numbers from a "block list".
How does this framework find primes?
- By repeatedly using the sieve: filter numbers, take the smallest survivor, add it to the block list, and repeat. This finds standard primes.
How does it find twin primes?
- Using a similar repeat-filtering process ("twin sieve"), but it works on indices n that represent pairs (6n-1, 6n+1), filtering them based on previous results.
Does this process ever stop?
- No. The core argument (detailed elsewhere) is that you can always construct a number (or an index for a pair) that will survive the next filtering step, so both processes continue infinitely.
Are the results the same as normal primes and twin primes?
- Yes, the step-by-step processes generate numbers and pairs that match the conventional definitions of primes and twin primes (except the pair (3,5) for twins).
Is this a standard mathematical proof?
- No, it's a proof based only on the specific rules and definitions of this "Computational Prime Number Framework". It's an alternative way to explore the ideas.

Building a legacy-proof app

Kirill Novik — Fri, 31 May 2024 06:47:50 +0000

Introduction

In the previous articles, I shared some insights regarding why UI projects tend to become instant legacy.

Everything was boiled down to two core needs: instant feedback and proper design patterns. Where, in terms of design patterns, the requirement for hard separation between view and logic was emphasized.

I even suggested that Elm MVU was a way to go.

However, despite MVU being an architecture that allows for the hard separation of view and logic, I have become convinced that MVU (and functional programming for that matter) suffers from being somewhat alien to a "natural" process of thinking and programming.

By the word "natural", I mean something that correlates to the language we use in everyday life. Because functional programming can't always be described via such a language (e.g. despite monads (including Observable streams) being a relatively simple term, you won't be able to express it in such a language). I became convinced that programming that would better correlate to natural language is multiparadigm programming, where things are not strictly OOP and not strictly functional, but one or the other depending on clarity and the ease to work with.

Therefore programming of the core of the application (the model/domain layer) isn't really about right or wrong, the model behind an application is a description of how a person who wrote it understands the program conceptually, and it better be one person or a group who is on the same conceptual page.

In this article, I demonstrate a process of building an application that will have the necessary components of good architecture (according to Uncle Bob Martin) with some extra ones that I personally find valuable:

General
- Testable
- Scalable
- Maintainable
- Follows SOLID
- Communicates a conceptual understanding of the creator
Details
- Dependency Inversion
  - Allows to postpone decisions of which tools to use
    - Framework agnostic
    - Allows to optimize for performance, security, and the rest at later stages of development
- Design as a single source of truth for the view layer
Development process
- Outside-in
- TDD

But enough of philosophizing, let's dive into the paraphernalia. Shall we?

Development

In this article, I will demonstrate a process of creating an application in an outside-in fashion. Where the ultimate source of truth is the design in Figma.

We will then create a pure view as a function of state. It will not have any logic or state (other than a few details like scrolling unrelated to the domain logic).

The logic will be created in an OOP manner as a composition of classes via DI in a composition root. This will allow us to postpone details like the choice of storage and possibly some other details.

The Model will be connected to the view using a mapping function similar to ViewModel. It will have the necessary functionality to represent the view, but will not know anything about the details of the view (like a library used or DOM, etc.)

Having a ViewModel will allow us to write the application in a TDD fashion not worrying about complex view libraries/framework runtimes and even allowing us to swap these.

Because both the Model as well as ViewModel will be pure JS Objects (like POJOs), they should also be easily convertible to other languages.

It is important to remember that this approach is all about writing legacy-proof apps (legacy-proof = “adaptable to change” = scalable), which we argued require instant feedback (via Storybook and black-box tests in Jest for example) and good design patterns, which in our case is MVVM and DI.

Step 1: Designs

Here I explain how designs will be converted to Storybook stories.

Since the tools for conversion are still far from perfect, we should rely on ourselves to implement components for the first time. However, as we change something in the designs, we can ask LLMs to adapt the changes to what we already have in the component code. This is possible because components, when implemented correctly, tend to be rather small and easily understood by LLMs.

Here is the link to the Figma file.

Step 2: Storybook

Once we convert designs to Storybook we can use the components to represent scenarios by putting together sequences of pre-setup pages (with certain props), and since we know what props need to happen in transition given certain user interactions we are preparing ourselves for writing black-box tests.

The structure of the stories will resemble the following:

Components
- They will contain the actual component presentation
Pages
- Pages composed out of the components
Scenarios
- A sequence of pages with various props for us to understand how props should change through interaction, which will allow us to write tests
App
- The actual functional app with connected test doubles
- It is important to note that we don’t need to connect actual databases or any other IO other than the view

Step 3: MVVM & TDD

As we write our tests, we implement the domain logic.

I admit that I developed the sample application with very few tests and relied on the TypeScript type system for immediate feedback, so as a personal TODO, I will have to make sure I learn this practice, as I believe it ultimately saves a lot of time for larger projects like this one.

While our tests need to tell whether the functionality is correct, the domain logic structure itself is really not about right or wrong. The conceptual model behind an application is a description of how a person who wrote it understands the program conceptually, and it better be one person or a group who is on the same conceptual page.

As a philosophical side note, Immanuel Kant revolutionized philosophy by shifting the focus from the idea that we directly perceive the world as it truly is to the idea that we perceive the world as it appears to us through our own minds. This means we study our experiences of the world, not the world itself.

Similarly, when developing a program, we shouldn't aim for a single "correct" solution. Instead, we should aim to create a program that effectively represents our understanding and concepts. The quality of this understanding can vary, but as long as the program follows SOLID principles, is testable, works correctly, and is understood by those who use it, we have achieved our goal.

To illustrate, a program doesn't have to be OOP or functional, as in reality, if we could think like computers, we would write optimized binary code directly without any programming languages.

However, I believe that every developer has dreamt about representing their application as simple classes that read like simplified English.

Technically, MobX allows you to do exactly this - represent your model as simple classes. However, there is a price to pay, your classes have to be wrapped with decorators that allow for automatic reactivity. However, representing your application as simple classes doesn't mean you have to rely on yet another framework.

Au contraire, what MobX does still could be accomplished with just simple POJOs.

The View Model, in our case, is a step between simple representation and the view that is always connected to some framework (React, Angular, Vue, Flutter, etc.), but since it is not connected to a framework, and we can use it as a simplified representation of the view that we can actually can (and should) test. Because ViewModel in our case is the boundary, that will allow us to write tests from the intent perspective (similar to behavior-driven development), where the user clicks or interacts with something. This will then allow the frequent refactoring that is required for us to revise our conceptual understanding as often as it needs to be done.

So we will always have an opportunity to refactor as long as tests pass.

Composition root

It is important to remember that the ultimate detail of the application that will change the most is the composition root, where all dependencies will be combined.

It is important to demonstrate in the code repository how you assemble your application as transparently as possible. It means that whenever somebody looks at the repo and then looks inside the index file, they should be able to understand how the application is structured and what its intent is.

Link to the sample app composition root

Step 4: Connecting to IO

The last and the coolest part will be the ability to delay very hard decisions about technology for storage and other IO as far into the future as possible, thus allowing us to keep our pace and implement features while knowing that we still have time to make an educated decision based on our app and stakeholder needs.

Pros & Cons

Pros
- Legacy-proof
- Easy-to-learn
  - This approach builds on top of a lot of established practices like OOP, MVVM, and Component Composition
- Natural programming style
Cons
- Requires you to form a coherent conceptual understanding of your application
  - You will have to doubt, rethink, and refactor
  - There is no set algorithm for creating a model, you will have to experiment until it fits your needs
    - Frequent refactoring
- Simplify and optimize the model
  - While View and IO could be optimized separately,
  - It requires you to make sure your model is as simple as possible

Conclusion

This article was a demonstration of how applications can be written so they are kept legacy-proof and are adaptable to change as true software should be (software means that it is soft or malleable and adaptable to changes).

This is a refreshing view on UI development as modern UI is always 100% tied to a particular framework, but as this article suggests it should not be the case, and in fact not marrying it to a framework makes the code look much simpler.

Useful links

Sample Application: The application that was created to illustrates concepts in this article
Clean Code by Robert Martin: The famous book that explains core principles of scalable software
Dependency Injection Principles, Practices, and Patterns: A book that I consider to be the practical implementation of the concepts outlined in "Clean Code"

Decoupler and future implications for legacy-proof UI code

Kirill Novik — Sat, 15 Jul 2023 14:01:33 +0000

Introduction

Over the course of the previous articles, I was trying to answer the question of how to write legacy-proof code.

The main point was to achieve two things:

Get the correctness feedback quickly
Make use of good design patterns

Albeit, there could likely be many other solutions, I considered the MVU pattern.

This pattern allowed us to take advantage of Figma as a declarative view generator and storybook as a quick correct feedback mechanism to check UI.

This pattern also made the application logic easy to test in a black-box manner.

IO-update MVU is a very flexible pattern. And with every flexible tool (like Redux or React), there are too many ways to shoot yourself in the foot.

To use this pattern wisely, you really have to know what you are doing. And given the time constraints of projects, most of the time you won’t be able to think deeply about how to make sure the legacy isn’t born.

Perks

Design as the single source of truth and the core asset for communication

Designs should be the core asset for reasoning about the application (not the architecture) because developers, designers, and business representatives can now reason about direct interaction with the product being built.

If UI is the main source of truth, then it is much easier to map the concepts and intentions to code based on the structures used in designs as opposed to business required in traditional OOP practices that blur the notion of what is an object, and where one begins and ends.

Essentially, design already has the necessary entities and we don’t need to introduce extra ones from user scenarios, which makes it much easier to understand what entities we need in code.

Division of labor

This approach allows to separate design and layout concerns from logic.
So that you only develop logic only when designs are ready.

And, usually, this makes it much easier, as the majority of expectations could already be demonstrated in Storybook.

This approach might allow to have a dedicated person for refactoring. That is, as a developer, your task is to only make sure your code passes tests, and the purpose of the dedicated refactoring specialist is to make sure everything is consistent with the patterns. Usually, such people are very opinionated, so it’s better to make sure it’s one person to avoid arguments.

Having a dedicated person for refactoring would make the code review process lighter and less prone to bottlenecks, as the main criterion for working code is whether the tests pass.

Declarative low-code tooling

For better or for worse, to avoid the trap of too much flexibility for a lot of simpler use cases, frameworks should be introduced.

I believe that the Decoupler MVU pattern allows for the creation of low-code frameworks similar to what we see with Unity and Unreal Engine.

This pattern could allow us to build UIs using declarative tools in an IDE, where logic could be composed similar to how you compose scripts in Unity, Cloud Serverless functions, nodes in Blender, or Blueprints in Unreal Engine.

But even without the low-code tooling for business logic, having the ability to generate the view layer from designs already eliminates the duplication of effort of transferring designs to code.

Regarding the IO, there could also be low-code tools. Swagger could be taken as inspiration. Swagger codegen is a great tool that allows you to declaratively produce code to interact with APIs.

We could introduce other similar low-code visual tools to connect various parts of the app and produce code based on these declarations.

And to build on top of this even further, why not introduce a dedicated IDE for this task? After all various mobile platforms as well as game development platforms do exactly that.

AI-assisted coding

Not at the present stage of the technology, but in the not-so-distant future, it seems plausible to expect that given black box pure-function tests of your application, you could feed them to an AI model and get the implementation that would satisfy these tests.

This would make development super easy.

In fact, ChatGPT already introduced its code interpreter that attempts to do a similar task of passing tests iteratively running its own code, and getting feedback from the interpreter.

It would also allow us to fine-tune constraints for low-coupling and high-cohesion declaratively. So that the AI agent turns it into an optimization problem.

It definitely a possibility now to use AI to help with some parts of the coding.

Server-side rendering

If we rely on Figma as a declarative view generator along with Decoupler MVU pattern, we could export our view in a format of any static templating engine, so that the backend wouldn’t have to do excessive server-side rendering logic but instead do something that is very natural — generate static html with parameters given and not requiring the complex configuration or setup or reliance on frameworks for that.

Server-side rendering is notoriously complicated and being able to simplify the problem, we could save time and effort.

Conclusion

It seems ironic, that at the end of my search for legacy-proof code, I arrive at a solution that tends to eliminate code altogether and instead introduce declarative tooling that provides a quick feedback loop about how correct everything is.

The IO-update MVU pattern embodies this shift, offering a straightforward way to handle UI and application logic. Separating the design realm from the business logic realm.

However, let’s keep things in perspective. Decoupler MVU is an effective pattern, an effective tool, not a magic wand. It’s designed to make sure code can adapt quickly, with some useful side-effects that allow to improve team communication, streamline the onboarding process, and foster efficiency through low-code tooling.

As attractive as the notion of AI-assisted coding might be, we aren’t there yet.

So, our focus should remain on making the most of the tools we have today.

Creating legacy-proof code isn’t a destination but a journey. It’s about gradual progress, learning, and adapting as we go.

I believe that this MVU pattern is a promising step in this direction — a useful addition to our toolbox that can help make our code more maintainable and robust, however, only when it goes through baptism with fire — when it’s used to create something large, only then could we see its true pros and cons.

Also, I believe that if we formulate problems as optimization and mapping problems, then solutions would no longer be a matter of opinion but rather something measurable. I believe that this pattern has the potential for formulating business logic in this way, where we could specify constraints and solve them (constraints like expected results, coupling, cohesion, performance, etc) via an automated process.

I hope you enjoyed this path we covered over the course of the articles as much as I have.

Let me know your thoughts in the comments!

If you consider using this approach and create something that you want to highlight, please consider forking this documentation and adding link to your project.

Thanks!

Useful links

Decoupler-MVU Documentation: I created this docs to highlight projects that consider using this pattern
Elm Architecture Guide: This guide presents an introduction to the Elm Architecture and provides useful details on how to structure applications effectively.
Model View Update in Elm: This tutorial explores the model-view-update pattern in Elm, a key concept for building interactive applications in the language.
Swagger Codegen: Swagger Codegen is a tool that allows developers to generate client SDKs, server stubs, and API documentation from an OpenAPI Specification.
OpenAI’s Blog on ChatGPT Plugins: This OpenAI blog post provides insights about ChatGPT plugins, which extend the functionality of the ChatGPT language model.
Are Unreal Engine Blueprints No-Code?: This article discusses Unreal Engine Blueprints and their position in the spectrum of no-code solutions.
Vercel’s Guide on Serverless Functions: Vercel’s documentation provides a comprehensive overview of serverless functions and their implementation on the Vercel platform.
Azure Functions: Here’s the official Azure Functions product page, where you can learn about the features, benefits, and pricing of Microsoft’s serverless computing service.
Working with Scripts in Unity: This Unity tutorial presents an in-depth guide on working with scripts in the Unity game development platform.
Scaling Up with Server Side Rendering in Vue.js: This guide from the official Vue.js documentation provides a comprehensive tutorial on scaling up applications with server-side rendering.
Client-Side Rendering vs. Server-Side Rendering: This FreeCodeCamp article discusses the differences between client-side rendering and server-side rendering, explaining the pros and cons of each.
Building Your Application with Server-Side Rendering in Next.js: Next.js’ documentation provides a guide on how to build applications using server-side rendering, a technique that can optimize the performance and SEO of your web applications.

From Figma to React, Vue, Svelte, Preact, and beyond

Kirill Novik — Sat, 15 Jul 2023 14:01:27 +0000

Introduction

In the previous article, we discussed Decoupler MVU pattern for application development that allows us to separate business logic from presentation logic so that we could make our code legacy-proof.

Because our presentation layer is now stateless and unaware of the business logic, it matches the designs very closely.

In Figma, you essentially create the same thing — a stateless component tree. Just like any modern UI framework, Figma relies on components.

Naturally, a question arises: could we use Figma as a single declarative source of truth for our view and eliminate a tedious transfer of designs to code?

And, fortunately, it is not as far-fetched as it might sound!

With Figma having introduced its dev-mode as well as various third-party plugins, it is now possible to convert designs into a stateless component tree in React and other frameworks. This is absolutely mind-blowing, but of course not without its own problems, as many of such code generation plugins miss various features.

Among the problems I faced:

You can’t pass props in a top-down manner.
You can’t have arrays to generate lists

But in general, it is possible. In this article, I will show some practical examples that demonstrate the perks of what the complete separation of the view layer from the rest of the app allows to accomplish.

Design Files

To experiment with this idea, I created a Figma design for a simplified chat.

The main component has a title, message area, and input.

Messages component in turn composes a list of messages which are in turn composes components.

Code generation for storybook

There is a particularly useful plugin for React code generation from Figma — Anima.

It is not perfect, as you still have to fix quite a few things about styles and code here in there, but it does a pretty good job of structuring components.

It also does a good job of generating TypeScript code.

Having this code generated, I had to fix styles and properly pass props, as well as add EventWrapper on top of the interactive components.

I didn’t have to touch any other piece of the logic.

Beyond React

Figma’s ability to generate React code (albeit with some flaws), naturally got me thinking if I could now convert this code to other view frameworks — like Vue, Svelte, and Preact.

These frameworks don’t rely 100% on the same concepts, but the concepts from one framework generally map well to the concepts in other frameworks.

Unfortunately, Anima only generates React code. Other plugins could be used for this task, but I wasn't able to find other code-generation tools that do as good of a job.

Naturally, for this task, I used ChatGPT to help me convert the barebone view layer. And it did pretty well! I still had to fix some issues, but it did 90% bona fide work.

I was feeding it component by component to generate the final result.

Here are the sandboxes with the result.

And because it’s all javascript code, you could replace this part of the application with the view in a desired framework. Although, it would probably be easier to do it the other way, where you add all non-view logic to the project with a desired view, as its configuration is probably relying heavily on the chosen framework.

How about going cross-platform?

Having proof that I can now change tooling as I please (with a bit of extra work of course but still), why not take it to the next level?

How about we turn our code to Flutter?

Concepts in React and other frameworks don’t correspond 100% to what Flutter relies on, but it is very very close. It maps relatively well, and if we had some extra information that we could generate from Figma, we would be able to map to all frameworks easily.

Initially, I wasn’t using ChatGPT to generate code in this case. I used another plugin in Figma — Figma-to-code.

Unlike Anima, it didn’t do as good of a job with generating components, but it still generated the entire tree. And, most importantly, the generated code worked.

I then broke it down into components and stored them in separate files.

Then I restructured it to match the file structure of the React project.

Once the structure matched my React project, I started converting non-react code to dart with ChatGPT.

ChatGPT did a great job. Some issues with types I was able to fix easily as Dart has great type-checking and hints.

I then regenerated components from React project and put them into the Flutter project.

It was a miracle to see that I was able closely to match all the concepts and structures relatively easily with these great tools.

Here is the result project.

Conclusion

In this article, I attempted to provide a practical example, of what I mean by making design the single declarative source of truth for UI.

Despite the fact that the code-generation tooling is still quite limited in functionality, it allows for eliminating the duplication of effort of converting a design to a view as well as not being tied to a single framework or library.

The reason I was able to accomplish the conversion of React project to Vue, Svelte, Preact, and Flutter relatively easily was because of the decomposition that we achieved with the MVU pattern.

Maybe ChatGPT would be able to provide me with 90% working code if it was coupling all the logic, but fixing the remaining 10% would definitely be more challenging in that case.

Having a decoupled stateless view layer is easily convertible to view layers written using different technologies.

Converting the pure update function as well as tests is the easiest part as the only issue you might face is working with types, but having tests and various type checks in place you would be able to fix it relatively easily.

Part 7 — Decoupler and the future for legacy-proof UI: Further exploration of perks that this approach allows that go even beyond legacy-proof code considerations

Useful Links

At first, I wanted to have a full-blown copy of ChatGPT UI, but that was too ambitious, you can see my attempt at that in this sandbox

Anima — Excellent Figma to React code generator
Figma-to-Code Plugin — Great plugin for generating code for various frameworks from Figma
Swagger Codegen — An excellent example of a code generation tooling
Figma Official Website: Figma is a popular tool for UI/UX design and prototyping. With its collaborative interface, it enables multiple designers to work together in real-time. This can be especially handy when working on a legacy-proof UI project, as it allows for a seamless transition from design to code.
UI Design Handbook by Design+Code: This handbook provides a detailed guide on how to turn your designs into code. It covers everything from working with shapes, icons, and images, to handling typography, layout, and spacing. A perfect resource for developers who want to create pixel-perfect UIs that match the initial designs closely.
Widget Code Generator by Figma: This article introduces a powerful tool provided by Figma — the Widget Code Generator. It automatically generates code for your designs, helping to streamline the development process and reduce the gap between design and implementation. It can be particularly useful for our legacy-proof UI project, enabling faster and more accurate transition from design to code.

MVU architecture in a React application

Kirill Novik — Sat, 15 Jul 2023 14:01:20 +0000

Introduction

How to introduce the MVU pattern in a React application?

In the previous articles, we arrived at the conclusion that in order for code to not become legacy we would need to separate our view from business logic in a different way than Redux and Elm are doing it as both approaches not allowing to disentangle view from the business logic completely.

I demonstrated a way to make React a decoupled stateless view similar to how it is done in Elm as part of our quest of trying to make code legacy-proof.

Now, a natural question arises — how about the rest of the pattern? How can we tie everything together?

Elm MVU Pattern

Elm handles UI unidirectional flow using an MVU pattern.

There is a model — data that represents our application state.

This model is used by the view layer to display the correct state of the UI.

When a user interacts with the UI a message is sent to an update function that returns a new model (new state), which in turn is consumed by the view thus going full circle.

There is another part to it, however, commands that produce side effects as well as subscriptions that seem to unnecessarily complicate this pattern.

Decoupler MVU

In reality, a better abstraction of this would be to make the view as well as all other side effect logic one and the same — after all, they all represent IO agents.

IO agent is really a part of this loop, a non-pure function that takes the model (state), does something with it and the outside world and then returns a message.

In the case of view, these actions are button clicks and other user actions. The user sees a certain screen, does some decision-making, and as a result, there is an interaction that results in a message. (User-UI interaction can be abstracted as an IO agent)

In the case of other IO, like HTTP requests, the IO agent sees some state of the application and based on certain parameters decides to fetch, or not to fetch, something and then sends a message.

This abstraction, where both view, requests, and other non-pure functions are just a form of an IO agent, makes it easy to decouple IO logic from the core of the application and thus allowing us to make the unidirectional flow easy to test, as the update function is just a pure function (that could be tested in a black box testing manner) and IO agents now could be swapped with simplified representations for the ease of testing.

This abstraction also makes sense for the vast majority of the UI applications as the majority of them are IO-bound applications (as opposed to CPU-bound or GPU-bound), where their main purpose is to communicate with various Input-Output components (side-effects) — like HTTP requests, WebSockets, UI-user interaction and many more.

So to simplify this pattern and to allow for more flexibility and decouple components better we could just use this IO-Update pattern.

The unidirectional flow of the application now can be represented as a simple function:

const applicationLoop = async (state: PState): Promise<void> => {
  try {
    const action = await io(state);

    const nextState = update(state, action);

    return applicationLoop(nextState);
  } catch (e) {
    console.error(e);

    return applicationLoop(state);
  }
};

This representation of an application seems to be both simple and natural to think about.

Applying this pattern

In the endeavor of ensuring unidirectional flow, I adopted the MIU pattern and created a class that I named ‘decoupler’. This class connects the view with the rest of the application seamlessly. You can see this in action in the linked application here.

Here is the link to the app where I connected the view and the rest of the application using this pattern.

In addition to this, I incorporated black box tests for the update function and devised a simple IO agent to facilitate server communication. It is important to underscore the significance of these black box tests. They not only ensure the functionality of our code but also provide the flexibility to refactor it. By refactoring, we can introduce necessary design patterns to prevent our logic from becoming convoluted.

The real advantage of this pattern is its flexibility and adaptability. It doesn’t dictate how you implement the various components, thus providing freedom to choose appropriate tools for each part of the application. This flexibility extends to allowing timely refactoring and introduction of design patterns, which are crucial for maintaining legacy-proof code.

Importantly, this flexibility allows for the introduction of code generation and various automation.

Furthermore, the decoupler pattern offers an incremental approach to its implementation. It doesn’t impose any restrictions on how the different parts should be implemented. Therefore, you have the liberty to put Redux behind the update function or customize it to suit your needs.

In essence, this pattern offers highly desirable outcomes — ease of receiving feedback and the ability to incorporate good design patterns. These are both essential components for maintaining legacy-proof code.

Conclusion

In this article, we built on top of the previous article, where we introduced a decoupled view layer, and now considered a practical example of how to implement MVU pattern making this view interactive.

This article also introduced a slightly modified and simplified version of MVU that I term IO-update.

As mentioned in the previous examples, among the advantages that we will consider in future articles is the ability to automate the conversion of designs to code, where the view layer no longer has to be tied to a particular technology as well as the ease of writing black box tests for the update

We now were able to implement an MVU pattern that will allow us to make code legacy-proof.

In the next article, we will put this approach to the test and see where it could get us.

Stay tuned!

Part 6 — From Figma to React, Vue, Svelte, Preact, and Beyond: Exploring the legacy-proof (adaptability) benefits of having a completely separate view that matches designs closely

Useful links

Elm Architecture Explained: This guide introduces you to the Elm Architecture. It’s a good starting point to understand the Model-View-Update (MVU) pattern and how it is implemented in Elm. It can offer insights on how we can incorporate these principles into our React application.
Figma Official Website: Figma is a popular tool for UI/UX design and prototyping. With its collaborative interface, it enables multiple designers to work together in real-time. This can be especially handy when working on a legacy-proof UI project, as it allows for a seamless transition from design to code.
UI Design Handbook by Design+Code: This handbook provides a detailed guide on how to turn your designs into code. It covers everything from working with shapes, icons, and images, to handling typography, layout, and spacing. A perfect resource for developers who want to create pixel-perfect UIs that match the initial designs closely.
Widget Code Generator by Figma: This article introduces a powerful tool provided by Figma — the Widget Code Generator. It automatically generates code for your designs, helping to streamline the development process and reduce the gap between design and implementation. It can be particularly useful for our legacy-proof UI project, enabling faster and more accurate transition from design to code.

React as a decoupled stateless view in Storybook

Kirill Novik — Sat, 15 Jul 2023 14:01:12 +0000

Intro

How to make React a stateless view with Storybook?

Let’s see how this could be achieved.

React view as a pure function of state

React has changed how we approach UI — its philosophy is based on the simple yet powerful concepts of using components as well as unidirectional data flow.

It is also believed that React introduced reactivity into UI, but this is not the case as MVVM patterns, as well as frameworks, that rely heavily on reactivity were introduced long before React.

Not only are these concepts very natural ways of thinking about UIs, but they also bring design and development onto the same page.

Elm relies on similar concepts and uses pure composable view functions (stateless components).

However, React falls short as soon as it introduces statefulness and inverse data flow to the picture thus opening the door for high coupling between business logic and presentation logic.

Redux, despite being designed to mimic Elm in part, still tightly couples with the view via the concept of containers.

To make React take full advantage of patterns that Elm follows, we would need to remove inverse data flow from it as well as enforce top-down data flow (as opposed to Redux container components).

I will try to demonstrate that this approach allows for what we’re looking for — decoupled view and less boilerplate.

Regarding concerns of prop-drilling, props are not going to be drilled in a traditional sense, but just like we describe a view as a declarative tree, the props would just match that pattern.

Building a static version of the application using Storybook

To remove the inverse data flow and to enforce top-down data flow, we would need to compose our state using props without any callback functions following the first two steps of the React documentation (https://react.dev/learn/thinking-in-react#start-with-the-mockup).

Here is an example of static version of the app we want to build in storybook.

The props for the entire view are easily composable as a structure that matches exactly the component structure and is statically typed.

This way allows us to easily generate various substates that we would need to check various states of the UI.

Thus helping us to quickly gauge the correctness of our UI using Storybook.

One thing to note, however, is that now as our UI is closely matching Figma designs, it seems a bit tedious to convert the designs to components, and this ideally should be automated.

This is one of the reasons why UI development is so hard — there is a lot of labor that goes into making a high-fidelity transfer of designs to code.

At one of my previous jobs a manager asked why, despite the fact that all we do day and night is making UIs, it still takes us so very long to make a page with React and other fancy tooling we are using.

It really got me thinking, as I myself didn’t quite understand why that was the case, but now, as I look back, I see that aside from quick feedback and design pattern, the transfer of designs to code is also a big part of the problem.

We would return to this point in a future article.

Event Wrapper

We made our static view and it works as a pure function from state.

However, to make this UI interactive, similar to Elm’s MVU, we still need to produce some actions, however, we need to be mindful to not tightly-couple to business logic as we do this.

An approach that we could follow is to introduce declarative wrappers that take metadata: ids and event information and send it to an observable subject, that we could then subscribe to as needed. We shouldn’t however send any data about what action we want to perform as it would tightly couple us to the business logic. (This is often done both in Elm and Redux)

It is important to note that the point of having this wrapper is that it could be added declaratively (ideally without even touching the code and instead relying on code generation tooling to generate code from designs, which we will return in future articles).

As an example, this is what such a declarative pattern might look like.
Note that this is just a demonstration of the concept. To be fully usable, it will need to be optimized for a variety of use cases.

export const EventWrapper: React.FC<
  React.PropsWithChildren<{
    id: { controlId: string; uniqueId?: string };
  }>
> = (props) => {
  const { children, id } = props;
  const childrenWithProps = React.Children.map<
    React.ReactNode,
    React.ReactNode
  >(children, (child) => {
    if (React.isValidElement(child)) {
      return React.cloneElement(child, {
        id: [Object(id).values].join("-"),
        onClick: (e: React.MouseEvent) => {
          e.preventDefault();
          EventSubject.next({ type: "click", id });
        },
        onChange: (e: React.ChangeEvent<HTMLInputElement>) => {
          e.preventDefault();
          EventSubject.next({ type: "change", id, payload: e?.target?.value });
        },
        onKeyDown: (e: React.KeyboardEvent<HTMLInputElement>) => {
          if (e.key === "Enter") {
            e.preventDefault();
            EventSubject.next({ type: "enter", id, payload: e?.target?.value });
          }
        },
        // NOTE: This should be extensible for various handlers
      });
    }
    return child;
  });
  return <>{childrenWithProps}</>;
};

Now we can wrap our interactive components with this wrapper like so:

<EventWrapper id={{ id: "input" }}>
    <input disabled={disabled} className="input" value={input} />
</EventWrapper>

It would probably make more sense to declaratively select what handlers we would need like so:

    <EventWrapper id={{ id: "input" }} handlers={["onClick", "onChange", "onFocus"]}>
      <input disabled={disabled} className="input" value={input} />
    </EventWrapper>

Or if cloning the children subtree is too much for us, it might make sense to use it more imperatively, although this should still be easy to generate such code with code generation tooling.

    <input 
      disabled={disabled} 
      className="input" 
      value={input} 
      onClick={EventWrapper.onClick(IdObject)} 
      onChange={onClick={EventWrapper.onChange(IdObject)}} 
    />

Here EventWrapper methods return handlers that pass the necessary information to the subject and work exactly like the initial wrapper does.

Note that for list elements we would need to provide extra metadata about them to be able to differentiate between them. A ‘controlId’ helps us identify which control element is being referred to, while a ‘uniqueId’ allows us to distinguish between various elements in a list.

    <ul>
      {items.map(({ name, id }) => {
        return (
          <EventWrapper id={{ controlId: id.controlId, uniqueId: id.uniqueId }}>
            <li>{name}</li>
          </EventWrapper>
        )
      })}
    </ul>

Side-notes

It is still possible to use Storybook for gauging quick feedback about how correct the application functions even when the view layer is not completely decoupled from logic.

However, because of this coupling, there will be a need for mocking and it can become very complicated, or it might cause you to rely on the actual communication with the integrated parts of the application.

It might work for a while, but over time will become complex to manage, unreliable, and potentially unusable.

Keeping the view layer pure, will allow us to reliably check the view layer in necessary states, be able to reason about it, and rely on automation.

Conclusion

In this article, we considered a practical example of how to make the view layer completely disjoint from the rest of the application and used Storybook to be able to check quickly the various states this view can be in.

The ability to separate the view layer completely and make a pure function offers many advantages.

Among the advantages that we will consider in future articles is the ability to automate the conversion of designs to code, where the view layer no longer has to be tied to a particular technology.

Also, now that we made our stateless view produce actions, we can finally connect in the unidirectional data-flow loop to make it interactive.

We will explore the rest of the MVU pattern in the next article.

Part 5 — MVU architecture in a React application: Example of how to make a completely stateless view interactive

Useful links

Thinking in React: This is a guide provided by the official React documentation that walks you through the mindset you need to effectively use React in your projects.
Storybook Documentation: Storybook is a powerful tool for UI development, and this documentation will get you up to speed on using it.
Elm Architecture: This link explains the architecture of Elm apps, which heavily inspired the creation of Redux.
React Components and Props: This page in the official React documentation explains how to use components and props in React.
Understanding React’s Unidirectional Data Flow: This article gives a detailed understanding of the unidirectional data flow in React.
React Container Components: This article discusses the concept of container components in React and Redux.
React Observable Subject: This guide explains how to use observable subjects in React.
Figma Design Tool: Figma is a web-based UI design and prototyping tool. The link leads to the official website where you can learn more about the tool.
Example of a Static Version of an App: This is an example of a static version of an app built with Storybook.

How to make UI testable and easy to change?

Kirill Novik — Sat, 15 Jul 2023 14:01:05 +0000

Intro

How to make UI testable and easy to change?

In the previous articles, we arrived at the conclusion that in order for code to not become legacy there needs to be quick correctness feedback and good patterns in place.

Given these two conditions will exhibit the ability to be changed easily.

However, there exist problems with current UI approaches that make these two conditions difficult to achieve.

Problems with architecture and design patterns

React and similar view libraries

React and many other similar front-end libraries tend to fall into the same trap. They tightly couple business, IO, and state management logic.

You develop your components with hot reloading, adding server requests (IO) logic inside of the body of the component, as well as adding redux or similar hooks. Not only it is very convenient, but also allows you to develop something that works and do so very quickly.

This works well for small projects. But this does not work for development at scale.

By allowing you this flexibility, you introduced everything that makes you view layer not just the view layer, but a mix of various layers, and it’s now going to be hard to turn back.

Surprisingly, React was introduced as a view library, that was intended for only handling the view, but in reality, it rarely does handle just view as hooks have now taken over the world.

Survey of architectural approaches

The problem of tight coupling of logic with view is not new and there have been many approaches to solve this problem.

Model-View-Controller (MVC)

Related frameworks: Ruby on Rails (Ruby), Django (Python), Laravel (PHP), Spring MVC (Java), ASP.NET MVC (C#)

The MVC pattern is perhaps the most classic architectural pattern in UI development. This pattern separates application logic into three interconnected components:

The Model manages the data, logic, and rules of the application.
The View abstracts the details of the technology used for presentation
The Controller accepts inputs and converts them to commands for the Model or View

The issue with MVC is that it can often become convoluted as the application scales, with the controller handling a significant portion of the logic. It becomes challenging to manage and test due to the increased dependencies.

// == EXAMPLE OF MVC ==

// MODEL
class ButtonModel {
    constructor() {
        this.click_count = 0;
    }

    incrementCount() {
        this.click_count++;
    }

    getCount() {
        return this.click_count;
    }
}

// VIEW
class ButtonView {
    constructor() {
        this.button = document.getElementById('myButton');
        this.label = document.getElementById('clickCounter');
    }

    updateLabel(count) {
        this.label.innerText = `Clicked: ${count} times`;
    }
}

// CONTROLLER
class ButtonController {
    constructor(model, view) {
        this.model = model;
        this.view = view;
        this.view.button.addEventListener('click', () => this.buttonClicked());
    }

    buttonClicked() {
        this.model.incrementCount();
        const count = this.model.getCount();
        this.view.updateLabel(count);
    }
}

// Main
const buttonModel = new ButtonModel();
const buttonView = new ButtonView();
const buttonController = new ButtonController(buttonModel, buttonView);

Model-View-Presenter (MVP):

Related frameworks: GWT (Java), Vaadin (Java)

MVP is a derivative of the MVC architecture and is mostly used for building user interfaces. In MVP:

The Model is the data layer.
The View is just like in MVC but now handles subscription to the events too (not in Controller anymore) as well as keeps a reference to the presenter.
The Presenter is a essentially a controller but without subscriptions that is a bit easier to test on its own.

Even though the pattern was meant to make testing easier, in reality, we get the complete opposite of what we wanted: the view layer knows everything about the presenter, and presenter doesn't know anything about the view.

// == EXAMPLE OF MVP ==

// MODEL
class ButtonModel {
    constructor() {
        this.click_count = 0;
    }

    incrementCount() {
        this.click_count++;
    }

    getCount() {
        return this.click_count;
    }
}

// VIEW
class ButtonView {
    constructor() {
        this.button = document.getElementById('myButton');
        this.label = document.getElementById('clickCounter');
        this.button.addEventListener('click', () => this.onClick());
    }

    setPresenter(presenter) {
        this.presenter = presenter;
    }

    onClick() {
        this.presenter.handleButtonClick();
    }

    updateLabel(count) {
        this.label.innerText = `Clicked: ${count} times`;
    }
}

// PRESENTER
class ButtonPresenter {
    constructor(view, model) {
        this.view = view;
        this.model = model;
        this.view.setPresenter(this);
    }

    handleButtonClick() {
        this.model.incrementCount();
        const count = this.model.getCount();
        this.view.updateLabel(count);
    }
}

// Main
const buttonModel = new ButtonModel();
const buttonView = new ButtonView();
const buttonPresenter = new ButtonPresenter(buttonView, buttonModel);

Model-View-ViewModel (MVVM)

Related frameworks: Knockout.js (JavaScript), Vue.js (JavaScript), Angular (JavaScript/TypeScript), WPF (Windows Presentation Foundation) with C#

MVVM is another derivative of MVC where the controller is really a controller that also handles pub-sub data binding for the view layer. It also relies on declarative markup. However, testing presentation in separation is very difficult as there is not explicit state view can be easily set to.

// == EXAMPLE OF MVVM ==

// MODEL
class ButtonModel {
    constructor() {
        this.click_count = 0;
    }

    incrementCount() {
        this.click_count++;
    }

    getCount() {
        return this.click_count;
    }
}

// VIEWMODEL
class ButtonViewModel {
    constructor() {
        this.model = new ButtonModel();
        this.button = document.getElementById('myButton');
        this.label = document.getElementById('clickCounter');

        // Binding the ViewModel's method to the button's click event
        this.button.addEventListener('click', () => this.handleButtonClick());
    }

    handleButtonClick() {
        this.model.incrementCount();
        this.updateView();
    }

    updateView() {
        this.label.innerText = `Clicked: ${this.model.getCount()} times`;
    }
}

// Initialize ViewModel
const buttonViewModel = new ButtonViewModel();

Model-View-Update (MVU)

Popular frameworks: Elm (Elm Language), Fabulous (F#), SwiftUI (Swift)

The MVU pattern, popularized by The Elm Architecture, is a relatively new approach to front-end development. In MVU, the model defines the state of the application, the view renders the UI based on the state (model), and the update function modifies the state based on messages (like user actions or server responses). This unidirectional data flow ensures that the UI is predictable and easier to debug.

// == EXAMPLE OF MVU ==

// MODEL
const initialModel = {
    clickCount: 0
};

// VIEW
function view(model) {
    const counterLabel = document.getElementById('clickCounter');
    counterLabel.innerText = `Clicked: ${model.clickCount} times`;
}

// UPDATE
function update(model, action) {
    switch (action.type) {
        case 'INCREMENT':
            return { ...model, clickCount: model.clickCount + 1 };
        default:
            return model;
    }
}

Flux

Popular frameworks: Original Flux, Redux, Alt.js, RefluxJS, Marty.js, McFly, Fluxible, Delorean, NuclearJS

Flux is an application architecture that Facebook uses for building client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow, making the application’s behavior more predictable and easier to understand.

Components of Flux Architecture

Action: These are payloads of information that send data from the application to the Dispatcher.
Dispatcher: A central hub that manages all data flow in the application. It is essentially a registry of callbacks into the stores.
Store: This contains the application state and logic. They are somewhat similar to models in a traditional MVC pattern but manage the state of many objects.
View: The final output of the application based on the current state of the Store.

In Flux, user interactions, server responses, and form submissions are all examples of Actions. The dispatcher processes these Actions and updates the Stores. The View retrieves the new state from the Stores and updates the UI accordingly. This unidirectional flow (Action -> Dispatcher -> Store -> View) is similar to MVU’s (Model-View-Update) data flow where the user input generates a message, the Model updates based on the message, and the View is a function of the Model.

Redux builds upon the Flux architecture but simplifies it by enforcing a few rules:

Single Source of Truth: The state of your whole application is stored in one object tree within a single store.
State is read-only: The only way to change the state is to emit an action, which is an object describing what happened.
Changes are made with pure functions: To specify how the state tree is transformed by actions, you write pure reducers.

These rules help maintain consistency and predictability within the application, making it easier to track state changes and debug the application.

Redux is closer to MVU than traditional MVC. Redux, like MVU, uses a unidirectional data flow where an Action (analogous to MVU’s “message”) triggers a change in the application’s state (Redux’s “single source of truth” is similar to MVU’s “Model”), and the View is updated based on this new state.

While these approaches provide a structured way of developing UIs, they come with their own sets of challenges.

While none of these approaches is a magic wand, I have to clearly state that the philosophy behind these articles is based on the assumption — gained from the insight from years of experience — that the tight coupling of the view layer to the rest of the application is the root of all evils and, therefore, will be exploring the only approach that allows overcoming this — the MVU pattern.

// == EXAMPLE OF FLUX ==

// DISPATCHER
const Dispatcher = function() {
    this._lastID = 0;
    this._callbacks = {};
}

Dispatcher.prototype.register = function(callback) {
    const id = 'CID_' + this._lastID++;
    this._callbacks[id] = callback;
    return id;
}

Dispatcher.prototype.dispatch = function(action) {
    for (const id in this._callbacks) {
        this._callbacks[id](action);
    }
}

const AppDispatcher = new Dispatcher();

// STORE
const ButtonStore = (function() {
    let clickCount = 0;

    function incrementCount() {
        clickCount++;
    }

    function getCount() {
        return clickCount;
    }

    AppDispatcher.register(function(action) {
        if (action.type === 'INCREMENT') {
            incrementCount();
            updateView();
        }
    });

    return {
        getCount: getCount
    }
})();

// ACTIONS
const ButtonActions = {
    increment: function() {
        AppDispatcher.dispatch({
            type: 'INCREMENT'
        });
    }
};

// VIEW
function updateView() {
    const counterLabel = document.getElementById('clickCounter');
    counterLabel.innerText = `Clicked: ${ButtonStore.getCount()} times`;
}

document.getElementById('myButton').addEventListener('click', function() {
    ButtonActions.increment();
});

Elm MVU

Elm is a much better solution for front-end development in terms of architectural design patterns, particularly for its ability to completely decouple the view as a pure function of state via its use of Model-View-Update (MVU) pattern.

Unfortunately, even though it’s a great tool, it lives in a completely different world with a very peculiar language and isolated ecosystem, it exhibits an unattractive pattern of not being able to opt-in gradually (like with TypeScript), which makes it hard to jump on the bandwagon as it would vendor-lock you in.

If Elm wasn’t a tightly coupled combination of an ML language, framework, and MVU pattern all baked into one, enforcing all-or-nothing choice, I would have been just exploring Elm.

Because Elm is a really great technology, of course, there were attempts to introduce similar patterns that Elm relies on, like unidirectional data flow, and similar decoupling of IO, with Redux.

Elm and Redux are similar in many ways, as both implement a functional programming style and a unidirectional data flow, but they have different approaches when it comes to connecting the view to the application’s state.

In Elm, the pattern is Model-Update-View. The whole model is passed to the view function each time an update occurs, meaning the entire state of the app is available when rendering the view.

Redux, on the other hand, is more flexible and less prescriptive about how you connect your state to your views. With Redux, you can use the connect function (when using React-Redux) to bind just the part of the state that the specific component needs, rather than the entire state.

In Redux, however, this makes view tightly coupled to the rest of the loop, so you can’t swap the view easily, without disentangling it properly, which is very tricky and no fun. Another way both Redux and Elm tightly couple view and the rest of the loop is by dispatching actions from controls (UI elements) thus connecting to the logic.

For example, if you have a button that is supposed to increment a value by one, you name an action “increment” and add that to the handler of a button.

However, if later on you decide, to change the underlying logic to use “multiply”, you would have to go to the view and change it.

But view shouldn’t really know about business logic, as well as business logic shouldn’t know about the view.

Therefore, actions should be separated from the view layer.

-- == EXAMPLE OF ELM MVU ==

-- Import necessary modules
import Browser
import Html exposing (..)
import Html.Events exposing (onClick)

-- Main function to start the application
main =
    Browser.sandbox { init = init, update = update, view = view }

-- Define the Model (the state of our application)
type alias Model =
    { clickCount : Int }

-- Initialize the model with a default state
init : Model
init =
    { clickCount = 0 }

-- Define possible actions that can change the state
type Msg
    = Increment

-- The update function describes how to handle each action and update the state
update : Msg -> Model -> Model
update msg model =
    case msg of
        Increment ->
            { model | clickCount = model.clickCount + 1 }

-- The view function displays the state
view : Model -> Html Msg
view model =
    div []
        [ button [ onClick Increment ] [ text "Click Me!" ]
        , p [] [ text ("Clicked: " ++ String.fromInt model.clickCount ++ " times") ]
        ]

Model-View-Intent (MVI) with Cycle.js

Frameworks: Cycle.js (JavaScript)
Another great framework that I've learned recently about is Cycle.js

Just like Elm, it also allows to completely decouple the view layer from the rest of the application.

Cycle.js is a functional and reactive JavaScript framework for cleaner code. It introduces a variant of the MVU pattern called Model-View-Intent (MVI). In Cycle.js, each of these components has a unique and well-defined role:

Intent: This handles all user inputs or events, such as button clicks and form submissions. The intention behind the user's interaction is processed and mapped into an object or "message" to be utilized by the Model.

Model: The Model takes the "message" from the Intent and uses it to update the state of the application. This is done in a predictable, deterministic way, thus ensuring the consistency of state across the application.

View: The View in Cycle.js is a pure function that transforms the application's state into a Virtual DOM tree to be displayed to the user. The advantage of using a Virtual DOM is that it only updates parts of the actual DOM that have changed, enhancing performance.

Cycle.js and the MVI pattern offer a different approach to UI architecture. Rather than propagating actions throughout the application as in traditional MVC, Cycle.js enforces a unidirectional data flow and decouples the application's state from the UI. It also uses Observables to manage asynchronous data flow, further promoting the separation of concerns.

It's very similar to MVU in Elm. So far this framework checks out best for the criteria that help to avoid legacy code.

// == EXAMPLE OF MVI ==

// INTENT
function intent() {
    const button = document.getElementById('myButton');
    button.addEventListener('click', () => {
        model({type: 'INCREMENT'});
    });
}

// MODEL
let clickCount = 0;

function model(action) {
    switch (action.type) {
        case 'INCREMENT':
            clickCount++;
            break;
        default:
            break;
    }
    view(clickCount);
}

// VIEW
function view(count) {
    const counterLabel = document.getElementById('clickCounter');
    counterLabel.innerText = `Clicked: ${count} times`;
}

// Initialize
intent();

Design patterns

Each known architectural approach has many prescribed design patterns. I will not go in-depth on them but will attempt to provide some resources at the end of the article.

Problems with testing

In the previous articles, we mentioned that design patterns help to partially solve the problem of the tendency behind code becoming legacy, a much more important task is the quick correctness feedback in a black-box manner. MVU is going to prove quite helpful in ensuring that such black-box feedback is easy to obtain.

React, as well as many other frameworks, have various solutions for testing, however, there are also very important shortcomings.

For libraries that rely on running React under the hood, as RTL does, tests become integration tests.

And since they are integration tests, the setup might become very complex. The setup for the RTL library itself is straightforward, but the procedure of mocking the dependencies can become unwieldy for larger projects.

And since we mentioned that requirements will change often, the tests might also become obsolete, so we would need to be able to adapt quickly, which could be quite difficult when we have to be aware of many dependencies.

In the context of the metaphor of a line with dots, our tests would be equivalent to locating the dots, and at some point, this process might get too complex and unwieldy making it a burden rather than the solution.

Regarding Redux, even though it’s a library that (finally) allows you to have a unidirectional pure-function-like flow, I haven’t seen a single test written to test its behavior in real-world applications.

How can we do better?

To improve the situation, we should separate business logic from view. This would allow us to test both (very complex) parts of applications separately, and be able to swap one part without touching the other.

This approach would allow us to put the entire view in Storybook, where we would be able to see it in different states easily. Would also allow us to do visual snapshots that would help us with refactoring.

Regarding the business logic, if it follows the unidirectional data flow and is separate from view and other IO, we could write pure-function black box tests that would let us easily check if everything is correct.

Very important to note, that once we have these black-box tests we can refactor our code, implementing the necessary design patterns that would allow us to keep our logic from becoming jumbled.

This would then allow us to refactor the underlying code accordingly and would allow us to do timely refactoring and introduction of necessary design patterns — one of the most important aspects of legacy-proof code.

On top of that, we could then connect this business logic and the view in Storybook again to see how they interact.

Overall, this approach would be highly storybook-friendly, which, in turn, means that the most important part about developing legacy-proof code would be out of the way — quick feedback.

Conclusion

As we mentioned earlier, in order for code to not become legacy there needs to be quick correct feedback and good patterns in place.

Given these two conditions will exhibit the ability to be changed easily.

I wanted to demonstrate that there exists an inherent problem with coupling in UI development that makes these conditions hard to achieve.

This problem makes it difficult to adapt code as well as get quick feedback.

Among the known architectural solutions, only the MVU pattern helps to provide a strong separation of view from the rest of the application, which is an important consideration and aligns best with the philosophy behind these articles.

However, the current solutions relying on unidirectional flow still exhibit a high coupling of business logic and view, and this needs to be resolved if we want to be able to get quick feedback as well as adapt quickly.

Over the course of the next articles, we will attempt to resolve this problem.

Part 4 — React as a decoupled stateless view in Storybook: In this article, we will consider an example of what it means to have a stateless view separate from business logic.

Useful links

Survey of Common Architectural Approaches: Useful article gives a brief overview of the major architectural approaches in UI

Useful Links on Cycle.js and the Model-View-Intent Pattern

Cycle.js Official Website: This is the primary resource for all things related to Cycle.js. It offers detailed guides and API references.
Problem with MVP: Article that explores shortcomings of MVP pattern
Design patterns — A comprehensive guide to software design patterns. Each pattern is explained in detail with examples to help understand when and where to use them.
SOLID Principles: Explanation and examples — This FreeCodeCamp post breaks down the SOLID principles in an easy-to-understand way with lots of examples.
React Documentation: The official React documentation is a must-visit resource for anyone working with React.
Redux Documentation: The official Redux documentation provides a comprehensive guide to getting started with Redux, as well as more advanced topics.
Elm Language Guide: This is the official guide to the Elm language, providing a detailed look at the language’s syntax and features.
React-Redux connect function Documentation: This part of the Redux documentation gives specific information about the ‘connect’ function, which is critical to understanding the connection between state and views in Redux.
Testing React Applications: The React Testing Library (RTL) documentation offers a guide on how to test React components.
Storybook for React: Storybook is an open-source tool for developing UI components in isolation. This link leads to the specific documentation for using Storybook with React.
Model-View-Update (MVU) pattern: This page of the Elm guide explains the Model-View-Update (MVU) pattern, which is a key concept in the Elm language.
Understanding Unidirectional Data Flow in React: This article explains the concept of unidirectional data flow in React and Redux.
Clean Architecture for SwiftUI
Model-View-Update
SwiftUI TEA

Why is UI development legacy prone?

Kirill Novik — Sat, 15 Jul 2023 14:00:57 +0000

Intro

Why is UI development legacy prone?

Using the line metaphor from the previous article, we arrived at a definition of what legacy code is:

Legacy code — code that is very hard to change without everything going down in flames and that is as costly to refactor as rewrite it from scratch.

This code happens when we have complex and ever-changing constraints and requirements when the correctness feedback loop is delayed, as well as when the codebase grows increasingly large.

And this sounds a lot like what UI development (in general) is. And web UI development is no different. There is probably no other field where requirements change as often as in areas related to UI.

Disclaimer: All of the below examples are contrived, simplified, and only needed for illustration purposes — any semblance to real people is coincidental.

From inception to legacy

Greenfield one-man-gig project

There exist lucky people who start working on a project from scratch. This is the happiest place to be if you are a developer.

As you receive the requirements, the idea behind what needs to be built is generally straightforward, the backlog is fresh and well organized, and designs are in, for the most part.

You begin working on it, setting up the project, hustling a bit with configurations initially, but once you figure that step out, the game is on, and you start building.

As you build your first components, you see quick progress, you don’t need tests, as you are able to navigate the entire application in a couple of clicks. You can see your UI with the help of your dev server or some sandbox environment. Your priority is to fulfill the requirements over making the code last.

With some setbacks (we are living in the real world), you manage to get everything delivered on time and everyone is pretty happy.

The end.

Brownfield project

It’s much more likely you are going to be in a different situation and be working on somebody else’s greenfield project and not by yourself anymore.

It will be much more difficult to understand the thought process of the person who built the application.

The last person most likely didn’t pay much attention to anything other than the requirements, so little (if any) testing, tightly coupled, and convoluted logic due to cutting corners during development.

As you now receive requirements, it will be mostly guesswork for you how long something will take to make it work.

As you start working on it, you are mostly debugging through code.

You can no longer click through the UI and know where everything is located.

As you develop, you try to avoid modifying the original logic as much as possible. Layer by layer, you tightly couple one feature on top of the other, as you try to understand the original code and get work done by the end of a sprint.

Most likely, you won’t be able to test things properly, as you are already overwhelmed and struggling with requirements and debugging.

Yet, if you are lucky, you start writing tests for your code, however, you probably make them white-box tests, meaning they are tied to implementation as opposed to testing overall logic with inputs and outputs, which would be part of the problem later on.

Layer by layer, the codebase becomes what’s known as legacy code.

Legacy project

It’s most likely, however, that you will be working on a legacy project as a developer.

At this stage, there is almost no hope for refactoring the legacy part.

The feedback loop for most of the applications is going to be delayed.

The process of covering the application with tests will always be lagging behind and draining motivation.

Conclusion

UI development is legacy prone because quick feedback and effective design patterns allowing for modularity aren’t built into the project during the stage when it’s still a green-field project.

However, the purpose of this article series is not to paint a bleak picture but to explore and propose solutions. While it is true that many of our lines of code may not stand the test of time, it is not an inescapable fate. By understanding the root causes and learning from the experiences of countless developers before us, we can anticipate and mitigate these issues.

Part 3 — How to make UIs testable and easy to change?: A concise survey of known approaches to UI in the context of the problem outlined in the previous articles and where they fall short as well as proposing a new solution

Useful links

To delve deeper into the topics discussed in this article, consider visiting the following resources:

Understanding Legacy Code: This website is a rich resource for understanding legacy code and strategies to effectively deal with it. You’ll find a wealth of information that can help you navigate and improve legacy systems.
Greenfield vs Brownfield: In this LinkedIn article by Giorgi Bastos, the concepts of greenfield and brownfield projects are explored in detail. Giorgi provides great insight into the differences, advantages, and challenges of both approaches.
Greenfield vs Brownfield in Software Development: Synoptek provides a detailed comparison between greenfield and brownfield software development, further enhancing the understanding of these concepts and their implications in UI development.
Advantages and Disadvantages of White Box Testing: This page on JavaTpoint gives a balanced view of white box testing, discussing its advantages and limitations in detail.
White Box Testing: Pros and Cons: Segue Technologies provides another perspective on white box testing, detailing its pros and cons. This article helps you understand why white box testing can be part of the problem in maintaining UI code.

Why does code become legacy?

Kirill Novik — Sat, 15 Jul 2023 14:00:02 +0000

Metaphor

Why does code become legacy?

Writing code is like connecting two points.

Naturally, you would like to take the most straightforward path — a straight line, from A to B. This works for a lot of simple cases, but for the majority of real-world scenarios, you just can’t, because aside from connecting the points, you will have to move around the obstacles.

But, aside from the need to maneuver a little bit, there is no problem.

Let’s increase the number of obstacles in the path by an order of magnitude. The line just keeps on becoming more convoluted.

Now let’s make these obstacles move (which, I, unfortunately, have no animation for), albeit pretty slowly, but enough to cause us trouble of needing to reconnect the points. This isn’t the nice straight-line scenario at all anymore. This is getting serious!

Well, as if that wasn’t enough, how about we now make the points move around as well? And not only that, but will make sure that these points aren’t glued to the lines, and you have to follow them to make sure they stay connected. Well, that’s even more annoying!

But this isn’t everything! What if we only knew the approximate location of the points, and the only way we could tell is by being able to request their location every 5 minutes? How crazy would that be?

And yet this is pretty much what real-world development is often like.

Discussion

In the context of this metaphor, the points are the functional requirements of what the software should do. It’s great when we know exactly whether our code connects to them properly. However, in reality, these requirements change (hence moving points), and we have to update our code accordingly. Yet, it’s not always easy to tell whether we connected the points correctly, and only through rigorous testing could that be determined.

The obstacles could be limitations in technology, performance, programming paradigms, various process, and everything else that could stand in our way — and there is always something — to which we, as problem solvers, are quite accustomed.

Naturally, given this dynamic setup, the code that started out with the best intents and practices possible turns into an ugly squiggle that bears testament to the tortures a developer had to go through to make it work.

This type of code is known as legacy — code that is very hard to change without everything going down in flames and that is as costly to refactor as rewrite it from scratch.

Like jumbled yarn, legacy code usually exhibits high coupling between pieces of logic, that similar to yarn you wouldn’t be able to disentangle easily.

This begs the question of whether there is something that we could do to avoid our code becoming legacy.

How to solve this problem?

Well, this problem is solved partially by the use of so-called design patterns — bite-sized solutions that we could assemble together like Lego blocks to make the process faster and more controlled.

But design patterns are not enough. It’s much more important to know that we’re going in the correct direction as soon as possible than going in the wrong direction “correctly”. And yes, there is a bunch of legacy code that follows great design patterns. In fact, the overuse of design patterns beyond necessary is called “over-engineering.”

We should know where the points are located as soon as possible and to do that, we need some automated, instantaneous way of getting this feedback. That’s what testing your code accomplishes. Not every test would do, but black box tests specifically check the points and not some parts along the path.

So, in order to solve the problem of constantly changing position of the points and the obstacles we need to meet two conditions:

To know that we are going in the right direction ASAP (correctness feedback in the form of black box tests)
Use some preconceived solutions to build the path faster and in a more controlled manner (design patterns)

Conclusion

As simple as these two objectives sound, they are pretty difficult to achieve within the context of UI development, and yet this is what we will try to solve over the course of these articles.

However, in these articles, most focus will be placed on the first aspect (the immediate feedback) requirement as this aspect proved to be the most painful, whereas the design patterns are relatively well studied and known, thus would only be mentioned as a brief survey.

Part 2 — Why is UI development legacy-prone?: Another illustration that builds on top of the previous one, further clarifying the problem

Useful links

Black Box Testing: An In-Depth Tutorial — This tutorial on Guru99 provides a comprehensive guide on black-box testing. It covers its techniques, types, methods, advantages, and disadvantages.
Design patterns — A comprehensive guide to software design patterns. Each pattern is explained in detail with examples to help understand when and where to use them.
SOLID Principles: Explanation and examples — This FreeCodeCamp post breaks down the SOLID principles in an easy-to-understand way with lots of examples.

DEV Community: Kirill Novik

Computational Prime Number Framework Proofs

The Basic Filter: A "Sieve"

Finding Primes by Repeating the Filter ("Sifting")

Why This Prime-Finding Process Never Stops

Finding Twin Primes with a Special Filter

Why This Twin Prime Process Also Never Stops

Summary

Simplified Q&A

Further Reading

Building a legacy-proof app

Introduction

Development

Step 1: Designs

Step 2: Storybook

Step 3: MVVM & TDD

Step 4: Connecting to IO

Pros & Cons

Conclusion

Useful links

Decoupler and future implications for legacy-proof UI code

Introduction

Perks

Design as the single source of truth and the core asset for communication

Division of labor

Declarative low-code tooling

AI-assisted coding

Server-side rendering

Conclusion

Useful links

From Figma to React, Vue, Svelte, Preact, and beyond

Introduction

Design Files

Code generation for storybook

Beyond React

How about going cross-platform?

Conclusion

Useful Links

MVU architecture in a React application

Introduction

Elm MVU Pattern

Decoupler MVU

Applying this pattern

Conclusion

Useful links

React as a decoupled stateless view in Storybook

Intro

React view as a pure function of state

Building a static version of the application using Storybook

Event Wrapper

Side-notes

Conclusion

Useful links

How to make UI testable and easy to change?

Intro

Problems with architecture and design patterns

React and similar view libraries

Survey of architectural approaches

Model-View-Controller (MVC)

Model-View-Presenter (MVP):

Model-View-ViewModel (MVVM)

Model-View-Update (MVU)

Flux

Elm MVU

Model-View-Intent (MVI) with Cycle.js

Design patterns

Problems with testing

How can we do better?

Conclusion

Useful links

Why is UI development legacy prone?

Intro

From inception to legacy

Greenfield one-man-gig project

Brownfield project

Legacy project

Conclusion

Useful links

Why does code become legacy?

Metaphor