Coding is not the end, it’s the means

When I work, my most important patterns/principles are:

KISS

Pareto’s Principle

Component all the things!

Loose coupling

This State Manager library was created mainly keeping in mind the Pareto’s Principle and KISS pattern. So, that that means?

This State Manager doesn’t add complexity to your project, it’s simple, and it allows you to reuse your old knowledge (nice thing if in your team most of devs are Juniors or are coming from backend).

This is good, and bad at the same time. I just wrote the things I think are good, and now I’ll write the things I thing are bad: This library doesn’t follow the current ~hype~ good-practice, like: It’s not declarative, it’s not functional programming (at least in the first version), and more things that I’m sure you gonna find (people loves finding bad things).

There is one more important thing there, and I believe is the most important:

I believe that if you added a State Manager in 10 projects, you may added it 8 times just to solve 1 issue: “Keep a couple of vars on sync between components”. You only needed a global state object and a couple of callback, but you added, let’s say, Redux… Complexity, a lot of complexity my friend. The idea of duix is to cover those 8 times that you added a State Manager only because you needed to keep on sync vars between components. Just that. There is a global state object, that you set values, or get values, and you can subscribe or unsubscribe , and every time someone set a new value, all the subscribers are gonna be called receiving the new and the old value.

^ This, my friend, is the Pareto’s Principle. Pareto says that the 20% of X , generate the 80% of Y . In this case, we can say that if you added a State Manager in your project, the 80% of the time you added it only to solve a few (or only one) problems: Keep vars on sync between components. And the remaining 20% of the time was to solve more than only “keeping vars on sync”.

So, to sum up: You are over-killing. You are adding a library that is created to solve a lot of problems, and you use it to only solve one of them. It remembers me the jQuery time, when some times we added jQuery only to use $ as an DOM element selector. Or adding the whole Moment lib to say “A few moments ago” when something happens in less than 2 seconds (It could be replace with: if ((Date.now() — initialMoment) < 2000) { )

This is simple, and like to keep things simple.

This library is called duix , and it’s basically a library with 3 functions:

duix.set

duix.get

duix.subscribe

If you, reading those 3 items, understand how this library is gonna work, it’s because I achieved my goal.

How DUIX works

You can use duix.set to set a key-value pair, for example:

You can use duix.get to get the pair’s value, for example:

You can use duix.subscribe to subscribe a callback that is gonna be called every time a value change, for example:

Something important to know is that the duix.subscribe function returns the unsubscribe function, for example:

And… that’s all.

Now you can subscribe any component to any var change and do whatever you want when the value change. And you can also set or get values whenever you want (in an imperative way).

How to use it

You know how to use it. Just check the duix library on NPM and Github.

Synchronicity is an ever present reality for those who have eyes to see - Carl Jung

… to see, understand, and remember …