Forem: vaukalak

React without Pain: Avoid Re-Renders and Simplify Dependencies

vaukalak — Mon, 13 May 2024 11:22:14 +0000

Tracking re-renderings in React can be a painstaking process. Fine-grain reactivity pattern offers a solution that completely removes this problem, allowing React engineers to forget about tracking dependencies and focus on writing code. In this article, we’ll explore how library Mlyn simplifies dependency management and prevents unnecessary re-renders in React applications.

Dependency Management: A Common Challenge

In traditional React applications, managing state and dependencies can often lead to complex and error-prone code. Let’s consider a simple counter example to illustrate this issue.

Traditional React Example

import React, { useState, useCallback } from "react";
const Counter = () => {
  const [count, setCount] = useState(0);
  const onIncrement = useCallback(() => {
    setCount(prevCount => prevCount + 1);
  }, [count]); // Dependency on count
  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={onIncrement}>Increment</button>
    </div>
  );
};

export default Counter;

Issue with Dependencies

In this example, the onIncrement function is wrapped in useCallback with count as a dependency. Every time count changes, onIncrement is re-created.

Simplifying with Mlyn

Mlyn introduces fine-grain reactivity, allowing you to manage state updates without worrying about dependencies. Let’s rewrite the same example using Mlyn.

import React, { useCallback } from "react";
import { rc, useSubject } from "mlyn/react";
const Counter = rc(() => {
  const state = useSubject({ count: 0 });
  const increment = useCallback(() => {
    state.count(state.count() + 1);
  }, []);
  return (
    <div>
      <h1>Count: {state.count()}</h1>
      <button onClick={onIncrement}>Increment</button>
    </div>
  );
});


export default Counter;

Since the reference of state.count never changes, we can read it in useCallback without re-creating a new function.

Benefits of Fine-Grain Reactivity

Stable Callbacks: The onIncrement function in Mlyn does not need state.count as a dependency. This stability prevents unnecessary re-creation of the function. And consumers of onIncrement will not re-render when count changes.
Simplified Code: With Mlyn, you don’t need to track dependencies manually.

Extracting IncrementButton: A Closer Look at Re-Rendering

Let’s extract the increment button into the IncrementButton component to understand how Mlyn’s approach prevents unnecessary re-renders.

Traditional React: Re-Rendering Issue

In the traditional example, IncrementButton re-renders every time count changes because increment is a new function reference each time.

const IncrementButton = React.memo(({ onIncrement }) => {
  console.log("IncrementButton re-rendered");
  return (
    <div>
      <button onClick={onIncrement}>Increment from Child</button>
    </div>
  );
});

const Counter = () => {
  const [count, setCount] = useState(0);
  const onIncrement = useCallback(() => {
    setCount(prevCount => prevCount + 1);
  }, [count]); // Dependency on count
  return (
    <div>
      <h1>Count: {count}</h1>
      <IncrementButton onIncrement={onIncrement} />
    </div>
  );
};

Mlyn: Preventing Unnecessary Re-Renders

With Mlyn, onIncrement remains the same reference, so IncrementButton does not re-render unnecessarily. This is a key advantage of fine-grain reactivity.

Example Revisited

const Counter = rc(() => {
  const state = useSubject({ count: 0 });
  const onIncrement = useCallback(() => {
    state.count(state.count() + 1); // No dependencies needed
  }, []);
  return (
    <div>
      <h1>Count: {state.count()}</h1>
      <IncrementButton onIncrement={onIncrement} />
    </div>
  );
});

Summary

Mlyn’s fine-grain reactivity simplifies state management by:

Eliminating the Need for Dependency Tracking: You can write cleaner, more maintainable code without worrying about manually updating dependencies.
Preventing Unnecessary Re-Renders: Components only re-render when their actual state or props change, improving performance and efficiency.
By adopting Mlyn, React engineers can focus on writing feature-rich code without the hassle of managing complex state dependencies. Try integrating Mlyn into your next project and experience the ease of fine-grain reactivity!

Interested in mlyn? check it out on github

React 18 Suspense minimal example

vaukalak — Sat, 22 Jan 2022 19:07:22 +0000

In the current version of React (17.0.2 at the day of this article creation) Suspense is a component, that allows developers to lazy-load application parts. It accepts fallback property, with content to display, while the child component is lazy-loading.

