DEV Community: Enzo

Creating a real-time App with React and dop (Part 2)

Enzo — Sun, 01 Mar 2020 12:48:09 +0000

In the first part of this post, we explained the basics of dop. What is a Patch or the Pattern that we used to create an App in React.

But we still have to see how RPCs and the Protocol works.

RPCs

A remote procedure call, is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network. - (Wikipedia)

In other words, is a way to run a function/method remotely. This is how RPCs looks like in dop.

// Server
function multiply(a, b) {
  return a * b
}

// Client
await multiply(3, 3) // 9

Thanks to the async/await syntax, this example is so simple to read. But let's try something mindblowing.

// Server
function square(n, callback) {
  callback(n * n)
}

// Client
square(5, result => {
  console.log(result) // 25
})

In dop RPCs can be created on the fly. Which means we can call a remote function and pass a callback as an argument.

This is very powerful because it let us write code with the feeling of writing it locally.

But how does it work under the hood?

The Protocol

The format of an RPC.

// Request
[<request_id>, <function_id>, [<argument1>, <argument2>, ...]]

// Response
[-<request_id>, <response_state>, <response_value>]

Important to notice that the <request_id> of the response is the same of the request but in negative. So if we take the multiply example we have above, it will looks like this.

// Client -> Server (Request)
[123, "multiply", [3, 3]]

// Server -> Client (Response)
[-123, 0, 9]

The square example is a bit more complex because we are using two RPCs.

// Client -> Server (Request)
[124, "square", [5, {"$f":"callback"}]]
// Server -> Client (Request)
[124, "callback", [25]]
// Server -> Client (Response)
[-124, 0]
// Client -> Server (Response)
[-125, 0]

As you can see the protocol is very lightweight in term of bytes to send. But we can do better because we are receiving unnecessary responses. Dop allows us to call RPCs without responses. So the example above would be like this:

// Client -> Server
[0, "square", [5, {"$f":"callback"}]]
// Server -> Client
[0, "callback", [25]]

We send 0 as <request_id> because we don't expect any response.

React

Enough theory. Remember the example of the three buttons we made with React in the first part of this article?

We can implement the same concept in a Server-Client architecture by adding a few more lines of code. All we have to do is:

Create the same store on the server.
Connect the clients (nodes) via WebSockets.
Subscribe to the store of the server.

For this example, instead of calling setGlobalState which is the function we use to update the state on the client, we call setServerState every time we click on a button. And the store of the server calls the setGlobalState of all clients subscribed with the patch.

Stop talking, show me the code!

1. Creating the store in the server

// server/store.js
const { createStore } = require("dop");

const store = createStore({ red: 0, blue: 0 });

function subscribe(listener) {
  store.subscribe(listener);
  return store.state;
}

function setServerState(patch) {
  store
    .applyPatch(patch)
    .forEach(({ listener }) => listener(patch));
}

function getEndpoints() {
  return {
    subscribe,
    setServerState
  };
}

exports.getEndpoints = getEndpoints;

2. Connecting clients via WebSockets

// server/index.js
const { createNode } = require("dop");
const { getEndpoints } = require("./store");
const wss = new WebSocket.Server({ port: 8080 });

wss.on("connection", ws => {
  const client = createNode();
  // We pass getEndpoints as second argument. 
  // Will be the entrypoint on the client side once we connect them.
  client.open(ws.send.bind(ws), getEndpoints);
  ws.on("message", client.message);
});

3. Subscribing to the server

// client/store.js
import { createNode } from "dop"

let endpoints
const ws = new WebSocket('ws://localhost:8080');
const server = createNode();
ws.onopen = async () => {
  // This is how we get the getEndpoints function from the server
  const getEndPoints = server.open(ws.send.bind(ws));
  endpoints = await getEndPoints();
  // Here we are subscribing and receiving the current state from the server
  const state = await endpoints.subscribe(setGlobalState);
  // Applying the current state of the server to our global store
  setGlobalState(state);
};
ws.onmessage = e => server.message(e.data);

That's it. Now, we only need to use the setServerState function in our React hook.

function setServerState(patch) {
  endpoints.setServerState(patch);
}

