DEV Community: Öner Zafer

Understanding Micro Frontends

Öner Zafer — Mon, 18 Feb 2019 10:46:01 +0000

As a frontend developer, all these years you were developing monoliths, even though you already knew it was a bad practice. You divided your code into components, used require or import and defined npm packages in your package.json or mounted sub git repositories into your project, yet you ended up building a monolith. It’s time to change it.

Why is your code is a monolith?

All frontend applications are a monolithic application in nature, except apps that already implemented micro frontends. The reason is if you are developing with the React library and if you have two teams both should be using the same React library and both teams should be in sync on deployments and always will be conflicting during code merges. They are not separated completely and most probably they are maintaining the same repository and have the same build system. The exit from a monolithic app is formulated as microservices. But it’s for backend! 😱

What is actually microservices?

In general and the most simplistic explanation for microservices is, it is a development technique which allows developers to do independent deployments for different parts of the platform without harming other parts. The capability of independent deployment allows them to build isolated or loosely coupled services. To put this architecture on a more stable base there are some sets of rules to follow which can be summarized as follows: Each service should have only one task and it should be small. So the team who is responsible for this service should be small. About the size of the team and the project, one of the coolest explanation on the internet has been done by James Lewis and Martin Fowler as below:

In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon’s notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we’ve seen setups where a team of half-a-dozen would support half-a-dozen services.

I created a simple sketch to give a visual explanation for monolith and microservices:

As you can understand from the drawing above each service in microservices is a standalone application except UI. UI is still in one piece! When all services handled by one team and while the company is scaling up, the Frontend team will start struggling and won’t be able to keep up with it and this is the bottleneck of this architecture.

Additional to its bottleneck, this architecture will result in some organizational problems too. Assume that the company is growing and will adopt agile development methodologies which require cross-functional small teams. On this common example, naturally, product owners will start to define the stories as frontend and backend tasks and the cross-functional team will never be a real cross-functional unit. It will be a shallow bubble which looks like an agile team but it will be separated deep inside. More on that managing this kind of team will be really a nail-biting duty. On each planning, there would be a question if there were enough frontend task or were there enough backend tasks in the sprint. To address all the problems described here and numerous others, a couple of years ago the micro frontends idea has emerged and it started to gain popularity very quickly.

The solution to the bottleneck problem in microservices: Micro Frontends 🎉

The solution is actually quite obvious, embrace the same principles which are working for backend services for many years: Divide the frontend monolith into small UI fragments. But UI is not quite similar to services, it is the interface between the end user and the product, it should be consistent and seamless. Even more, in the era of Single Page Applications, the whole application is running on the browser on the client side. They are not simple HTML files anymore, instead, they are sophisticated pieces of software reaching really complex levels. Now I feel like a definition of the micro frontend is necessary:

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end , from database to user interface. (micro-fontend.org)

From my experience so far, for many companies, it is really hard to directly adopt the architecture proposed above. Lots of others have a huge legacy burden which is nailing them down from migrating to a new architecture. For that reason a softer midway solution which is more flexible to allow easy adoption and secure migration is vital. After overviewing the architecture in more detail I will try to provide some insight into an architecture which is confirming the proposal above and allowing more flexible ways to follow. Before diving into the details, I need to build up some terminology.

The overall structure and some terminology

Let’s imagine we are dividing the monolithic app structure vertically through business functionalities. We will end up with several smaller applications which has the same structure with the monolithic application. But if we add a special app on top of all these small monolithic apps, users will communicate with this new app and it will compose the old monolithic UI from each small app into one. This new layer can be named as stitching layer because it gets the produced UI parts from each microservice and combines into one seamless UI for the end user and this would be the most straight forward implementation of a micro frontend 🤩

For a better understanding, I will refer to each small monolithic app as micro-app since they all are standalone apps and not microservices only, they all have UI parts and each represents an end-to-end business functionality.

