The Idea That Wouldn't Go Away

Then one day I looked at the speakers in my house and thought: how hard is it going to be to make these things programmable? Like, play music from 7 to 11 automatically. Café mode. And I wanted to finish it today.

I vaguely knew about something called Home Assistant. So I did what any self-respecting developer would do, I went and asked AI 🤖. After a long back-and-forth, it turned out the setup wasn't that complicated. Here's the full picture of what we figured out:

You have a Squeezebox client that connects to a speaker through Bluetooth, and on the other end connects through Wi-Fi to a Squeezebox server running inside Home Assistant. Home Assistant Music handles the connection to your music provider (Spotify, YouTube Music, etc.)

The original plan involved an ESP32 a microcontroller. But as I understood what was actually needed something that receives an audio stream and pushes it to a speaker I thought why can't I just use my old phone? 🤷‍♂️.

Setting Up Home Assistant

First thing: Home Assistant. If you don't know it, think of it like Google Home or Apple Home except you don't have to worry about these corporations recording every conversation you have. It runs completely in your home, on your network.

You need some kind of computer to run it. Any old computer, a Raspberry Pi, or you can buy the Home Assistant Green — a ready-to-go device you plug in and it just works out of the box. I already have a home server so I set it up as a VM.

Once Home Assistant is up, you create an account and install the Music Assistant app. This is where two important concepts come together:

• Music Providers adapters that bring your music from platforms like Spotify, YouTube Music, Apple Music, etc.

• Players destinations where the music plays. Your laptop, a speaker, anything that can receive audio.

I connected YouTube Music (the adapter is in beta but it worked). And then something cool happened.

The Moment It Clicked

My laptop was already showing up as a player. Just because it's on the same network as Home Assistant. I hit play. Music came out of my laptop.

This was not the goal. But it made me understand how things connect. Music Assistant discovers players on the network. My laptop is one. Now I just need to add another one the old phone connected to my speaker.

Adding the Dead Phone as a Player with Squeezebox

Squeezebox is a technology that's been around for a while. What makes it interesting is that it doesn't send audio files to the device it streams audio data to any audio sync. So conceptually, if the phone is connected to the speaker through Bluetooth, any audio streamed to the phone goes straight to the speaker.

Here's how I set it up:

1. Squeezebox Server: In Home Assistant Music, go to the plugins and add the Squeezebox provider. This sets up the server.

2. Squeezebox Client on the Phone: I needed a Squeezebox client for Android. The official options are all paid on the Play Store. So I went to F-Droid (an open-source app store) and installed SqueezeLite. Straightforward setup just point it to the server address and hit start.

3. Connect Phone to Speaker via Bluetooth: Just the standard Bluetooth pairing. Nothing fancy.

After this, I could see a new player in Home Assistant Music, "Android Speaker." I picked a song, chose that player, hit play, and the music came through the speaker.

That was the moment I knew the hard part was done.

The Snowball

This is the part I didn't expect.

Home Assistant has an automation tab and it's surprisingly straightforward. I set it up: music plays from 7 to 11, jazz playlist. Café mode.

But then I noticed my TV had been discovered on the network. Home Assistant just found it. So I added a rule — TV on, music stops.

Then I installed the Home Assistant companion app, which knows whether I'm home (and that data never leaves my server). New rule: left the house, music stops.

Then I wrote a small script that checks if my laptop mic is active. New rule: on a call, music ducks.

Each of these took minutes. And each one came from just poking around what Home Assistant had already found.

And then more things opened up. I discovered devices and entities. I saw NFC tags in the settings and went down a rabbit hole of how people use them. By the end of this one project, I had more ideas of what to build next than I ever got from reading books or watching courses.

Turns out all it took was one small question to pull me in.

If you have questions or want to share what you built, feel free to reach out. Happy hacking 🤓

Why does this happen?

This happens when a component use Non-logical CSS like padding-left, margin-right, top-5 and much more. Non-logical properties include width and height which can break designs for languages that are Top-To-Bottom (TTB).

However, Both Flexbox and Grid are designed logically, allowing them to function correctly irrespective of the direction. This explains why some parts of the design, such as the spacing between icons and links, display correctly in both LTR and RTL.

New CSS properties have been introduced to address these issues, creating a more logical user interface. For instance, padding-start was introduced to correspond to padding-left in RTL, while block-size was developed to match height. Many more logical CSS properties have been developed. A complete list of these properties can be found here.