const SomePage = React.lazy(() => import("./modules/somepage"));

const App () => (
  <React.Suspense fallback={"Loading..."}>
    <SomePage />
  </React.Suspense>
);

However from React 18 it will be possible to use Suspense for data fetching. This means, that fallback will be displayed until component will fetch all the data needed. Or in general all events that component expect will occur. Let say we want to just display placeholder for 2 seconds:

const Main = () => {
  useTimeout(2000);
  return <div>Component loaded</div>;
};

const App = () => (
  <Suspense fallback={"Loading..."}>
    <Main />
  </Suspense>
);

export default App;

As you could guess, Loading... will be displayed for 2 seconds and Component loaded afterwards.
However when I first saw the code above, I didn't understand HOW did that happen.. What is that magic mechanism in the useTimeout hook? In short it has to:

Stop component code execution.
Let Suspense know that the component isn't yet ready
Notify Suspence know when it should re-attempt with rendering component.

To stop code execution you need use throw statement. In order to make Suspense know it's expected, the value thrown need to be a Promise. Suspense will catch this promise and subscribe to it, to re-attempt rendering.
Please note: the code bellow is just for a demo purpose:

let fullfilled = false;
let promise = null;

const useTimeout = (ms: number) => {
  // check if timeout already occurred.
  if (!fullfilled) {
    // if promise doesn't exist create and throw it.
    throw promise ||= new Promise((res) => {
      setTimeout(() => {
        // on next attempt consider timeout completed.
        fullfilled = true;
        // resolve promise (will ask react to re-render).
        res();
      }, ms);
    });
  }
};

(Confused about ||= ? Check this doc)

It turns out that suspense uses quite simple mechanisms, but there's a hard part. You might ask why fullfilled and promise couldn't be stored in a ref, so the hook would be reusable:

const fullfilled = useRef(false);

It turns out, that while component is not loaded, hooks can't be really used. Component will be unmounted / mounted on every render attempt before the render will complete without throwing promises. Hence to figure out, if this component has actually started data loading process, we should rely on a globally available cache. (In our simplified case it's just fullfilled variable). Of course in a real-world example such simple approach wouldn't work (this hook works only one time).

This is why it's advised to use good libraries that supports suspense (like swr).

Full code of the example above.

👋

Two-way binding will make your React code better.

vaukalak — Fri, 14 Jan 2022 15:14:42 +0000

Two-way binding allows to create synchronisation between 2 entities, for example application data and view. React out of the box, provides an api to get one-way binding. When we want to mutate the state, we need explicitly call updating callback:

const UserName = ({ name, onChange }) => {
  return <input onChange={onChange} value={name} />;
};

const App = () => {
  const [user, setUser] = useState({ name: "" });
  return <UserName
    name={name}
    onChange={(e) => setUser({ name: e.target.value})}
  />;
};

This is done to provide owner to child update experience. So when the root state of the app gets updated, changes will propagate to children. This makes application data flow clear and predictable, however increases the amount of code to write.
In order to make two-way binding match with react update philosophy, I've built the library called mlyn. The main paradigm is that every piece of the state is readable and writable. However when you write to it, the change will bubble to the root of the state, and the root state will be updated:

// trailing $ suggests that the value is observable
const UserName = ({ name$ }) => {
  return <Mlyn.Input bindValue={name$} />;
};

const App = () => {
  const user$ = useSubject({ name: "" });
  return <UserName name$={user$.name} />;
};

That's it, the engine will update the state in the same way as on the plain react example above.

However two-way binding is not limited to the communication with UI. You can easily bind your value to the local storage. Let say you have a hook that accepts a portion of mlyn state, and target local storage key:

const useSyncronize = (subject$, key) => {
  useEffect(() => {
    // if state exists write that to the state.
    if (localStorage[key]) { 
      subject$(JSON.parse(localStorage[key]));
    }
  }, []);
  useMlynEffect(() => {
    // whenever state is updated, update localStorage
    localStorage[key] = JSON.stringify(subject$());
  });
};

Now you can easily bind user name to it:

useSyncronize(user$.name, "userName");

