Bump version

CHANGELOG.md

@@ -0,0 +1,9 @@
+### 1.0.5
+### 1.0.4
+### 1.0.3
+### 1.0.2
+### 1.0.1
+* New Documentation
+
+### 1.0.0
+* The Library

README.md

@@ -1,5 +1,9 @@
 # DUIX
-First of all: Why is it called "DUIX"? The `x` at the end is obvious: Because it's a state manager. If you make your own state manager and you don't call it with an `x` at the end, please, don't do a state manager. On another hand the `dui` means: `DON'T USE IT`. So, you are already warned.
+A Simple library to keep vars on sync between components (or whatever). It's just a matter of callbacks. Use it as you want.
+
+## The `duix` approach
+`duix` just have a state that is just a plain (private) object, and some listeners (publish-subscribers) that are gonna be called every time the subscribed-value change.
+It's just a Publish Subscriber lib + a private object (the state)
 
 # API doc
 With examples. People need examples!
@@ -19,35 +23,6 @@ const goodBye = duix.subscribe('user', (newValue, oldValue) => {
 goodBye();
 ```
 
-
-## Why "don't use it"?
-Because if you saw (if not, you should) all the courses, tweets, videos and blogs from our almighty frontend community, you should already learned that EVERYTHING SHOULD BE DECLARATIVE. And this, my friend, is not declarative at all (and I hope to keep it as it is).
-
-So...
-
-## Why was it created?
-Because some ~most~ of the current State Managers libs add too unnecessary complexity (even in the learning curve, or arch, or high coupling between components).
-
-The idea of `duix` is to reuse some old knowledge to solve only one simple problem: Keep 2 components on sync.
-
-There are 2 things that I keep on mind while working:
-1. **KISS**: Keep it simple, stupid.
-2. **Pareto principle**: The 80% and 20%. The 80% of your bugs, are gonna be always the same 2 or 3 issues that you always see in every project.
-
-The KISS patter is very clear, but I believe the Pareto principle deserves more details:
-
-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", and also 2 times that you solves tons of issues that it absolutelly worth it.
-But, what about those 8 times that you added, let's say, Redux, only to keep 1 var on sync? You only needed a global state var and a callback, but you added Redux (complexity, a lot of complexity my friend).
-
-The idea of `duix` is to cover those 8 times that you added Redux 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.
-
-I'm a React dev, and I used Redux a couple of times. After creating this tool (I was using it during one whole year), I used this tool in 5 projects, and I had to use Redux in only 1.
-
-If your team is not feeling very well with the current State Managers complexity, I'd say that you should try this tool. But, due to it's not in the `declarative hype`, I'd preffer to say: DON'T USE IT!
-
-## The `duix` approach
-`duix` just have a state that is just a plain object, and some listeners (publish-subscribers) that are gonna be called every time the subscribed-value change.
-
 ## The Counter Example
 1. `Buttons` component is gonna add or subtract.
 2. `Viewer` component is gonna show the value
@@ -231,6 +206,25 @@ So, could you understand what happened there? Only 3 things on `duix`:
 2. Someone is gonna `subscribe` to a value change, or unsubscribe when component unmount.
 3. Someone is gonna `set` the new value every time it changes
 
+## Why was it created?
+Because some ~most~ of the current State Managers libs add too unnecessary complexity (even in the learning curve, or arch, or high coupling between components).
+
+The idea of `duix` is to reuse some old knowledge to solve only one simple problem: Keep 2 components on sync.
+
+There are 2 things that I keep on mind while working:
+1. **KISS principle**: Keep it simple, stupid.
+2. **Pareto's principle**: The 80% and 20%. The 80% of your bugs, are gonna be always the same 2 or 3 issues that you always see in every project.
+
+The KISS principle is very clear, but I believe the Pareto principle deserves more details:
+
+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".
+On another hand, you also added it 2 for solving tons of issues that it absolutelly worth it.
+
+But, what about those 8 times that you added, let's say, Redux, only to keep 1 var on sync? You only needed a global state var and a callback, but you added the whole Redux library (complexity, a lot of complexity my friend).
+
+The idea of `duix` is to cover those 8 times that you added Redux only because you needed to keep on sync vars between components. Just that. There is a global `state` object, where you `set`, or `get` values, and you can `subscribe` or `unsubscribe` of their changes. Every time someone `set` a new value, all the subscribers are gonna be called receiving the new and the old value.
+
+If your team is not feeling very well with the current State Managers complexity (you may know a lot of devs with that feeling), I'd say that you should try this tool.
 
 "That's all, folks"
 

package.json

@@ -1,6 +1,6 @@
 {
   "name": "duix",
-  "version": "1.0.4",
+  "version": "1.0.5",
   "author": {
     "name": "Broda Noel",
     "email": "[email protected]"