Introducing to-logical -tailwind

Lucky for us the TaiwlindCss ecosystem for a while had a plugin that added support to logical Css in Taiwlind. Also more recently TaiwlindCss added native support to RTL with V3.3 release. To-logical-tailwind, support both output formats and converts any tailwind component to a "logical-tailwind" component.

Conclusion

You can start using to-logical-tailwind today, and the code for the project is open-source and you can find it here. Happy hacking and feel free to open an issue if you need any help 🤓.

TLDR;

The biggest advantage of Xstate is it comes to modeling complex business logic. Instead of juggling various flags or values to get things to work, as you often need to do in Zustand, Xstate allows you to align your coding approach with the actual mental model of your business logic. For example, you have a flow that is the most linear and sequential you can visualize is it in your stat chart as such. See the machine at Stately here.

About the project and the plan for migration

So the App we are working with allow users to create formatted tables from csv fiels . It works by using a dataModel to extract data and format csv files. The app is powered by a single Zustand store but broken down into two different slices. One slice is responsible for the creation of the formatted tables ("AutoTables"). The other slice is responsible for the creation and updating of user-defined DataModels. Another layer of complexity is that the store is persisted to localStorage.

When planning for migration to Xstate, I wanted as much as possible to do incremental migration to the Xstate. First I decided that I will start with the CreateAutoTableSlice. The thinking was that I can start using Xstate and not worry about persistence for now. However, I still needed somehow to be synced with any DataModels that are defined on the user device. Luckily the solution in Xstate was simple. In the first step of the machine, I added an invocation that fetches the data Models from local storage.

Rabid fire mental model of Xstate

Before delving deeper into the details, let's quickly establish a fundamental mental model of Xstate. This section aims to give you an essential grounding to better appreciate the rest of the article.

• Everything is defined inside a machine*: Your business logic, side effects, context, state values—everything is defined and lives inside a single machine.

  • * There are patterns such as withConfig and the options parameter of the useMachine function, but these mostly augment the state machine rather than altering this fundamental characteristic.

• Logic is modeled as several states connected by transitions: you define explicit state charts, which not only manage state but also elegantly map out the entire flow of our application logic.

• Machin "Context": it's where you store data that can change over time and across states. It acts as a memory of sorts for your state machine, persisting data between state transitions.

• No Built-in State Sharing: Xstate doesn't have inbuilt primitives for sharing states across different applications, unlike Zustand. But fear not, as there are well-established patterns for state sharing in Xstate, which we'll be exploring later.

• Using Machines by "Interpreting" it: Finally, in a React application, you bring your machine to life by using useMachine or useInterpret. These hooks start a machine that runs for the lifetime of the component.

Lessons Learned

The code matches my mental model of the business

Often time when you start coding you have a fuzzy idea of how the business logic should work. This is because the natural language can't perfectly encapsulate the complexities of business operations.
Consequently, you end up in a cycle of coding, encountering unforeseen scenarios, refactoring, rewriting, and repeating until you achieve a working product that meets the business needs.

Having your code Matches the mental model of your business makes things much faster to develop. And even when you hit cases where you have to update the code to match your new understanding of the business logic is a lot easier. on top of all the the Xstate visualizer/editor, make things even easier.

There is a learning curve

No Surprise there is a learning curve and a bunch of new concepts and terminologies to learn for me. Also I never really got to a point where I felt I have a solid understanding of what exactly is an actor, I know that a service is an actor in Xstate and I know that an actor is something that "sends messages, receives messages and do some computation" but still for my brain that wasn't enough.

Luckily despite this disadvantage, I managed to get my way around Xstate and manage to migrate the AutoTablesCreationSlice to Xstate. It did however take a couple of days for me to feel comfortable and stop being frustrated when typescript screams at me. As usual with foreign new complex concepts, I need to sleep on it and that for some weird reason does help.

Dealing with Computed Context

Computed context is a common need in our application and often time they do include business logic. Unfortunately Xstate doesn't have the concept of computed/derived context. However, the xstate/react package does come with a useSelector. Initially, I tried to build a custom selector hook that will encapsulate all the available computed context. However, I apondened that approach after I learned that you lose the isolation of re-renders based on what changes by using useSelector. Instead, I create a DerivedContextSelectors to encapsulate all the business logic in one place.

