DUIX

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). Duix clone the received object, and send a cloned object to the subscribers, in order to keep the immutability of the store.

API doc

With examples. People need examples!

• duix.get('user'): Returns (it's NOT a promise) the user value. This value is safe to be mutated. It's not going to mutate the state.
• duix.set('user', { name: 'Noel' }): This set the user value. It can be ab Object, Array, null, whatever. You can safely mutate the object after setting it. It's not going to mutate the state.
• duix.subscribe('user', (newValue, oldValue) => { /* ... */ }): Subscribe a callback on every change made in user. A change on user can be made only by calling duix.set('user', {\* ... *\}) with a different value that the value is currently on the state. This function also returns a function that if you call it, you unsubcribe to the changes (example below).

Here the unsubscribe example:

1// Subscribe
2const unsubscriber = duix.subscribe('user', (newValue, oldValue) => {
3  /* ... */
4});
5
6// Unsubscribe
7unsubscriber();

See below for some advanced usages.

The Counter Example

1. Buttons component is gonna add or subtract.
2. Viewer component is gonna show the value

1// index.js
2import duix from 'duix';
3
4// Set `null` as default `user` value
5duix.set('githubStars', 0);
6
7class App extends Component {
8  // ...
9}

1// Buttons.js
2import duix from 'duix';
3
4class Buttons extends Component {
5  handleAdd = () => {
6    const currentValue = duix.get('githubStars');
7    duix.set('githubStars', currentValue + 1);
8  };
9
10  handleSubtract = () => {
11    const currentValue = duix.get('githubStars');
12    duix.set('githubStars', currentValue - 1);
13  };
14
15  // ...
16}

1// Viewer.js
2import duix from 'duix';
3
4class Viewer extends Component {
5  unsubscribe = [];
6  state = {
7    githubStars: duix.get('githubStars'), // get initial value
8  };
9
10  componentDidMount() {
11    this.unsubscribe[0] = duix.subscribe('githubStars', this.onStarsChange);
12  }
13
14  componentWillUnmount() {
15    this.unsubscribe[0]();
16  }
17
18  onStarsChange = githubStars => {
19    this.setState({ githubStars });
20  };
21
22  render() {
23    return <div className="Viewer">{this.state.githubStars} stars</div>;
24  }
25}

So, could you understand what happened there? Only 3 things on duix:

1. Someone needs to set the default value
2. Someone is gonna get the initial value, and also subscribe to any change
3. Someone is gonna set the new value every time it have to be changed.

The Login Example

1. The main file in the app defines the initial value for the user object.
2. The Header component is subscribed to the changes of user (because if the user object is not null, it's because the user is logged).
3. The Login component is gonna call a function that is gonna do the API call to check if the credentials are OK.
4. The LogOut component is gonna logout the user. :shrug:

The code:

1// index.js
2import duix from 'duix';
3
4// Set `null` as default `user` value
5duix.set('user', null);
6
7class App extends Component {
8  // ...
9}

1// Login.js
2import duix from 'duix';
3// Let's suppose this `actions` is an object with all the functions necessary to login an user
4import { loginWithCredentials } from 'actions';
5
6class Login extends Component {
7  handleLogin = (email, password) => {
8    // The `Login` component is not gonna change the `user` object. Instead, the `loginWithCredentials` is gonna do it.
9    loginWithCredentials(email, password);
10  };
11
12  // ...
13}

1// Logout.js
2import duix from 'duix';
3
4class Logout extends Component {
5  handleLogout = () => {
6    duix.set('user', null);
7  };
8
9  // ...
10}

1// actions.js
2import duix from 'duix';
3
4export default {
5  loginWithCredentials: (email, password) => {
6    fetch(
7      'http://example.com/api/login'
8      // ...
9    )
10      .then(r => r.json())
11      .then(user => {
12        /**
13         * Whatever the backend send us, let's set it.
14         *
15         * Let's suppose the backend send `null` if the credentials were wrong,
16         * or the proper `user` object if the credentials were OK.
17         */
18        duix.set('user', user);
19      });
20  },
21};

1// Header.js
2import duix from 'duix';
3
4class Header extends Component {
5  unsubscribe = [];
6  state = {
7    user: null,
8  };
9
10  componentDidMount() {
11    // Let's subscribe to the `user` changes
12    this.unsubscribe[0] = duix.subscribe('user', this.onUserChange);
13  }
14
15  componentWillUnmount() {
16    // Let's unsubscribe.
17    this.unsubscribe[0]();
18  }
19
20  onUserChange = user => {
21    this.setState({ user });
22  };
23
24  render() {
25    return <div className="Header">{this.state.user && `Hello ${this.state.user.name}`}</div>;
26  }
27}

So, could you understand what happened there? Only 3 things on duix:

1. Someone needs to set the default value
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

Advanced options/usages

When subscribing to a value, you can choose special behaviors by passing an object as third parameter:

1duix.subscribe(key, callback, {
2  fireImmediately: false
3});

option	default value	comment
fireImmediately	false	Should duix callback immediately with the value currently in memory?

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"

PS: 10 minutes ago it was Christmas. This is my gift for te community.