2 min read

Puredux 1.2 – Monorepo Migration and Further Plans

Recently I returned back to the Puredux development and released a 1.2 update.
Puredux 1.2 – Monorepo Migration and Further Plans

Recently I returned back to the Puredux development and released a 1.2 update.

While many libraries start as a single package and then become an umbrella and get split, Puredux does the opposite.

I've migrated all the packages into a mono repo and here is why.

The Story

Initially, Puredux was born a few years ago out of an existing SwiftUI project. It was an implementation of a Redux-like store with SwiftUI bindings.

When I moved on to another UIKit project I missed it terribly. So decided that it would be a nice idea to implement Puredux bindings for UIKit as well.

  • First of all, it's a good idea to have a pluggable foundation that could be shared between different projects/apps. UIKit bindings enhanced the spectrum of projects where it could be used.
  • Another point was to allow a seamless migration from the UIKit codebase to SwiftUI.

The main Puredux module was implemented as an umbrella module that exported other dependencies: (PureduxStore, PureduxSwiftUI, and PureduxUIKit). But each of them could be also used separately if needed.

In many cases, having a package split into small packages is very handy. Works nicely when each module is handled by different people or teams.

It is literally eating an elephant one bite at a time.

In the case of Puredux, it gave a lot of independence to make gradual updates without a need to touch all the dependent projects.

A good idea at the beginning which didn't pay off in the end. It just turned into 3x more maintenance hassles for a single maintainer (me).

Further Plans

Now I've got a few things on the roadmap.

Sugar

I'm still not quite happy about the amount of boilerplate code needed to spin up the UI with Puredux.

Ideally, I want it to be almost as easy as @Observable macro on SwiftUI but both for SwiftUI and UIKit.

In that case, it could be a good alternative for vanilla SwiftUI dataflow.

Long-Running Jobs

Complicated resumable background jobs are still a thing. I want to return to the idea of state-driven side effects in Puredux – a kind of saga pattern and develop it.

Swift Concurrency

Puredux is written in plain old GCD under the hood and it could be a good idea to rewrite it with Swift Concurrency.

Will be a good move, but probably after the updates above.