DEV Community: Johnny Jarecsni

Why Redux is still #1?

Johnny Jarecsni — Thu, 30 Sep 2021 10:56:40 +0000

Intro

After a rather dull and uneventful period of Redux dominance in the UI application architecture land, there have been quite a few novel state management frameworks released over the past few years. Mobx, Recoil, Diffx, Svelte's own state management, etc. just to name a few.

They all seem to embrace the idea of mutable state, and they seem to allow much more flexible software design than Redux. In fact, Redux as a framework forces us to use some very questionable techniques and constructs. It uses actions instead of plain methods or functions (ok it's inherited from Flux), huge switch statements to match reducers with actions, sagas to handle asynchronous side effects.

Redux was created to tackle the problem of messy web applications with hard to reason about code, difficult to trace errors. However Redux, while it does solve those problems, it also violates almost all software design principles, results in brittle, boilerplatey, hard to maintain code.

The biggest issue with Redux that it transforms your business domain during the implementation into something very low level, technical (for an analogy think assembly language). In other words, the resulting code does not resemble your original problem domain at all. It is a pile of reducers and sagas, with no concepts, entities, encapsulation and abstraction or in general, any structure at all. It is very difficult and costly to introduce any major or cross cutting changes into a Redux application as that requires fine adjustments and changes in many moving parts (in this code everything is open and exposed, there are no clear boundaries, or encapsulation). Yes, you can make quick initial progress and demo stuff every two weeks, at the cost of longer term maintainability.

So if Redux has so many obvious problems, why is it still the king of state management frameworks? What stops people from migrating to lighter, more flexible and more efficient frameworks? There must be something that these newer frameworks are missing... After spending years trying to convince people about Mobx, then Svelte, I think I know the answer. Actually there are more than one reasons for this.

Code navigability, code organisation

If you compare a Redux based application with, say, a Mobx one, you will see that Redux has well defined locations for doing certain things, whereas Mobx is less explicit or opinionated. You can have more expectations about a Redux based project, like for instance if you look for an action fired in a component, you can be sure that there will be a reducer configured for that action, and maybe a saga as well. Even if one does not like the idea of reducers (and I for one certainly do not like it), they have to admit it does introduce a way of decoupling and and improves navigability. So I believe any successful attempts to dethrone Redux will have to offer a similar mechanism.

Developer Tool

This is huge. People want to see how the state is changing, clearly, action after action. This is a must. Let me put it bluntly, without a Redux like developer tool, no state management framework has a serious chance to be considered as a replacement for Redux. Luckily most frameworks do offer such a tool (I can only hope that someone makes one for Svelte - Svelte has a great state offering but sadly lacks in the tooling department.)

One more thing...

Besides these two points, which are fairly easy to tackle (watch this space for more articles on that), there is another, more subtle issue here.

Redux fits the present day Agile method quite well, it does not require ANY effort for an upfront design (in fact, there is no need for any design at all!). You can start "wiring in" your atomic little reducers, press a button, state changes, wonderful isn't it? Other frameworks tend to need some sort effort to map the domain to an object model, define some interactions, state transitions, etc. This does not quite play well with Agile's delivery centered approach that wants to see something moving and flashing at the first Show and Tell.

So, my other prediction is that any successful contender to replace Redux, will have to find a middle ground, where devs are able to put something in place quickly and also to evolve a design over time, in an Agile fashion, that will help with long term maintainability and will be less sensitive to change. Exactly how that could be done is not clear to me yet, but we can clearly see the two extremes: a functional approach leading to assembly language level decomposition with all its problems, and a purely OO approach requiring heavy upfront design, often leading to difficult to reason about custom solutions.

As usual, the ideal solution will be somewhere in the middle!

On Modern Web Applications

Johnny Jarecsni — Sat, 17 Jul 2021 12:47:34 +0000

Introduction

We all know that fashion waves come and go in software development, just like everywhere else in life. When in the middle of such a wave, it is extremely difficult to raise any concerns about the actual main stream, canonical method or truth. Currently it is agile and functional programming. We have a tunnel vision, where we keep repeating '4 legs good, 2 legs bad'. This article attempts to go against the accepted and unchallenged, and look at a few pretty big cracks in the system, trying to come up with some recommendations as well.

The problem

It has been a while now that I noticed a few things I did not like about how we write software. I started to collect these points, and was thinking about why we do things the way we do them, and how these individual aspects might correlate, catalysing each other. It is best if we start with the end product of it all, the software that we write.

If you look at a typical web application made in the past few years, you will notice the following few attributes:

it is using FP as programming paradigm
it is using a framework like Redux for application logic
it has no noticeable software design
it has tons of unit tests
it has a layered organisation of files (services, actions, etc.)

When you try to apply even the tiniest change to an application written like this, you immediately notice the following engineering principles all being violated:

Open-Closed Principle
Single Responsibility Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

First of all, any functionality change needs to involve all the layers, actions, reducers, components, meaning lots of changes. Since there is a tendency to introduce dependencies between pieces of state in the reducer(s) these changes are all potentially risky - hence you need to put a load of unit tests in place to make sure things still work. Things are flat and open, there is no resistance in this software, people can do pretty much anything, software contracts, etc. are not expressed by any means. And they even think that this is a good thing...

There is no noticeable design, that is, no entities, processes, interactions, the software is an unintelligible assembly of framework specific technicalities like actions and reducer functions that operate on atomic bits like a Boolean variable that has a particular meaning. Looking at this from ten thousand feet it looks as though we are again at the elementary level of assembly programming - our software is close to the metal (close to the framework and the DOM) and far away from the reality it is modelling. Yes, it seems history does repeat itself.

This type of software will obviously be very costly to maintain. As I said before, simple functional changes will need to be woven through the fabric of the application (lots of changes, lots of unit tests) but larger changes, like supporting a different financial product with a slightly different set of attributes/behaviours will be painful due the complete lack of abstraction and tight coupling everywhere. I like to call this type of software shrink wrap software. It is tailor made to the exact set of requirements known at the time of writing the software, with absolutely zero flexibility to withstand or help with change.

Under the hood

So what is driving all this? We all know that back in the 90s people started to feel that Waterfall doesn't really cut the mustard as it was unable to keep up with the fast changing business reality. By the way, this was the era of Object Oriented programming and software design (Design Patterns by GoF, etc. - apparently people had time for all that! :)

Coincidentally, application development took another turn at the time, more like around the early 2000s. Web applications started to replace the heavy duty GUIs and their object oriented designs that were developed with costly waterfall methodology. The fast paced business world found its ideal match, functional programming and agile.

The focus of agile is short term, the actual iteration, there is not much room for anything else. It is but natural that developers picked up a tool which is more proper for this type work, functional programming. Functional languages are good at small scale work, as in writing lots of small functions that can be combined to carry out more complicated work. Due to their dynamic nature they are also good for quick prototyping (funnily enough most prototypes in an Agile project end up being used as the real thing - clearly showing some confusion in the minds).

Functional programming, however, inherently is not so good at expressing larger scale designs. If you try to google for functional design patters you will find none. Everything is a function, end of story. You can play with scopes etc, but it is not idiomatic functional programming any more. Functional programming is wonderful, and it is very efficient for an array of things. It is a mistake however to try to use it for everything. It leads to the messy, unmaintainable codebases we call agile software.

A Way out

So far I tried to show where I see the problems with modern software development. It is ephemeral, short sighted, lacks design and uses a tool that is inherently incapable of producing structured, reusable and maintainable software. So what shall we do, shall we go back to waterfall and Object Oriented languages?

Well, that would hardly work, there was a reason for leaving all that behind.

There are a few things we need to take into account when trying to come up with a better way of crafting software.

1) Businesses change rapidly, so only tools/metholodigies that are able to keep up will be viable
2) Agile is unlikely to go away