As it’s already known, today’s frontend ecosystem is highly versatile and can be extremely complex. So this kind of straightforward solutions will not be sufficient enough when the time comes to implement it for a real product.

Problems to solve

While this article was just an idea, I started a Reddit thread to discuss the idea. Thanks to the community and their responses I can list some problems to be addressed and I will try to describe them one by one.

How to create a seamless and consistent UI experience when we have a totally independent standalone micro-apps ?

Well, there is no silver bullet answer to this question but one of the ideas is creating a shared UI library which is a standalone micro-app itself too. By that way, all the other micro-apps will depend on that shared UI library micro-app. In that case, we just created a shared dependency and we killed the idea of standalone micro-apps.

Another idea can be sharing CSS custom variables on the :root level. The advantage of this solution would be the global configurable theme between apps.

Or we may simply share some SASS variables and mixins between app teams. The downside of this approach would be the repetitive implementation of UI elements and the integrity of the designs of similar elements should be checked and validated always for all the micro-apps.

How do we make sure that one team is not overriding the CSS written by another team?

One solution is CSS scoping via CSS selector names which are carefully selected by the micro-app name. By putting this scoping task to the stitching layer will reduce the development overhead but will increase the responsibility of the stitching layer.

Another solution can be forcing each micro-app to be a custom web component. The advantage of this solution is the scoping done by the browser, but it comes with a price: it is nearly impossible to do server-side rendering with shadow DOM. Additionally, there is no 100% browser support for custom elements yet especially if you have to support IE.

How should we share the global information between micro-apps?

This question points out to one of the most concerned issues on this topic, but the solution is pretty easy: HTML 5 has pretty powerful functionalities which are not well known by the majority of frontend developers. For example, custom events are one of them and it is the solution for sharing information within the micro-apps.

Alternatively any shared pub-sub implementation or T39 observable implementation can do the trick. If we want a more sophisticated global state handler we can implement a shared miniature Redux, by that way we can achieve more reactive architecture.

If all micro-apps are standalone apps, how do we do client-side routing?

This problem is up to each implementation by design. All major modern frameworks are providing powerful routing mechanisms on the client side by using browser history state. The problem is which application is responsible for the routing and when.

My current pragmatic approach is creating a shared client router which is responsible only from the top level routes and the rest belongs to the respective micro-app. Let’s say we have a /content/:id route definition. The shared router will resolve /content part and the resolved route will be passed into ContentMicroApp. ContentMicroApp is a standalone server and it will be called with /:id only.

We must have the server-side rendering for sure but is it possible with micro-frontends?

Server-side rendering is a tricky problem. If you are considering iframes to stitch the micro-apps then forget about server-side rendering. Similarly, web components for stitching task are not powerful than iframes. But if each micro-app is able to render its content on the server side then the stitching layer will be responsible only for concatenating the HTML fragments on the server side.

Integration with a legacy environment is vital! But how?

To integrate a legacy system, I would like to describe the strategy of my own that I named as “gradual invasion”.

First, we have to implement the stitching layer and it should have a functionality of transparent proxy. Then we can define the legacy system as a micro-app by declaring a wildcard route to it: LegacyMicroApp. So all the traffic will hit the stitching layer and will be proxied to the legacy system transparently since we don’t have any other micro-apps yet.

Next step will be our first gradual invasion movement: We will take a small bite from the LegacyMicroApp by deleting the main navigation and replacing it with a dependency. This dependency will be a micro-app implemented with a shiny new technology: NavigationMicroApp.

Now the stitching layer will resolve each route as LegacyMicroApp and it will resolve the dependency as NavigationMicroApp and serve them by concatenating these two.

Then the next bite will come for the footer by following the same pattern with the main navigation.

And then we will continue taking similar small bites from LegacyMicroApp until nothing left from it.

How to orchestrate the client side so we won’t need to reload the page each time?