export const autoTablesCreationMachineDerivedContextSelectors = {
  selectAvailableDataModelsNames: selectAvailableDataModelsNames,
  // more selectors here
} as const;

Hidden Bugs

I got stuck for 15m during the migration on an event that I can see from the dev-tool that is firing but the transition does not complete. I eventually found out that event firing was referencing the target state that was renamed. Though typescript did show an error in that file, the app didn't show anyting in the logs and didn't break. I wished that cases like this would break more loudly.

Actions can be fired from anywhere

This point was not immediately obvious to me and I was having a difficult time figuring out how to fire an error toast if the processing of uploaded files failed but still who the upload screen. I ended up doing what is called a self-transition and firing the error toast from the event.

Using the state Machine across components

As discussed earlier, we bring our state machine to life in a component by 'interpreting' it using either useMachine or useInterpret. This initiation creates distinct, disconnected flows for each component on each call, which may not always what you want. If we want different components to share the same flow, we can achieve this by using ReactContext.

export const AutoTablesCreationServiceContext = React.createContext<InterpreterFrom<typeof autoTablesCreationMachine> | null>(null);

// inside your component 
const service = useInterpret(autoTablesCreationMachine, { devTools: true });
// insde the return
 <AutoTablesCreationServiceContext.Provider value={service}>
    {children}
 </AutoTablesCreationServiceContext.Provider>

Then in any component, you can do this

const service = useContext(autoTablesCreationMachine);

I wanted to use the useActor hook to perform state.match (which is how you verify the state of your machine). But since the context is sometimes null this was a problem so I ended up creating a custom hook that asset strong types the context and throws if it's missing.

import { useContext, type Context } from 'react';

export function useRequiredContext<T>(context: Context<T | null>): T {
  const value = useContext(context);
  if (value === null) {
    throw new Error('Context value is missing');
  }
  return value;
}

Final Score

Using Xstate did require a different way of thinking about my application state. But it did ended-up for me to be a much more natural way of thinking about code and business logic. Despite the learning curve, I'm very pleased with the migration to Xstate. Going forward I'm going to explore migrating the next slice to Xstate and figure out the best approach strategy for persisting the machine's context. Stay tuned for a potential Part 2 of this article.

Domain-Driven Design (DDD) is a software development methodology that emphasizes the importance of modeling business domains to create software that closely aligns with the needs of the organization. However, persisting DDD objects can present challenges for developers. In this article, we'll discuss some common problems when persisting DDD objects and explore how to solve them using Prisma, a powerful and flexible ORM for Node.js and TypeScript. We will use the following example models throughout the article:

class Customer {
  id: string;
  name: string;
  orders: Order[];
}

class Order {
  id: string;
  customerId: string;
  total: number;
  items: OrderItem[];
}

class OrderItem {
  productId: string;
  quantity: number;
  price: number;
}

Problem 1: Create VS Update

In DDD, aggregate or entity IDs are usually set upon object creation if they do not exist. This presents a problem: if the ID always exists, how do we know if we should use Create or Update when persisting the object? Using the wrong operation will result in an error. Consider the code below:

import { Customer } from './models/Customer';
import * as cuid from 'cuid';

class CustomerAggregate {
  private constructor(private _customer: Customer) {}

  static create(customer: Partial<Customer>): CustomerAggregate {
    const id = customer.id || cuid();
    const newCustomer = new Customer({ ...customer, id });
    return new CustomerAggregate(newCustomer);
  }

  get customer(): Customer {
    return this._customer;
  }
}

async function saveCustomer(customer: Customer) {
  if (customer.id) {
    await prisma.customer.update({ where: { id: customer.id }, data: customer });
  } else {
    await prisma.customer.create({ data: customer });
  }
}

if the Customer Object always has an ID then the else path will never be reached! Of course, there is a million hacky way to solve this like adding a flag to the domain object but we are looking for a clear separation between the Domain and the DB.

Solution: Using upsert with Prisma

Prisma provides an upsert feature, which allows developers to replace Create and Update with Save. This simplifies the persistence logic, as shown in the code below:

async function saveCustomer(customer: Customer) {
  await prisma.customer.upsert({
    where: { id: customer.id },
    update: customer,
    create: customer,
  });
}

One caveat to this is that the save method can get quite large as the aggregate increase in the number of relations and complexity. See example below