Since coming up with an application design for each new application is not really viable due to the points above, we need a better framework that allows us to craft software, component by component that blends into the super-structure of the application, which is easy to maintain over time. This is the exact opposite of things like Redux, where things melt away, as you keep adding more and more to the application. They dissolve into atomic pieces of the state and fragmented logic, which are very difficult to reason about. I think this is a key problem with Redux. It forces a brittle, fragmented architecture on your application - and there is a massive price to pay for this down the line.

So the way forward can be a plugin-like architecture, where you can develop pieces of functionality (yes, using FP if you like!) where these plugins provide clear integration points and APIs, and it is easy to see how they are assembled together to provide a piece of functionality. These plugins can then be easily reused in other application, since plugins are self-contained and encapsulated units of markup, state and async resources. Contrast this with the fragmented nature of modern web apps, with the entangled web of action creators, reducers, services, utilities, and UI components - where it is impossible to isolate anything for reuse.

This plugin architecture will also help with testing, by allowing easy replacement of the dependencies these plugins declare.

It is still a question, how much of this is possible to implement in TypeScript, which is tied to JavaScript which has some limitations around implementing these kind of 'meta' designs, which are based on indirection, inversion of control, decoupling and lazy/conditional loading.

Conclusion

It is long overdue to come up with a better architecture and organisation for web applications. Finally we have a simple and elegant UI component framework, Svelte, but we are still suffering from an even bigger problem, not being able to model business problems in a clean, reusable and maintainable way.