Well, the stitching layer solves the problems on the server side but not on the client side. On the client side, after loading already glued fragments as a seamless HTML, we don’t need to load all the parts each time on URL change. Therefore we have to have some mechanism which loads fragments asynchronously. But the problem is, these fragments may have some dependencies and these dependencies need to be resolved on the client-side. That means a micro frontend solution should provide a mechanism to load micro-apps and also some mechanism for dependency injection.

According to the questions and possible solutions above, I can summarize everything under the following topics:

Client-side

Orchestration
Routing
Isolation of micro-apps
App to app communication
Consistency between micro-app UIs

Server-side

Server-side rendering
Routing
Dependency management

A flexible and powerful yet simple architecture

So, it worthed the wait all along this article! The basic elements and requirements of a micro frontends architecture finally started to reveal itself!

With the guidance of these requirements and concerns, I started to develop a solution which I named as microfe. 😎 Here I will describe the architectural goal of this project by underlining its main components in an abstract manner.

It is easy to start with client-side and it has three separate backbone-structures: AppsManager, Loader, Router and one extra MicroAppStore.

AppsManager

AppsManager is the core of client-side micro-app orchestration. The main functionality of AppsManager is to create the dependency tree. When all of the dependencies of a micro-app are resolved, it instantiates the micro-app.

Loader

Another important part of client-side micro-app orchestration is the Loader. The responsibility of the loader is fetching the unresolved micro-apps from the server-side.

Router