export function useGlobalState(...colors) {
  ...
  // return [store.state, setGlobalState];
  return [store.state, setServerState];
}

The codesandbox of this example: https://codesandbox.io/s/react-dop-websockets-95gdx

Maybe you have already noticed, but I'd like to highlight this part.

// Server
function subscribe(listener) {
  store.subscribe(listener);
  return store.state;
}

// Client
const state = await endpoints.subscribe(setGlobalState);
setGlobalState(state);

Here, we are actually passing our setGlobalState function as a listener to subscribe to the server store. And this function will be called every time we mutate the state in the server.

I my opinion this concept is very cool because it makes very easy connecting stores and keeps the state of our App sync.

And this is all the data we are sending through the wire by clicking on the red button just once.

// Client -> Server: Client calls getEntryPoints
[1,0]
// Server -> Client: Server response with the endpoints
[-1,0,{"subscribe":{"$f":1},"setServerState":{"$f":2}}] 

// Client -> Server: Client calls subscribe and pass setGlobalState
[2,1,[{"$f":1}]]
// Server -> Client: Server Response with the current state
[-2,0,{"red":0,"blue":0}]

// Client -> Server: Client calls setServerState passing the patch
[0,2,[{"red":1}]]
// Server -> Client: Server calls setGlobalState passing the patch
[0,1,[{"red":1}]]

Final thoughts

The worst part of creating an open-source project is that in the end, you have to promote it somehow if you want people to use it. And that's the part I hate the most. I like to code, I don't like to sell.

But after three rewrites of the project. I made a solution that I'm very proud of. And, I've spent too many hours on it to leave it without showing it to the world.

I really think that dop is a good solution to handle state in different kinds of architecture. Probably not the best one, but a good one. People will say at the end.

I hope you enjoyed reading. And please, if you have any question or concern don't hesitate to let me know.

Thanks for reading :)

Creating a real-time App with React and dop (Part 1)

Enzo — Mon, 10 Feb 2020 18:46:08 +0000

What is this dop thing? You might be wondering.

Distributed Object Protocol is a thin layer on top of your data network that helps you communicate server and clients (nodes) using RPCs. It is also a pattern that makes easy update, mutate or even sync the state of your App using Patches.

You can find this description a bit poor, especially because it mixes two concepts RPCs and Patches. It also has a pattern and the word protocol. Dop is a complex concept, so let's explain it step by step

Patches

A patch describes mutations to be made in our state using plain objects. Is like using Object.assign or _.merge but in a more advanced way.

A patch looks like this.

const state = { red: 0, blue: 0 }
const patch = { blue: 1 }
const { result } = applyPatch(state, patch) 
result // { red: 0, blue: 1 }

The point of a patch is that makes very easy to send them through the wire and mutate the state of other nodes (server-clients). JSON Merge Patch spec was defined by IETF in 2014 https://tools.ietf.org/html/rfc7386.

The pattern

If you are familiar with React, you have probably heard about Unidirectional Data Flow. In general means that the data have only one way to be transferred to other parts of the application.

In the React world, the view is a component. And patches are actions. So imagine we have a button that counts every time we click on it.

The flow would be:

User clicks on Button
Sends a patch like this { count: count+1 }
Apply the patch to the store/state
Notify components to be re-render

An example using React

We have three buttons. Red, Blue and Magenta with a counter on each one. But the result of Magenta is the sum of clicks that we have on Red and Blue. We can also click on Magenta which will result in an increment of the Red and Blue counter.

Let't start creating the store.

import { createStore } from "dop";

const store = createStore({ red: 0, blue: 0 });

Now, we need a way to mutate our state.

function setGlobalState(patch) {
  store
    .applyPatch(patch)
    .filter(({ mutations }) => mutations.length > 0)
    .forEach(({ listener, patch }) => listener(patch));
}

Here, we are applying the patch. Then we call the listeners that previously were subscribed to the store.

Is the turn for subscriptions.

For our components we are going to use hooks, which makes our subscription system very clean and simple.