My proposal is to combine the good from both OO and FP to come up with a framework that allows rapid application development and yet it does not compromise on the maintainability of the resulting code.

Sounds like a daring proposition?

JavaScript's Lack of Inversion

Johnny Jarecsni — Thu, 02 Jul 2020 17:39:58 +0000

Intro

I think we can risk to say that from its humble beginnings, JavaScript has become the most popular programming language during the past two decades.

As the old adage goes: your true nature cannot be avoided, just as a tree cannot deny its own roots. Similarly, JavaScript has a few important design decisions inherent in being a browser scripting language, which have some substantial consequences.

The Problem

Let us suppose you want to implement a plugin architecture based solution. You have a PluginManager module which will manage all the registered plugins in the system.

import {pluginA} from './plugins/PluginA'
import {pluginB} from './plugins/PluginB'

class PluginManager {
    registerPlugins() {
        register(pluginA);
        register(pluginB);  
    }
}
export const pluginManager = new PluginManager();

And somewhere in your index.js or similar top level script, you will do something like the below:

import {pluginManager} from './PluginManager'

pluginManager.registerPlugins();

So what is the big problem here, you're on about?

Well, if you look closer, you will see that the PluginManager has explicit knowledge about the plugins it manages. This contradicts all the software design principles, and among other things it means whenever we want to introduce a new plugin we will need to modify the PluginManager.

OK but how other languages go about this?

In a poor man's implementation you could have a simple file like plugins.txt, where you list all your plugins to be loaded:

com.supercool.plugins.PluginA
com.lesscool.plugins.PluginB

And then you would construct your PluginManager with this piece of configuration and it would be able to load the classes and register them. Without explicit knowledge about any of them.

Yes, you can go much fancier than this, and use some Dependency Injection framework for example.

Back to JS

The reason for this is rather prosaic: the lack of dynamic module loading.

In other words, if it ain't mentioned it ain't bundled (and won't be loadable as it won't be there). So that is why everything has to be so explicit, as otherwise the poor bundler would have no knowledge of the stuff and so it would not be bundled.

This is inherent in how JavaScript was born as a scripting language for the browser. Its resources (script files) are treated the very same way as say a GIF, it has to be referenced and made available in a resource file, available to the browser, otherwise it does not exist.

Conclusion

To me, the lack of dynamic module loading means that certain designs are impossible to implement in JavaScript. Also, it fosters brittle architectures based on strong coupling by having to reference concrete module implementations (module files).

Some of these issues are easy to work around, some are less so. At any rate, this is a serious limitation, which is only now becoming more and more apparent, as we are putting JavaScript to more use as a generic programming language, not just the cowboy language of the Internet.

The Power of Svelte Markup or When Less is More

Johnny Jarecsni — Thu, 18 Jun 2020 21:53:32 +0000

Intro

This is just a quick post about a revelation I have made today about the profound consequences of how Svelte markups work. Or more precisely, how they do not work...

Long Story Short

I am new to Svelte, coming from a React background and that means that I will try things in a 'Reacty' way first (why, if we have words like 'cupboardy', 'Reacty' is fine), just like anyone else, first trying stuff that is familiar.

However Svelte is radically different from React in many ways, and one of these areas is its approach to markup (you know the HTML like thing with the angle brackets).