async save(propertyListing: PropertyListingAggregate): Promise<{ id: string }> {
    const { pricingOptions, images, propertyListingData } = propertyListingMapper.toDb(propertyListing);

     await this.prisma.propertyListings.upsert({
      where: {
        id: propertyListingData.id,
      },
      create: {
        ...propertyListingData,
        customGeneralInfo: Prisma.JsonNull,
        customFeaturesAndAmenities: Prisma.JsonNull,
        pricingOptions: {
          createMany: {
            data: pricingOptions,
          },
        },
        images: {
          createMany: {
            data: images,
          },
        },
      },
      update: {
        ...propertyListingData,
        customGeneralInfo: Prisma.JsonNull,
        customFeaturesAndAmenities: Prisma.JsonNull,
        pricingOptions: {
          deleteMany: {},
          createMany: {
            data: pricingOptions,
          },
        },
        images: {
          deleteMany: {},
          createMany: {
            data: images,
          },
        },
      },
    });

    return { id: propertyListingData.id };
  }

Problem 2: Value Objects Persisted on Another Table

Sometimes, we have DDD objects that should be value objects but, due to how they are persisted in the database, we need to assign them an ID. This goes against one of the fundamental ideas of DDD: that database concerns should not leak into the domain.

Solution: Transactions and Cascading Relations

To address this issue, we can use transactions in the Save method. This allows us to first delete all value objects and then create new ones through cascading relations. Consider the code example below:

async function saveOrder(order: Order) {
  await prisma.$transaction([
    prisma.orderItem.deleteMany({ where: { orderId: order.id } }),
    ...order.items.map((item) =>
      prisma.orderItem.create({
        data: { ...item, orderId: order.id },
      })
    ),
    prisma.order.upsert({
      where: { id: order.id },
      update: { total: order.total },
      create: { ...order, items: { create: order.items } },
    }),
  ]);
}

While this solution does increase the number of database operations, it prevents database concerns from leaking into the domain.

Summary and Conclusion

Persisting DDD objects can pose challenges for developers, but Prisma provides powerful tools to overcome these issues. In this article, we explored how to use the upsert feature to simplify the Create and Update operations and how to use transactions and cascading relations to handle value objects that are persisted on separate tables. By employing these techniques, developers can adhere to the principles of DDD while efficiently persisting their domain objects.

But wait we have React hooks now, we don't need Redux anymore, right ?

If you are not a React dev, React hooks are the latest addition to React and they are absolutely awesome ⚡, but they are not replacing Redux. If you are still unconvinced, I would strongly recommend Eric Elliot article, Do React Hooks Replace Redux?.

For now if you want to continue without reading Elliot article, here is the tl;dr:

• Redux is not just a library, it's architecture that proved very effective in building scalble and maintainable code.
• While you can recreate the functionalities of Redux using the createContext and React Hooks, there are no clear gains from that and you would lose access to the powerful debugging capabilities in Redux devtools.

I hope that you are convinced and that you would join us in this tour. Now before we jump right in, please have a look at our brochure of functional programming concepts that you will see quite often inside Redux. If however, you feel confident in these concepts you can skip to the start of the tour.

TOC

• Brochure of functional programming concepts
  • Pure Functions
  • Closures
  • High order functions
  • Currying
  • Function Composition
• Start of The Tour
  • First: rootReducer, the maker of the new state
  • Second: createStore, the store maker
  • Third: middleWares, the ones in the middle
  • Fourth: enhancers, Augmenting createStore
    • The applyMiddleWare
• The Gift shop

Brochure of functional programming concepts

We are not going to try and give an exhaustive explanation of those concepts here as I believe it would be futile to try and jam all of those in a single article. However, I'll try to explain just enough so you can gain the most from this article.

Pure Functions

• Functions which their return value is determained by the arguments passed to them.
• They don't access or modify values outside of their scope.

Closures

Closures are created at the creation of new functions and they allow those functions to access the outer scope.

function outer() {
  const savedInClosure = true;
  return function() {
    if (savedInClosure) {
      console.log('I always have closure');
    }
  };
}

const doYouHaveClosure = outer();
doYouHaveClosure(); // 'I always have closure'

High order functions

Functions that receive functions as an argument and/or return another function. Also, Yup the code above is a high order function, well done for noticing 😉.

Currying