To solve client-side routing I introduced the Router into microfe. Unlike the common client-side routers, the microfe router has limited functionalities, It does not resolve the pages but micro-apps. Let’s say we have an URL /content/detail/13 and a ContentMicroApp. In that case, the microfe router will resolve the URL up to /content/* and it will call ContentMicroApp /detail/13 URL part.

MicroAppStore

To solve micro-app to micro-app client-side communication I introduced MicroAppStore into microfe. It has the similar functionalities of Redux library with a difference: It is resilient to asynchronous data structure changes and reducer declarations.

The server-side part can be a little bit more complicated in implementation but simpler in structure. It consists of only two main part StitchingServer and lots of MicroAppServer.

MicroAppServer

Bare minimum functionality of a MicroAppServer can be summarized as init and serve.

While a MicroAppServer booting up first thing it should do is calling SticthingServer register endpoint with a micro-app declaration which defines the micro-app dependencies, type, and URL schema of MicroAppServer. I think there is no need to mention about serve functionality since there is nothing special about it.

StitchingServer

StitchingServer provides a register endpoint for MicroAppServers. When a MicroAppServer registers itself to StichingServer, StichingServer records the declaration of the MicroAppServer.

Later the StitchingServer uses the declaration to resolve the MicroAppServers from the requested URL.

After resolving a MicroAppServer and all of its dependencies, all relative paths in CSS, JS and HTML will be prefixed with related MicroAppServer public URL. One additional step is prefixing the CSS selectors with a unique identifier of MicroAppServer to prevent collision between micro-apps on client-side.

Then the main responsibility of StitchingServer comes into the scene: composing and returning a seamless HTML page from all collected parts.

A Glimpse of Other Implementations out There

Even before it was called micro frontends by 2016, lots of big companies were trying to solve similar problems such as Facebook with its BigPipe. Nowadays the idea is gaining momentum. The companies with different sizes are interested in the subject and investing time and money on it. For instance, Zalando open-sourced its solution which is called Project Mosaic. I can say that microfe and Project Mosaic are following similar approaches with some vital differences. While microfe embraces full decentralized route definitions to empower more independence for each micro-app, Project Mosaic prefers centralized route definition and layout definitions for each route. By that way, Project Mosaic allows easy A/B testing and dynamic Layout generation on the fly.

There are some other approaches to the subject such as using iframes as stitching layer which is obviously not on the server-side but on the client-side. This is a very simple solution which does not require so much server structure and DevOps involvement. The job can be done by the frontend team only, so it creates a less organizational burden on the company and also it is less costly.

There is a framework already out there called single-spa. The project relies on naming conventions of each app to resolve and load micro-apps. Easy to grasp the idea and follow the patterns. So it can be a good initial introduction for experimenting the idea on your own local environment. But the downside of the project is you have to build each micro-app in a specific way so they can play nice with the framework.

Final Thoughts

I believe that micro frontends topic will be discussed more frequently in time. If the topic manages to get the attention of more and more companies, it will be the defacto way of development in large teams. It can be really beneficial in the close future for any frontend developer to grasp some insights and experience on this architecture.

Consider contributing

I’m heavily experimenting on micro frontends with a noble goal in my mind: Creating a micro frontend framework which can solve the majority of problems without compromising of the performance and ease of development and testability. If you have any bright ideas to show, do not hesitate to visit my repositories, open an issue or reach me out via comments below or Twitter DM. I will be there to help you! 🙂

DIY Redux with RxJS: Part 3

Öner Zafer — Tue, 15 Jan 2019 11:51:00 +0000

Photo by Steve Halama on Unsplash

So far, in the previous two posts, I covered the topics “How to Create a Redux Library with RxJS” and “How to Write Redux Middlewares”. Before starting the 3rd and the last part of the series, I would recommend you to check the first 2 parts below:

In this part, I will create a HOC (Higher Order Component) to connect RxDx with React.Component. I assume that you already know about React.Component, so that I won’t be explaining it again. But I need to explain HOC s which is the heart of what I will demonstrate below.

What the heck are these Higher-Order Components?

Basically, HOC is a class decorator. But what is a class decorator? Sometimes while we are coding we start feeling that all classes we create have the same basic properties. At that point, we realize that we are repeating ourselves which is completely against the DRY rule. So we start trying to find a way to isolate the repeating parts. Or while we are coding we need to add a feature to our classes without changing the implementation of it. In both cases, our purpose is to achieve code sharing between classes. So the very best answer to our problem described above is kind of a class factory function.

Class factory functions are functions which returns a class. (welcome to the weirdness of the javascript world).

// the most primitive description of a class factory function
function **giveMeClass** (someArguments) {
   return class **SomeDynamicallyGeneratedClass** {}
}

The primitive class factory function is not a class decorator yet. To be a class decorator, a class factory function requires a class as an argument and the returning/produced class will be an extended version of the input class:

//enhance decorator
function **ehance** (targetClass) {
   return class **EnhancedClass** extends **targetClass** {
      constructor() {
         this.isEnhanced = true;
      }
}

//usage in enviroment where experimental decorators allowed
@enhace
class **Normal** {}

console.log(new Normal().isEnhanced) // true

//usage in enviroment where experimental decorators not allowed
class **Normal** {}

const **Enhanced** = enhance(Normal);

console.log(new Enhanced().isEnhanced) // true

As it’s mentioned before, HOC s are also decorators and works exactly the same way as a class decorator. A HOC takes a React component -which is a class- and returns another React component. For detailed documentation of HOC s you may follow the link below but if you are in the mood TL;DR I will continue with a summary of it:

Higher-Order Components - React

Now it’s time to extend the decorator example above to make it a HOC by replacing class input and output with a React Component. I have to mention that using React component as input/output gives us a couple of opportunities, but I will continue with recommended one which is wrapping the original component with another:

// a primitive HOC which makes A component great nothing :)
function **makeGreat** (WrappedComponent) {
   return class **EnhancedComponent** extends **React.Component** {
      constructor() {
         this.state = {isGreat: true}
      }

      render() {
         return < **WrappedComponent** {...this.props, ...this.state} />
      }
   }
}

// usage
class **LameComponent** extends **React.Component** {
   render() {
      return <div>{this.props.isGreat? 'Great': 'Lame'}</div>
   }
}

const **GreatComponent** = **makeGreat** (LameComponent);

< **LameComponent** /> // this will render <div>Lame</div>
< **GreatComponent** /> // this will render <div>Great</div>

// alternative usage if experimental decorators are allowed
@makeGreat
class **LameComponent** extends **React.Component** {
   render() {
      return <div>{this.props.isGreat? 'Great': 'Lame'}</div>
   }
}

< **LameComponent** /> // this will render <div>Great</div>

I believe we need to go deeper right now, so buckle up. At this point, you still don’t know about RxDx you may check it from this link because I will explain how to connect RxDx to React.Component.

Stitching the RxDx with a React Component: A real-life example of HOC

Did you remember the selectors from Part 2 and store.select function from Part 1? This is the moment they will come in handy since we will use them as the cement between RxDx and React.Component. Store.select get a selector or a series of strings and return an observable to allow us to be notified of state updates. We can subscribe to all of these observables in componentDidMount and on each update we can re-render the component by using forceUpdate and to prevent memory leaks we have to unsubscribe from all subscriptions in componentWillUnmount:

class **SomeUglyComponent** extends **Component** {
**componentDidMount** () {
      this.subscription = store
          .select(someSelector)
          .subscribe((update) => {
             this.setState({data: update});
             this.forceUpdate();
   }
**componentWillUnmount** () {
      this.subscription.unsubscribe();
   }
**render** () {
      return (<div>{ this.state.data }</div>);
   }
}

Ok, I have to admit that this will work but SomeUglyComponent is not that ugly as we have only one of it. Let’s imagine we have to implement such components tens of, hundreds of times. Now it seems uglier, right? A generalized solution for this repeating task is required and the SomeUglyComponent should be as simple as possible so we can call it SimpleAndNiceComponent. The desired SimpleAndNiceComponent would be as follows:

const **SimpleAndNiceComponent** = **connect** ({
   data: store.select(someSlector)
})(({data}) => <div> {data} </div>);

//or
@ **connect** ({
   data: store.select(someSlector),
})
class **SimpleAndNiceComponent** extends **Component** {
**render** () {
      const {data} = this.props;
      return <div> {data} </div>;
   }
}

So how do we achieve this simplicity and how we wire observables to props? The answer is hidden inside the HOC s. We need one step further than simple HOC , what we need is a HOC factory. I will implement a connect function which takes observables and returns a HOC which takes a React.Component and returns an enhanced/wrapped React.Component:

For the sake of clarity, the example above is simplified. For sure, if we need to use it for production, we have to think more about edge usage cases and debuggability and also error prevention and recovery strategies. Even though it’s a simplification this code piece will do the trick and will allow us to write simpler components with a generalized connect mechanism with async nature of observables and sync nature of React.Component.

Final, final, final words

Yes, finally we have all in one RxJS powered Redux equivalent library. All I can say that I learned a lot working on this experiment and I wanted to share it hoping that my journey will help others. Next steps will be using it, growing it and loving it!

If you managed to read up to this point and bared with me through this experiment, I will be extremely glad. A big thanks to you! Please don’t forget to clap or drop your comment below.

If you want to contribute to my experiment and help me to make it a real library which can possibly solve real-life problems, don’t hesitate to click the link below and contribute. You will be only welcomed!

onerzafer / rxdx

redux like library for react based on rxjs

RxDx

RxDx is a Rxjs base Redux like state management library and it icludes all necessary tooling inside.

heaviliy inspired from great libraries redux, react-redux, redux-observable and ngrx

Motivation

Basic idea behind this library is bringin the full power of RxJS into react world with a familiar interface of Redux withiot relying on some middleware jungle of libraries.

Installation

npm install rxdx --save

yarn add rxdx

How to Use

Store

Unlike react-redux RxDx does not rely on context so no need to introduce Provider on App.js. But on the contrary it requires an exported Store to function. In these sample codes it is suggested to have a saperate store.js for initializing the Store and improting it when neccessary. Intentionally the interface of createStore is just like react-redux interface.

//store.js
import {
  createStore,
  applyMiddleware,
  combineReducers,
  devToolsMiddleware,
  effectsMiddleware
} from "rxdx/lib/rxdx";
import { todoEffects

…

View on GitHub

DIY Redux with RxJS: Part 2

Öner Zafer — Mon, 07 Jan 2019 06:31:59 +0000

Photo by Steve Halama on Unsplash

In case you didn’t read the part one I would recommend you to read it. The first part is covering how to implement the core functionalities of Redux.

DIY Redux with RxJS = RxDx

Öner Zafer ・ Jan 17 '19 ・ 5 min read

#redux #javascript #rxjs #react

At DIY Redux with RxJS => RxDx Part 2, I will reveal the internals of some most popular and widely used Redux middlewares. As I mentioned in the first part of the article -which you can find above-, my goal is to do an experiment to combine RxJS and all widely used Redux middlewares into a library which can be found below:

onerzafer / rxdx

redux like library for react based on rxjs

RxDx

RxDx is a Rxjs base Redux like state management library and it icludes all necessary tooling inside.

heaviliy inspired from great libraries redux, react-redux, redux-observable and ngrx

Motivation

Basic idea behind this library is bringin the full power of RxJS into react world with a familiar interface of Redux withiot relying on some middleware jungle of libraries.

Installation

npm install rxdx --save

yarn add rxdx

How to Use

Store

//store.js
import {
  createStore,
  applyMiddleware,
  combineReducers,
  devToolsMiddleware,
  effectsMiddleware
} from "rxdx/lib/rxdx";
import { todoEffects

…

View on GitHub

Before diving into the subject, it is always good to review the required signature of redux middlewares.

(storeAPI) => (next) => (action) => state

Before I start, I need to confess, when I finished the createStore function I thought with bold confidence that all available middlewares of redux will work for my version of it. Actually, it worked but not for most of them, not for widely used ones :( So I had to provide these libraries/middlewares by re-implementing them or at least implementing similar ones. Here, we go!

A different approach to redux-observable

Under normal conditions, Redux does not implement/has no intention to implement TC39 Observable therefore it is not compatible with RxJS by default.

Here I have to mention the use cases of observables; if you need to operate on streams of events, then it is probably better to use an observable. What kind of operations am I talking on? Merging two streams into one, filtering, mapping or redirecting a stream. For more technical detail check [_here](https://rxjs-dev.firebaseapp.com/guide/observable)._

When implementing a Redux store you will definitely notice that you have to create lots of actions. I have to admit that actions are pretty similar to events and on the runtime, they will be triggered hundreds of times. So this must be the point where redux-observable catches Redux as a streaming event source. By doing so, it creates a good opportunity for developers who are willing to create some asynchronous side effects on each selected action. For detailed documentation on redux-observable , you may check here. TL;DR The magic happens in a function called createEppicsMiddleware that has the signature below:

const createEpicsMiddleware = (rootEpic) => (storeAPI) => (next) => (action) => state

To be honest, when I checked the documentation, I didn’t like the way we need to consume this library. For me, the usage of Effect from NgRx is more classy :) So I decided not to mimic the API of redux-observable, yet the functionality should be there. So I ended up something as follows.

As I mentioned before I really like NgRx style usage and I borrowed Effect decorator and ofType tappable function.

Effect decorator is as simple as adding a type on the original variable. And if your environment supports experimental decorators the usage can be as follows:

@Effect()
const someCoolAsyncSideEffect = action$
   .pipe(ofType('SomeCoolAction', 'OrEvenCoolerAction'))
   .pipe(map(() => {type: 'SomeOtherCoolAction'}));

Unfortunately, if your environment does not support experimental decorators this code piece won’t look that much handsome.

Reselect

While I was implementing the createStore function in the first part of this story, I implemented a select function in the exposed store object by trusting my gut feeling. This decision revealed itself as pretty useful in implementing the reselect library of RxDx . To be frank, reselect is completely compatible with RxDx , yet I was experimenting and I needed to challenge myself to combine all libraries into it .

What does reselect do? It takes the state or a state portion and returns a portion of it. So what’s the deal? We can achieve the same functionality without it like the example below:

const reselect = (state, key) => state[key];

The example above totally undermines the power of this simple yet incredibly useful library. The deal is, the reselect provides a simple repeatable function which has memoization inside to speed up our -possibly complex- filtering on states.

This function will have a key functionality while we are consuming the RxDx store in react components. The usage of a selector as simple as follows:

Redux Dev Tools Middleware

I thought that the absence of the integration to redux dev tools would be a big missing part of RxDx. Then I started reading the API documentation of dev tools and I found what I need __REDUX_DEVTOOLS_EXTENSION__.connect

After this point, it was super easy to combine everything into a middleware:

Finally, I reached a point which I can create a store, add some reducers, apply built-in optional middlewares and select a specific state child with memoization:

Final words until next time

I strongly recommend such experiments for anybody who wants to learn more about any library or any kind of design patterns or coding styles. It will cause you to question lots of things you do during normal daily coding tasks of yours.

Next time I will continue my experiment with how to combine a redux-like-library with react components and it will include lots of information about HOCs and decorators.

If you are also a self-learner like me and a little bit impatient on top of it, let’s just try it yourself until I release the 3rd and the last part of the RxDx article.

Here is my repo to start your own experiment:

onerzafer / rxdx

redux like library for react based on rxjs

RxDx

RxDx is a Rxjs base Redux like state management library and it icludes all necessary tooling inside.

heaviliy inspired from great libraries redux, react-redux, redux-observable and ngrx

Motivation

Basic idea behind this library is bringin the full power of RxJS into react world with a familiar interface of Redux withiot relying on some middleware jungle of libraries.

Installation

npm install rxdx --save

yarn add rxdx

How to Use

Store

//store.js
import {
  createStore,
  applyMiddleware,
  combineReducers,
  devToolsMiddleware,
  effectsMiddleware
} from "rxdx/lib/rxdx";
import { todoEffects

…

View on GitHub

If you are interested in RxDx and enjoyed the article so far, please don’t forget show your appreciation. If you share your ideas and feedback below, I would only be glad!

Thanks for reading!

This post originally published on hanckernoon.com. On dev.to it is slightly adapted to platform

DIY Redux with RxJS: Part 3 on hackernoon

DIY Redux with RxJS = RxDx

Öner Zafer — Sat, 29 Dec 2018 13:14:46 +0000

Photo by Steve Halama on Unsplash

State management is a must if you are developing a huge app, and using proper state management can be a real lifesaver. On React, Redux is our lifeguard, and on Angular, we have NgRx for this role.

I think, on the architectural level both have similar boilerplates and if you grasp one already, your learning curve for the other will be smoother. What I really like on NgRx is not the library itself but RxJS, which is really the most amazing library for handling the streaming events.

While I was investigating on Redux and NgRx, I realized that there are hardly any people who use Redux by itself without lots of helper libraries, but on the other hand the case is not similar for NgRx as it provides all in one solution in most of the cases. So I decided to make an experiment to combine RxJS and all Redux helper libraries for creating a super duper state management library for React with similar fingerprints like Redux.

At this point, the recipe was obvious: Firstly, I reimplemented Redux with RxJS and added some middleware salt on top of it and it’s ready to serve! So with this post, I will try to explain how I did it.

Hint: I released the alpha version of the resulting library already and you can check it ** here **.

Step 0: Deconstruct Redux and Related Libraries

Redux provides mainly a createStore function which obviously creates a store. This createStore takes a reducer, initial state, and an enhancer.

Reducer is a function which takes a state and returns a state. Quite simple, right? But wait a minute, I will need more than one reducer, which means I will need a helper function to combine all reducers into one big fat reducer.

For a similar purpose, Redux has combineReducers function which is very handy. An initial state is an object which may be an empty or undefined state at all. Even simpler! The enhancer is a little bit weird which has the following signature:

(createStore) => (reducer, initialState) => store

Again I will need more than one enhancer and again I will need a helper function to combine all enhancers into one which is called applyMiddleware.

When we run createStore function it returns an object similar to the simplified object below:

{
   getState: () => state,
   subscribe: () => unsubscribe,
   dispatch: (action) => void
}

getState returns the current state. Subscribe returns an unsubscribe object but if I’m planning to use RxJS I can use its own subscription and unsubscription. As a result, I will have a simpler implementation. Dispatch functions actually pass the action to the reducer. And again RxJS will become handy here which has its own dispatching mechanism.

So, I have created a TODO list to achieve my goal:

Implement createStore(reducer, initialState, enhancer) => store
Implement combineReducer(structuredReducersObject) => reducer
Implement applyMiddleware(createStore) => (reducer, initialState) => store

Let’s start!

Step 1: createStore with the help of RxJS BehaviourSubject and operators

At any time a store consumer calls getState, store should return the current state back. If I use BehaviourSubject as state source the implementation of internal store state will be easier since similar behavior from RxJS observables belongs to BehaviourSubject by calling BehaviourSubject.value.

This is how it’s done:

I will rephrase what I did here in HUMAN words. In the createStore function, I created a Store with given reducer and initialState. If there is an enhancer I pass a fake createStore function which will return already created Store , as a result, it will return enhanced Store. Then I dispatch the first action and return the created or enhanced store. So when the createStore function is called, we can use the store reference in our app. Maybe this reference can be passed to some react context provider.

As you can see, the most complicated part is the select function and it is not a must-have feature at all. I added this part to have an interface such as reselect. As I can understand so far, the subscribe function of Redux is not a widely used feature of it but react-redux library uses it to get the updates and rerender the component (if anybody uses it directly please comment it below, because in my experiment I couldn't find any use case for my subscribe function).

So, the createStore function so far should be able to work for one reducer and one enhancer, which means the backbone of my RxJS based Redux library is ready to be named: From now on I will call it RxJs + Redux = RxDx.

Step 2: How to create a combineReducers function?

When I checked the combineReducers source code from Redux, I realized that it takes an object (which can be nested) of which the keys have a reducer and as a result returns a bigger reducer.

Let start with the following initial code:

For now, I will avoid error prevention and error handling (I will trust whoever uses this function). The idea here is to loop over the keys of reducers object and to call the attached reducer with related state part and the action.

As a result, all reducers will update only the related part of the state and I will combine the results in the same structure and return them. While I was trying to code this function I noticed the name of the function has the solution itself: Array.reduce.

Step 3: The Magical applyMiddleware function

If you take a closer look into the Redux implementation, the biggest magic happens with only one function named compose. What does the compose function do? Actually, it is pretty simple as it takes a list of functions, wraps each of them by passing the second wrapped one to the first, the third to the second and so on, and finally returns this weird nested function:

As you can see above, the functions a,b,c,d,e becomes A(B(C(D(E(…args))))). This behavior is crucial because all enhancers should be able to be called on each action and all of them should be able to alter the action or dispatch a new one or even delay the original one. There is one more restriction to enhancers as they should follow the signature below:

// sample enhancer signature
const enhancer => (createStore) => (next) => (action) => state

Finally, I ended up with the following function by omitting the error handling and error prevention parts:

Final Words

Actually, RxDx currently includes lost of other functionalities and if you are willing to check them out and all the example usages, you may check the repo and sample todo app repo.

This is the core part of RxDx and I am planning to explain it further how to connect the RxDx to React components with a follow-up article to this one.

With the follow-up article, I am hoping to shed some light into the inner structure of react-redux and then I will move forward to react-observable, then reselect libraries.

If you are interested in RxDx, and enjoyed the article so far, please don’t forget show your appreciation. If you share your ideas and feedback below, I would only be glad! Thanks for reading.

DIY Redux with RxJS: Part 2

Öner Zafer ・ Jan 17 '19 ・ 5 min read

#redux #rxjs #react #javascript

This article is published at hackernoon.com. This version is slightly adapted to dev.to
DIY Redux with RxJS: Part 2 on Hackernoon