The Problem

Lets just say I have a bunch of meet-up event objects in an array, which I want to render as a list. There is one tiny twist, when there are multiple events on the same day, I want to collapse these events under the same date (only render the date in front of the very first event on any given day).

React Instincts Kick in

So I thought, ok fine, I can just use an #if to emit the date if it is different from the 'currentDate' that we hold in a variable.

{#each upcomingEvents as event}
   {#if event.date !== currentDate }
      <label>{event.date}</label>
   {/if}
   <label>{event.time}</label>
   <label>{event.title}</label>
   <label>{event.group}</label>
{/each}

Looks promising right? Ok let's add the variable

<script>
let currentDate = null;
<script>

It is again dead easy, we just declare the variable, and since it is null, the very first item in the array will have a different date, so that is good as we will render it nicely.

Now there is just one more tiny problem to solve, updating this variable with the lastly rendered event's date. Should not be too difficult right?

Try something like:

{#each upcomingEvents as event}
   {#if event.date !== currentDate }
      <label>{event.date}</label>
   {/if}
   <label>{event.time}</label>
   <label>{event.title}</label>
   <label>{event.group}</label>
   {currentDate = event.date}
{/each}

(As an astute reader pointed out this is not idiomatic React. Yes true, we would not do an assignment like that from JSX, but we also don't have 'each' (or templating keywords) in React, where you'd probably map the array to JSX. Lets just say the assignment to currentDate is the next logical option that was in my mind (given we don't do mapping to markup in Svelte!) and this article is showing how the revelations unfolded for me, so you get to see the work in progress :)

Svelte Markup != JSX

Too bad, it does not work. And here is the deal - you cannot do this the React way. React's JSX is two-way, code and markup are interchangeable. You can return JSX from functions, you can switch to code entirely within your JSX (that is why you can just call Array.map() to transform a piece of data to markup in the middle of your JSX expression).

Svelte markup is markup only, or we could say it is one directional. It can render data, but there is no way to execute code from markup (this is exactly why Svelte needs a few templating keywords like #each and #if, to be able to apply some minimal logic to rendering).

So how can this problem be solved with Svelte then?

A Moment of Revelation

The answer is separation of concerns. Separating presentation / rendering concerns (done by markup) and model transformations (done by code).

Therefore, to achieve what we want, we will need to create a derivation of our primary model object (the array of event objects) such that our events are grouped by date, and then render this model by a simple markup:

let upcomingEventsGrouped; 
$: {
   let currentDate = null;
   upcomingEventsGrouped = [];
   upcomingEvents.forEach(({date, time, title, group}) => {
      const _date = (date !== currentDate ? date : null);
      upcomingEventsGrouped.push({
         time, title, group, date: _date 
      });
      currentDate = date;
   });
   upcomingEventsGrouped = upcomingEventsGrouped;
}

It is worth noting at this point, that this model derivation is declared reactively (it is recomputed every time the underlying data, upcomingEvents in this case, changes). That's achieved by using '$:' - isn't that just wonderful?!

Here is the template to render the derived data:

{#each upcomingEventsGrouped as event}
   {#if !!event.date }
      <label>{event.date}</label>
   {/if}
   <label>{event.time}</label>
   <label>{event.title}</label>
   <label>{event.group}</label>
{/each}

Really simple, just mapping the data attributes to markup elements, really easy to read!

And here's a pieace of event code that tests adding a new event in the upcomingEvents array:

function addEvent(e) {
   upcomingEvents = [...upcomingEvents, {
      date: '20/06/2020',
      time: '18:00',
      title: 'Templating with Svelte 2.',
      group: 'Svelte Rookies'
   }];
}

Note that we need to use assignment in some form wherever we update an array otherwise Svelte will not pick up on the change!

Finally

I think Svelte's take on the markup may come across first as limiting and less powerful than React's JSX, however there is huge power in this - the power of simplicity.

React JSX lends itself for complicated solutions (taking on responsibilities of the view model), while Svelte's markup forces you to offload these concerns to your script element, resulting in a simple 1:1 mapping when it comes to rendering the model.

Thanks for reading this article, hope you enjoyed it and if you have anything to add/correct etc, please do leave a comment!