Note that you don't need to create/pass any callbacks to update the value, it just works.
Another use-case is when you want to make changes of the state undoable / re-doable. Once again, just pass this state to the appropriate history management hook.

const history = useHistory(state$.name);

The history object will contain the api to jump to any step of the state. However, it's a bit customized 2-way binding. Whenever state gets updated, the value is pushed to the history:

When a history entry is selected, this entry is written back to the state:

And note again that we don't write custom boilerplate for the state update, just connecting the dots.

Check this code sandbox with history management for a TodoMVC app:

For more examples on 2-way binding and mlyn visit react-mlyn repo.

Easy history management for React with Mlyn

vaukalak — Thu, 13 Jan 2022 20:22:19 +0000

In the introduction to mlyn post, I've shown an example of how easy is to create a TodoMVC app within it. In this post, I'd like to demonstrate how 2-way binding can help to setup history management. This is how the app would look like:

You can see full code on this codesandbox
The thing we want to track is todos field of the store:

const state$ = useSubject({
  todos: [],
  newTitle: ""
});

Since all parts of a mlyn store are 2-way bindable, we can easily pass it to the tracking function:

const [history] = createHistory(state$.todos);

createHistory is an utility from mlyn-history package. Within the returned history object we can jump to any step of the tracked state. Lets write a component for that:

const History = seal(({ history }) => {
  // let store past and future to local storage.
  useSyncronize(history.past$, "past");
  useSyncronize(history.future$, "future");
  return (
    <>
      <Mlyn.Input
        type="range"
        step="1"
        onChange={(e) => {
          // on input change, jump to a point in history
          history.jumpTo(e.target.value);
        }}
        // subscribe component to history position.
        value$={() => history.past$().length}
        // the range of mutations, indexing starts from 1
        // cause 0 is the initial state which can't be rolled back
        min={1}
        max$={() => history.entries$().length}
        // history with one entry (actual state)
        // is empty, hence can't be modified
        disabled$={() => history.entries$().length === 1}
      />
      <button onClick={history.commit}>COMMIT</button>
    </>
  );
});

And that's it, now every step of the todos state can be easily inspected. I hope the above has convinced you in the power of 2-way binding.

Currency converter app in React and Mlyn

vaukalak — Tue, 14 Dec 2021 14:11:21 +0000

👋 Let build a currency converter app:

The application should allow to edit the amount in the input fields and change currency. The amount in another input should change in the base of the conversion rate.
For a working example see this codesandbox (It also contains an advanced example).

First of all, we need to define our data domain. We need to take a currency as a reference point, let use USD:

// USD to currency price
const usdRates = {
  USD: 1,
  BYN: 2.5,
  CAD: 1.260046,
  CHF: 0.933058,
  EUR: 0.806942,
  GBP: 0.719154
};

// list of currency names
const availableCurrencies = Object.keys(usdRates);

Now we can setup the root state:

export default function App() {
  const state$ = useSubject({
    // entered amount expressed in USD
    baseAmount: 0,
    // list of currently compared currencies
    currencies: ["USD", "EUR"]
  });

  return (/* jsx here */);
}

Yeah, that's all boilerplate we need. And finally some JSX:

<div className="App">
  <Currency
    amount$={state$.baseAmount}
    currency$={state$.currencies[0]}
  />
  <Currency
    amount$={state$.baseAmount}
    currency$={state$.currencies[1]}
  />
</div>

Operation state$.baseAmount created a read/write lens to baseAmount property. Calling state$.baseAmount() will return its current value and state$.baseAmount(1) will change the baseAmount value. The update will bubble to the root state, cause encapsulated object is immutable. Also, you can subscribe to this value. This enables 2-way binding.
Same thing for state$.currencies[0], it will read/write the first element of the currency array.
Now let write an incomplete version of the Currency component.

const Currency = seal(({ amount$, currency$ }) => {
  return (
    <div>
      <Mlyn.select bindValue={currency$}>
        {availableCurrencies.map((c) => (
          <option key={c}>{c}</option>
        ))}
      </Mlyn.select>
      {/* text input code here */}
    </div>
  );
});

Mlyn.select is a wrapper over the plain select element, it has a property bindValue which accepts a read/write value, and creates a 2-way binding to it. Internally Mlyn.select will observe currency$ value, and re-render when it's changed. When a selector option will be selected currency$ (and hence the root state) will be updated.
To write the input we can't just bind amount$ to it, cause we need to display the derived value of the currency:

// will not give the expected result,
// cause USD amount will be displayed
<Mlyn.input bindValue={amount$} />

Ok. This will be the hardest part.
One of good things of 2-way binding, is that you can wrap binded value within a function, that will perform read/write derivation logic. So let create a function that will convert amount in a currency to/from USD amount:

// function that will curry references to `baseAmount$`
// and `currency$` subjects
const convertCurrencyAmount = (baseAmount$, currency$) =>
  // returns function to use as 2-way bindable value
  (...args) => {
    // if function has been invoked with params
    // checks if it is a write operation
    if (args.length > 0) {
      const newAmount = parseFloat(args[0]);
      // writes new value to the subject 
      baseAmount$(newAmount / ratesToUSD[currency$()]);
    } else {
      // it is a a read operation, return converted value
      // note that this code will create subscription and
      // routing will rerun whenever baseAmount$ or currency$
      // values will changed 
      return baseAmount$() * ratesToUSD[currency$()];
    }
  };

The above function is a simplified version, in reality we should do some input validation:

const convertCurrencyAmount = (baseAmount$, currency$) =>
  (...args) => {
    if (args.length > 0) {
      // if user erases all text make value 0.
      const value = args[0] === "" ? 0 : parseFloat(args[0]);
      // skip non-numeric updates
      if (!isNaN(value)) {
        baseAmount$(value / usdRates[currency$()]);
      }
    } else {
      const newAmount = baseAmount$() * usdRates[currency$()];
      // avoid very long numbers like 0.999999999
      return Math.round(newAmount * 100) / 100;
    }
  };

Now you can use pass the converted currency lens to the amount input:

<Mlyn.input
  bindValue={convertCurrencyAmount(baseAmount$, currency$)}
/>

For more examples and docs about mlyn, I invite you to check the github repo page.

Proxy / Observable as property pattern in React

vaukalak — Sat, 04 Dec 2021 15:04:59 +0000

Suppose you have the following app:

In this particular state you have Box1 element selected, and want to change it backgroundColor style by the color picker in the Details component. Let describe some possible implementations in React:

(Scroll down if want to bypass prop-drilling / context / redux approaches and go directly to proxy / observable approach).

Prop-drilling

In this case we would lift the state that contains all elements to the top of the app (Application component). We would pass to the Details component the selected element, and a callback (updateComponent) to modify it. Then on color selection this callback updateComponent would be invoked, which would update state of Application component. Afterwards Application, Canvas and Box1 components would be re-rendered and finally background color will be updated.

Pros

Simple implementation to develop and support.

Cons

This would cause invalidation of all hooks (useCallback / useEffect / useMemo) to check if they need to update. Also re-rendering Canvas would cause invalidation of properties of all boxes (need to check if incoming properties changed for this specific box). In real-world application you'll get even more dependencies to update (for sure Canvas will not be the only child of Application). Also this is positive scenario, which suppose that all memoization in your app is properly managed.

This will certainly work fine if you update color only when releasing color picker. But what if you want to update the color of Box1 on every mouse move to get a handy preview experience? I think in some cases it will still work, but at certain point you might reach performance wall, that will force you to optimise your application. And in this case simple implementation might become not so simple.

Also you will not only need to pass down the state, but also callbacks to update it.

Context / Redux

I grouped those two approaches, cause they solve this problem in a similar way. The state is stored in a context which than is injected into components via hooks (react-redux uses context under the hood as well). So when the state stored in context is updated, all dependent components are notified.

Pros

Since you don't pass the pass the property / update callbacks through the intermediary components, amount of passed properties is reduced. The problem of re-rendering intermediate components is solved as well.

Context cons

All components subscribed to context via useContext re-renders when it's updated. This problem might be solved by fragmenting different parts of the state to different contexts. But I'd prefer application data to be separated in base of logical distinction, rather than in base of thinking how it will re-render less.

Redux concerns

In redux, all components that are subscribed via useSelector hook are notified, but than a selector is run to extract selected state, afterwards it figures out, if that component actually need to be re-rendered. This mostly solves the re-rendering issue, but still, more components are subscribed to the store, more selector logic need to happen.