Currying is the technique of taking a function that takes multiple arguments and transforming it into a series of functions that takes one argument at a time. Now, you might scream to yourself why would I ever want to do that. Well the simple answer is "specialized Functions and separation of complexity". Let's have a look at the canonical example of currying:

// Before currying
const add_notCurrying = (x, y) => x + y;

// after currying
const add_currying = x => y => x + y;

// specialize functions
const add2 = add_currying(2);

add2(8); // 10

Now say your manager comes to you and tell you, "the add functions must do a bunch of checks and API calls before committing the first argument and must do totally different checks and API calls to commit the second argument". In the uncurried version you would have to jam all that complexity into one functions, while on the curried version of add you can separate it.

Function Composition

Function composition is the process combining functions to build more sophisticated ones, and yes in the examples above we've already done some function composition. However, the techniques that I want to explain here is the one that might give you headache first time you see it:

const myFuncs = [func1, func2, func3, func4];

const compose = arr => arr.reduce((a, b) => (...args) => a(b(...args)));

const chain = compose(myFuncs);

WAAAAAAAAIT...., Now trust me if you don't have experience in functional programming, like I was when I first saw this, having a reaction like "🤬🤬🤬🤬" is in my opinion the healthiest response you can have. Unless you are well versed in functional programming, this will not be intuitive and it might takes time for it to click in your mind, but. For now, know that all compose does is help us get to something like this function.

const composed = (...args) => func1(func2(func3(func4(...args))));

As you can see the final function we get from compose, calls the functions in the array right-to-left and passing the return of each function as the argument to the previous one. Now with that mental framework in mind try to take a look at a refactored version from the code above.

const myFuncs = [
  () => {
    console.log(1);
  },
  () => {
    console.log(2);
  },
  () => {
    console.log(3);
  },
  () => {
    console.log(4);
  }
];

let chain = myFuncs[0];

for (let index = 1; index < myFuncs.length; index++) {
  const currentRingInTheChain = myFuncs[index];

  // This is necessary to avoid recursion. Basically we storing different instances of functionsChainSoFar in closure scopes
  const functionsChainSoFar = chain;

  chain = (...args) => functionsChainSoFar(currentRingInTheChain(...args));
}

chain(); // 4 , 3, 2, 1

I hope that clarified what compose does but if you are still not 100% sure, don't worry too much. Again this might take time and it does require a mental shift.

BONSUS ROUND: what do you think the following code will log?.

const myFuncs = [
  func => () => {
    console.log(1);
    func();
  },
  func => () => {
    console.log(2);
    func();
  },
  func => () => {
    console.log(3);
    func();
  },
  func => () => {
    console.log(4);
    func();
  }
];

const hakuna = () => console.log('Mattata');

const secret = compose(myFuncs)(hakuna);

secret(); // what do you think this will log?

Give it a go but if you get stuck don't worry will revisit this again in the article.

Start of The Tour

The best way to start the tour is to see how we are creating a Redux store and what are the pieces that plays a part in that. So let's have a look at this sample from the docs.

import { applyMiddleware, createStore } from 'redux';
import thunkMiddleware from 'redux-thunk';
import { composeWithDevTools } from 'redux-devtools-extension';

import monitorReducersEnhancer from './enhancers/monitorReducers';
import loggerMiddleware from './middleware/logger';
import rootReducer from './reducers';

export default function configureStore(preloadedState) {
  const middlewares = [loggerMiddleware, thunkMiddleware];
  const middlewareEnhancer = applyMiddleware(...middlewares);

  const enhancers = [middlewareEnhancer, monitorReducersEnhancer];
  const composedEnhancers = composeWithDevTools(...enhancers);

  const store = createStore(rootReducer, preloadedState, composedEnhancers);

  return store;
}

There is a lot going on here, we are using redux-thunk, attaching the redux-devtools-extensions and a lot more. So, let's divide and conquer and separate the code above into four domains.

1. The reducers
2. The createStore functions
3. The enhancers
4. The middlewares

First: rootReducer, the maker of the new state

The rootReducer function is the first of the three arguments that createStore takes and chances are you already know that redux reducers are functions that takes the current state and an action and return a new state. You might also already know that the reducers must be pure functions. However, have you ever wondered "why reducers have to be pure functions?" 🤔. Well there is a very good reason, but unfortunately, there isn't a piece of code that I can point to and tell you "if the is NOT pure function it will ALWAYS break". Yet the fact that reducers must be pure functions is at the heart of what Redux aim to be, and that is "a state store with predictable state mutation". Redux, achieves that by adehering to three self-imposed principles:

• A Single source of truth
• State is read-only
• Changes to the state are made with pure functions

If that didn't click immediately in your mind don't worry we will see those principles again in this article.

So, reducers are pure functions. They take the current state and an action as arguments and return a new state object, got it 👍. But how about combineReducers, how does that magical function work. Well combineReducers is an awesome utility function that help us keep our code modular, but really there is nothing magical about it. combineReducers is a high order function and all what it does is:

• Extract an array from the reducer object passed into it (note that the reducer keys match the shape of the state tree).
• Return a new reducer function.
  • This function will make the next state by looping over the array of reducers keys and call the coresponding reducer.
  • Finally, it will return the next state.

Take a look at the trim down version of combineReducers:

const reducers = {
  someState: reducerOfSomeState,
  anotherState: reducerOfAnotherState
};

function combineReducers(reducers) {
  const reducerKeys = Object.keys(reducers);

  return function combinedReducer(state = {}, action) {
    const nextState = {};
    for (let i = 0; i < reducerKeys.length; i++) {
      const key = reducerKeys[i];
      const reducer = reducers[key];
      const previousStateForKey = state[key];
      const nextStateForKey = reducer(previousStateForKey, action);

      nextState[key] = nextStateForKey;
    }
    return nextState;
  };
}

const rootReducer = combineReducers(reducers);

Finally, there is an important insight that you might already noticed by looking at combineReducers, which is, each time the rootReducers gets called all of the reducers in your app will be called to create the next state.

Second: createStore, the store maker

In it's simplest form createStore return a state object and few methods. However it also accepts extra arguments that enhances 😉 the store but more on that later. For now let's make sure we understand a simpler version of createStore.

We've already seen the three principles that redux is built on. Now, let's take another look at them and try building our own redux replica 🛠:

• A Single source of truth ≈ we should have a single store object.
• State is read-only ≈ state object should not be mutated directly, instead changes should be described and emitted using a method. (If don't understand how we got that from "state is read-only" then that's fair after all it's only four words. However, the docs elaborate on the point and make the intention of the principle clear.)
• Changes are made with pure functions ≈ reducers have to be pure functions.

Adhering to the principles above our Redux replica might look something like this:

// An action to initialize our state
const ActionTypes = {
  INIT: `@@redux/INIT${Math.random()
    .toString(36)
    .substring(7)}`
};

function createStore(rootReducer, initialState) {
  let currentState = initialState;

  const dispatch = action => {
    currentState = rootReducer(action);
  };

  const getState = () => currentState;

  // setting the initial state tree.
  dispatch({ type: ActionTypes.INIT });
  return {
    dispatch,
    getState
  };
}

const myAwesomeStore = createStore(rootReducer, {});

Those few lines might not look like much, but they are equivalent to the core functionlites of Redux. Of course, Redux adds some checks to help developers avoid stupid mistakes like calling dispatch from inside a reducer or not calling dispatch with a plain object. Also our replica doesn't support middleware or enhancers, yet at least.

Third: middleWares, the ones in the middle

I knowwwwwwww 🤯, Ok ok but seriously though, it's helpfully to think of them conceptually as a middleman between the dispatcher and the the rootReducer. SPOILER ALERT: At the the Enhancer section we will see that it's a little bit more complected than that. Because actions go through middleware, there they can be changed, canceled or really anything else. There is a lot nuance in how to use middleware effectively, but in this article we will only focus on how they work inside Redux. So let's see that by examining what is probably the simplest middleware you will ever see.

const middledWare = ({ dispatch, getState }) => next => action => {
  if (typeof action === 'function') {
    return action(dispatch, getState, extraArgument);
  }
  return next(action);
};

If you are eyes skipped the first line and immediately went to the body of the final function you might have seen that the logic is straightforward. However, once your your eyes aim back at the first line, bells in your head should start ringing CURRYING. Also, If you feel at all confused by this, don't disheartened because you are not alone, In fact this questions is one of FAQs in the docs Why does the middleware signature use currying?. In the next section we will see how this function signutre is being used by Redux inside applyMiddleware, for now just remember the following from the middleware signature above.

1. the first function will get called with the an object that has two properties dispatch and getState (the middleWareApi).
2. The second function gets called with next (the next middleWare).
3. The final function act as a dispatch and it gets called with an action.

FUN FACT 🤓: You might not have noticed it, but the code above is actully the source for redux-thunk.

Fourth: enhancers, Augmenting createStore

As you might have already guessed, enhancers are high order functions that take createStore and return a new enhanced version of createStore. Take a look a this sample implementation.

const ourAwesomeEnhancer = createStore => (reducer, initialState, enhancer) => {
  const store = createStore(monitoredReducer, initialState, enhancer);
  //  add enhancer logic

  return {
    ...store
    //   you can override the some store properties or add new ones
  };
};

While it's rare that you might need to craft your own enhancers, you are likely already using at least one, applyMiddleware. Oh Yes, this is might be shocking to some but the notion of middlewares is not in Redux createStore. We add middlewares capabilities to our store by using the only enhancer that ships with Redux applyMiddleware.

To be specific the actually enhancer is the returned function from applyMiddleware but they are referenced interchangeably in the docs.

The enhancer function is first called from inside createStore and there isn't anything magical or overly complected. As you will soon see soon. However before we see the code, we need to address an urgent problem 🚧. Because enhancers take createStore and returned enhanced version of createStore, you can see how using those terms to explain the mechanics of the enhancer can get convoluted very quickly. As such for the purposes of this section I'm introducing what I dubbed as placeholders terms:

• The originalStoreMaker: the createStore function that you can import from Redux.
• The storeMaker: any function that has the same signature as the original storeMaker (accepts the same arguments and return the same API).

Alright then now let's see some code. Take a look at our Redux replica from above, now modified to accept enhancer.

function createStore(rootReducer, initialState, enhancer) {
  let currentState = initialState;

  // Now accepts enhancers
  if (typeof enhancer !== 'undefined' && typeof enhancer === 'function') {
    return enhancer(createStore)(reducer, preloadedState);
  }

  const dispatch = action => {
    currentState = rootReducer(action);
  };

  const getState = () => currentState;

  // setting the initial state tree.
  dispatch({ type: ActionTypes.INIT });
  return {
    dispatch,
    getState
  };
}

As I said nothing magical. It's just function that takes a storeMaker and return an enhanced storeMaker. Of course that's not to say that enhancer can't be complex. It's to say that the complexity of an enhancer is encapsulated inside it and determined by what it try to achieve AND not by how it interact with a storeMaker. This subtle distinction is important as we in the rest of this section examine the implementation of the most widely used enhancer in Redux, applyMiddleware.

The applyMiddleWare

function applyMiddleware(...middlewares) {
  return createStore => (...args) => {
    const store = createStore(...args);
    let dispatch = () => {
      throw new Error(
        'Dispatching while constructing your middleware is not allowed. ' +
          'Other middleware would not be applied to this dispatch.'
      );
    };

    const middlewareAPI = {
      getState: store.getState,
      dispatch: (...args) => dispatch(...args)
    };
    const chain = middlewares.map(middleware => middleware(middlewareAPI));
    dispatch = compose(...chain)(store.dispatch);

    return {
      ...store,
      dispatch
    };
  };
}

OK that was the whole thing now let's unpack it. Let's first quickly understand the curring part at the top. What we really need to know here is what arguments will those functions gets called with, luckily for us we already know that:

• applyMiddleware takes middlewares return an enhancer.
• enhancers take a storeMaker and return an enhanced storeMaker.

From that we can bring our focus back to the body of the final function and noting what it has in closure.

// In closure: [middlewares], createStore

// This final function is a storeMaker
(...args) => {
  const store = createStore(...args);
  let dispatch = () => {
    throw new Error(
      'Dispatching while constructing your middleware is not allowed. ' +
        'Other middleware would not be applied to this dispatch.'
    );
  };

  const middlewareAPI = {
    getState: store.getState,
    dispatch: (...args) => dispatch(...args)
  };
  const chain = middlewares.map(middleware => middleware(middlewareAPI));
  dispatch = compose(...chain)(store.dispatch);

  return {
    ...store,
    dispatch
  };
};

Much better, now Somewhere in the code this storeMaker will get called with rootReducer and initialState. Jumping inside the function, the first two lines create the store and assign a function to a variable named dispatch. As the error message say this is done to prevent developer from accidentally calling dispach inside a storeMaker.

// In closure: middlewares and the original createStore.

// + more code above
const store = createStore(...args);
let dispatch = () => {
  throw new Error(
    'Dispatching while constructing your middleware is not allowed. ' +
      'Other middleware would not be applied to this dispatch.'
  );
};
// + more code below

Before looking at the second piece of code try to remember the signature of a middleware in Redux that we've seen before. Here the first of those curried function of each middleware gets called. After this part of code we will get an array of functions where each has a reference in their closure to the middleWareAPI object.

// In closure: middlewares and the original createStore.

// + more code below
const middlewareAPI = {
  getState: store.getState,
  dispatch: (...args) => dispatch(...args)
};

const chain = middlewares.map(middleware => middleware(middlewareAPI));
// + more code below

Brace yourself, the next line is probably the most intimidating part of the code. Largely because of the compose function. Nonetheless, give it a go 💪 and take this hint: all the functions in the chain variable return a function.

// In closure: middlewares and the original createStore.

// + more code below
dispatch = compose(...chain)(store.dispatch);
// + more code below

If you went through our Brochure of functional programming concepts, seeing the code above might rang few bells inside your head. Because this code look very similar to the code from the BONUS ROUND in the function composition sub-section. Speaking of which, what did you guess the code from there will log?....

well let's have another look.

const myFuncs = [
  func => () => {
    console.log(1);
    func();
  },
  func => () => {
    console.log(2);
    func();
  },
  func => () => {
    console.log(3);
    func();
  },
  func => () => {
    console.log(4);
    func();
  }
];

const hakuna = () => console.log('Mattata');

const secret = compose(myFuncs)(hakuna);

secret(); // 1, 2, 3, 4, Matata

Yes, if you tried to run the code in the console, you've seen that it logs 1, 2, 3, 4, Matata. The code seems to have ran left-to-right. Except after the returned function from compose gets called with hakuan, we don't have an array anymore!. Where is the left-to-right coming from?? It's because of Closures and callbacks. Ok I'm guessing that wasn't super helpful 😅. No worries though, I'll try to explain a little better but first to avoid confusion, I'm going to need once again to introduce new placeholders terms.

• level1Func: any function inside the myFuncs array.
• level2Func: any function that is returned by a level1Func.

Alright, let's recap what is it that we want to achieve. We want somehow for all of level2Func to run in order from left-to-right. We can see in the array that each level1Func takes a callback as an argument and then that callback gets called inside it's level2Func. So it's seems that we can achieve our goal if somehow each level1Func got called with the next level2Func.

OK Ok gears are turning ⚙⚙ we are closing into something. We know by now that compose will return a function that will call functions right-to-left and passing each return to the previous function in the array. But god it's too hard running that code inside my mind 😵. Maybe if we saw how that would look like differently.

const composed = (...args) => func1(func2(func3(func4(...args))));

AHA!, As composed gets called and the functions gets called right-to-left, each level1func will be called by the next level2func. Well done You got it 👏. That is exactly how we end-up with a function that resemble a chain in how it runs left-to-right. The last thing to point out and hammer home is that hakuna function is the first argument that gets passed by composed and as such it's the last function in the chain

Now with this new found understanding let's look back at the line code from applyMiddleware. I hope you can see by now how the chain is made, that each middleWare will calls the next one and that the last function in the chain is store.dispatch which sets the new state (but NOT create it) to the store.

// In closure: middlewares and the original createStore.

// + more code below
dispatch = compose(...chain)(store.dispatch);
// + more code below

Finally, because this is after all a storeMaker function we return the store and of course override the dispach property.

return {
  ...store,
  dispatch
};

The Gift shop

The above is everything about how the core of Redux works. There are few more methods that ships with Redux and while they will not alter your understanding of how Redux works, they are worth mentioning. Here is a quick list.

• replaceReducer: Give you the ability replace the rootReducer of the store. Interestingly in some setups you can use it to add new reducers rather than just replacing the whole rootReducer.
• subscribe: Give you the ablity to pass a callback that will get called after any action gets dispatched.
• observable: Can be used in libraries like RxJS. Also allowes you to subscribe to changes.

Congratulation you made it 🎊🎊👏👏. Now you understand how Redux works under the hood and hopefully have gained an appreciation for the power functional programming.