export function useGlobalState(...colors) {
  // colors is the array of properties that we want to subscribe to

  // A trick to re-render our component every time we need it
  const [, forceUpdate] = React.useState();
  React.useEffect(() => {
    // This filter is called every time a property mutates the state.
    const filter = mutation => {
      // prop is the property is being mutated. It can only be red or blue.
      const { prop } = mutation;

      // If we return false this mutation will be ignored,
      // therefore the component won't be re-rendered.
      return colors.includes(prop);
    };
    const listener = patch => {
      forceUpdate(patch);
    };

    const unsubscribe = store.subscribe(listener, filter);
    return () => {
      unsubscribe();
    };
  }, [forceUpdate, colors]);

  return [store.state, setGlobalState];
}

Let's use this hook in the components.

import { useGlobalState } from "./store.js";

function Red() {
  const [globalState, setGlobalState] = useGlobalState("red");
  const { red } = globalState;
  return (
    <button
      onClick={() =>
        setGlobalState({
          red: red + 1
        })
      }
    >{red}</button>
  );
}

Magenta looks quite similar.

function Magenta() {
  const [globalState, setGlobalState] = useGlobalState("red", "blue");
  const { red, blue } = globalState
  return (
    <button
      onClick={() =>
        setGlobalState({
          red: red + 1,
          blue: blue + 1
        })
      }
    >{red + blue}</button>
  );
}

Here is the codesandbox of this example to play with https://codesandbox.io/s/react-dop-nhj0j

What is happening here?

When we click on the red button.
We call setGlobalState with our patch.
Then we apply the patch and our state changes.
store.applyPatch returns an array of objects. Each object contains the listener and the mutations previously filtered by the filter passed in the subscription inside the hook.
Then we filter again if mutations are greater than zero.
If so, we call the listener which is actually the forceUpdate function.
Our component renders with the new state.

In my opinion, the best part of this pattern is that makes very easy subscribe granularly to the properties that our component cares about. That's why our components only re-renders when they need to.

So, what's the point of learning another state-management library when I can do the same with Redux, MobX or even React Context. And you are right. If you only need to manage state in the client you are fine with your current solution. The thing is that this pattern can be extended to the server, and here is where dop really shines.

I'm going to stop here. Is already a long post and too much to understand. But if you want to know how to extend this concept to the server and see the real-time demo, please follow me on Twitter. I will publish the second part very soon.

Thanks for reading.

Second part: 👉 https://dev.to/enzo/creating-a-real-time-app-with-react-and-dop-part-2-4lac

Mutable or immutable global state pattern in React with hooks?

Enzo — Thu, 21 Nov 2019 21:51:02 +0000

I want to create a global state pattern for my next app. But I don't know if I should go for the mutable approach or the immutable one. Let me show examples illustrating my two options with pseudo-react.

Immutable

let globalState = { name: 'Enzo' }
function setGlobalName(name) {
    globalState = { ...globalState, name }
    notifySubscriber1(name)
    notifySubscriber2(name)
    // ... and so on
}

function Component() {
    const [state, setState] = useState(getGlobalState())

    function notifySubscriber1(name) {
        setState({ ...state, name })
    }

    return <Text onClick={setGlobalName('John')}>{state.name}</Text>
}

Mutable

const globalState = { name: 'Enzo' }
function setGlobalName(name) {
    globalState.name = name
    notifySubscriber1()
    notifySubscriber2()
    // ... and so on
}

function Component() {
    const state = getGlobalState()
    const [n, forceUpdate] = useState(0)

    function notifySubscriber1() {
        forceUpdate(n + 1)
    }

    return <Text onClick={setGlobalName('John')}>{state.name}</Text>
}

The mutable version could look dirty but let's assume that I'm going to wrap everything into a fancy API. The idea of forceUpdate comes from the MobX pattern that I once studied at that time. The pattern is pretty much the same with the difference that MobX uses Proxies to notify the component to forceUpdate.
https://github.com/mobxjs/mobx-react/issues/55#issuecomment-219536973

The thing is that I don't know what approach to take. Clearly, the mutable is much better in terms of performance because the immutable one makes a copy of the state every time we make a mutation, and this would be a problem if the store/state is a huge object.

But on the other hand, I don't know how problematic it would be the mutable way.

We can compare more or less both patterns with MobX and Redux. I know is a difficult topic because both have pros and cons. But I'm here to hear all the opinions that help me decide.