As another concern I need to state, that unfortunately I saw many situations, when some complex (or parametrised) selectors where written in a wrong way, from the memoization standpoint. And this would make component re-render on every store update (even of data completely unrelated to the re-rendered component). Those memoization issues are quite hard to debug.

One more issue, is that within useSelector hook you need to reference full application state. Which means if your module consumes user data, it has to be aware that this user data is stored under user key in the root state. Not good for modules decomposition. In general context (and especially with redux) makes it harder create reusable components, and bootstrap unit tests / storybook.

Proxy / Observable as property

However React doesn't force component properties to be plain values. You can easily pass as property an observable value to a child and then internally subscribe to it. Let write some pseudo-code to explain it:

const Application = () => {
  const elements = createObserable([]);
  return <Canvas elements={elements} />
}

Then inside a consumer component you can subscribe to it value.

const Box = ({ element }) => {
  const [backgroundColor, setBackgroundColor] = useState(0);
  useEffect(() => {
    const unsubscribe = element.backgroundColor
      .subscribe(value => {
        setBackgroundColor(value);
      });
    return () => {
      unsubscribe();
    };
  }, []);
  return <div style={{ backgroundColor }} />;
}

Looks like a lot of boilerplate is needed. Also within this approach all Box component function need re-execute. Suppose for example situation when component has more than one child. But what if we create an ObserverDiv component, that will detect all observable properties automatically, then the code can be reduced to:

const Box = ({ element }) => {
  const { backgroundColor } = element;
  return <ObserverDiv style={{ backgroundColor }} />;
};

This is very similar to prop-drilling, but on change of backgroundColor for one element only ObserverDiv will be re-rendered and the rest of the app will remain untouched. Very similar to the context / redux approach, but without related concenrns.

The next question is how we can we make every element property (like element.backgroundColor) observable. Here's where proxy enters in the game. Within a javascript proxy object you can override get accessors, and return another proxy, which will create a lens to backgroundColor, now you can directly subscribe to it.

To solve everything described above I've a created library called mlyn. Within it you can create proxies, that can be lensed, subscribed and updated. And yeah, internally those proxies contains immutable objects, so none of react best practices are violated. How this app would look with mlyn:

import Mlyn, { seal, useSubject, For } from "react-mlyn".

const Application = seal(() => {
  const elements$ = useSubject([{
    id: "some-random-id",
    backgroundColor: "black",
  }]);
  return <Canvas elements$={elements$} />
});

const Canvas = seal(({ elements$ }) => {
  return (
    <For each={elements$} getKey={({ id }) => id}>
      {(element$) => <Box element$={element$} />}
    </For>
  );
});

const Box = seal(({ element$ }) => {
  const { backgroundColor } = element$;
  return <Mlyn.div styles$={{ backgroundColor }} />;
});

And now when you change backgroundColor of an element, only the Mlyn.div component will be re-rendered.

To see mlyn in action, please checkout my previous article about it.

Have a nice day :)

Introducing mlyn - new state management for React

vaukalak — Mon, 22 Nov 2021 22:18:24 +0000

Impressed by fine-grained reactivity concept from solid-js, I've tried to build a library that brings it to react. Some react issues I was going to solve where:

Provide possibility to re-render just those elements, which related data has changed.
Enable easy 2-way binding, however maintaining unidirectional data flow.
Remove necessity to overflow the code by explicitly mentioning all dependencies, as we currently do with useEffect, useCallback and useMemo.
Issues with encapsulation and modularisation when using redux or context as state management (I ❤️ redux btw).

Now I'm going to present you main concepts of the library within a TodoMVC app example. You can find full source code here. Note that example fits in less than 60 lines of code.

First of all let define our component:

export const App = seal(() => {
  // ...
});

seal is an import from react-mlyn, it's a wrapper of React.memo, which compare function always returns true. Which means, component should never re-render by incoming properties change (those are not supposed to ever change). All children re-renders will be triggered by mlyn reactivity system.
Now let define the state:

const state$ = useSubject({
  todos: [],
  newTitle: ""
});

useSubject is a react-hook, that will convert initial state to a subject. A subject in mlyn is a proxy object, which can we used in 4 different ways:

you can read from it:

// will return actual state
state$();

you can write to it:

// will set `newTitle` to `hello`
state$({
  ...state$(),
  newTitle: "hello",
});

you can subscribe to it:

useMlynEffect(() => {
  // will log the `state$` value every time it's updated
  console.log(state$());
});

By reading state$ inside of useMlynEffect hook we automatically set it as a dependency, which will re-run the hook every time state$ has been updated.

you can lens it:

state$.newTitle("hello");
state$.newTitle(); // hello
state$(); // { newTitle: "hello", todos: [] }

Every lens behave like a subject, but when updated bubbles an immutable update to the root subject. Also within lens you can subscribe to updates of just a portions of the state.

Now let go back to our TodoMVC app, let create a synchroniser of todos to the local storage:

// this hook accepts a subject and a string key for localstorage
const useSyncronize = (subject$, key) => {
  // if localStorage already contains info for that key,
  // let write it to `subject$` as initial state
  if (localStorage[key]) {
    const preloadedState = JSON.parse(localStorage[key]);
    subject$(preloadedState);
  }
  // create a subscription to `subject$` and write
  // write it to localStorage when updated
  useMlynEffect(() => {
    localStorage[key] = JSON.stringify(subject$()); 
  });
};

Invocation of this hook in the component code:

// create a lens to `state$.todos` and
// bind it to localStorage `todos` key.
useSyncronize(state$.todos, "todos");

Let create methods for adding / deleting todos:

const addItem = () => {
  state$({
    todos: [
      // remember to use `()` when reading from a subject.
      ...state$.todos(),
      {
        title: state$.newTitle(),
        createdAt: new Date().toISOString(),
        done: false
      }
    ],
    newTitle: ""
  });
};

This looks very similar to normal react update, but you don't need to wrap it with useCallback since with mlyn component is not going to be re-rendered.

const removeItem = (i) => {
  state$.todos([
    ...state$.todos().slice(0, i),
    ...state$.todos().slice(i + 1)
  ]);
};

Note that since here you need to update just todos you can directly write to state$.todos without taking care of rest of the state. This is very handy, when passing a lens as a property to a child.
And finally jsx:

return (
  <>
    <h3>Simple Todos Example</h3>
    <Mlyn.input
      type="text"
      placeholder="enter todo and click +"
      bindValue={state$.newTitle}
    />
    <button onClick={addItem}>+</button>
    <For
      each={state$.todos}
      getKey={({ createdAt }) => createdAt}
    >
      {(todo$, index$) => (
        <div>
          <Mlyn.input type="checkbox" bindChecked={todo$.done} />
          <Mlyn.input bindValue={todo$.title} />
          <button onClick={() => removeItem(index$())}>x</button>
        </div>
      )}
    </For>
  </>
);

Notice that for inputs we use special tag Mlyn.input it has some properties which enables subscriptions to mlyn reactivity. One of those is bindValue. When you pass state$.newTitle to it, it will both update the input when the newTitle is updated, and write to newTitle when input is changed. In short, this is 2-way binding.

<Mlyn.input
  type="text"
  placeholder="enter todo and click +"
  bindValue={state$.newTitle}
/>

Now let analyse how the For component, that is used to display collections works:

<For
  // pass subject which holds array to display
  each={state$.todos}
  // key extractor, it's used not only by react reconciliation,
  // but also by `For` component logic.
  getKey={({ createdAt }) => createdAt}
>
  {(todo$, index$) => (
    <div>
      <Mlyn.input type="checkbox" bindChecked={todo$.done} />
      <Mlyn.input bindValue={todo$.title} />
      <button onClick={() => removeItem(index$())}>x</button>
    </div>
  )}
</For>

The first parameter $todo of function child prop is still a 2-way lens. Which means, by updating it, you'll update todos array and in general entire state. So writing:

todo$.title("new value");

Is like writing something similar to bellow in plain react:

setState({
  ...state,
  todos: state.todos.map(item => {
    if (getKey(item) === getKey(todo)) {
      return { ...item, title: "new value" };
    }
    return item;
  }),
});

You probably noticed that one input is a checkbox toggle for boolean value:

<Mlyn.input type="checkbox" bindChecked={todo$.done} />

bindChecked is similar to bindValue but it creates 2-way binding for a boolean subject value to input checked field.