DEV Community: Max Nowack

SignalDB and Maverick Signals: The Perfect Duo for Reactivity in React

Max Nowack — Wed, 13 Dec 2023 10:43:38 +0000

Introduction to SignalDB and Maverick Signals

SignalDB is a new frontend database that offers fast, flexible data management without strict structures. Its power is fully realized when used with reactive programming in React, specifically with signal libraries like Maverick Signals. These libraries make user interfaces more intuitive and responsive by managing state changes efficiently. Maverick Signals is notable for its detailed approach to state management, improving performance by updating only necessary components. Together, SignalDB and Maverick Signals provide developers with advanced tools for building dynamic, efficient web applications with seamless data flow and real-time user interface reactions. This introduction leads to a more detailed discussion on the benefits of improved reactivity in React applications and how these technologies are changing frontend development.

The Need for Enhanced Reactivity

Reactivity in React applications is not just a feature; it's a necessity for creating engaging and responsive user experiences. Traditional state management and reactivity approaches, while effective to a degree, often face limitations. They can lead to complex patterns, especially in large-scale applications where managing state changes becomes cumbersome. This complexity can impact performance, making the application less responsive and, in turn, affecting user engagement.

Signals, a concept integral to reactive programming, have regained popularity with the emergence of libraries like SolidJS. In essence, signals are variables that, when modified, automatically trigger updates to dependent parts of the application. This facilitates a more efficient and intuitive way of managing state changes. SolidJS, renowned for its fine-grained reactivity, leverages signals to deliver optimal rendering performance. React developers, inspired by this approach, can adopt similar patterns by using hooks and state management libraries. This integration of signals into React enhances the ability to handle dynamic, responsive interfaces with improved performance and cleaner code architecture.

Using signals in React makes apps more efficient and user-friendly. Signals help update only the necessary parts of an app, avoiding unneeded changes. This improves app performance and makes it react faster to user actions. They also make the code clearer and easier to manage, leading to better-written apps. The main goal is to enhance the user experience, making apps feel more responsive and interactive. Signals are key for React developers to create highly reactive and engaging web applications.

As we delve further into Maverick Signals and SignalDB, we'll see how these tools not only address the limitations of traditional approaches but also open up new possibilities for building more dynamic and responsive web applications.

Exploring Maverick Signals

Maverick Signals elevates React development with its lightweight, yet powerful approach to state management. Despite its small size (about 1kB minzipped), it's capable of handling observables effectively in both browser and Node.js environments. Its main appeal lies in its ability to observe various data types and update only when values change, which enhances performance by avoiding unnecessary re-renders. Additionally, Maverick Signals supports batched updates and lazy computations, making it efficient and resource-friendly. The inclusion of features like computed for derived values and effect for reactive effects, coupled with strong typing through TypeScript, makes it a versatile and reliable choice for React developers seeking to improve their application's reactivity and performance.

Understanding SignalDB's Approach to Reactivity

SignalDB brings a novel perspective to managing remote data in React applications, addressing a crucial aspect of frontend development. Its approach to reactivity, particularly in the context of frontend databases, is both innovative and pragmatic. SignalDB stands out for its synchronous interface and in-memory data storage, features that are key to its efficiency and ease of use.
The synchronous interface of SignalDB simplifies the interaction with data. Developers can perform operations on the database without the typical complexities associated with asynchronous loading. This approach not only makes coding more straightforward but also enhances the performance of the application. By storing data in memory, SignalDB ensures rapid access and manipulation of data, a fundamental requirement for real-time applications.

Reactivity in SignalDB is not just about updating the UI in response to data changes; it's about creating a seamless bridge between the database and the application's state. SignalDB achieves this by using reactive queries. These queries automatically update the UI components whenever there's a change in the data they depend on. This setup is incredibly efficient as it eliminates the need for manual intervention to refresh the UI, ensuring that the application remains consistent with the underlying data at all times.

Maverick Signals integrates seamlessly with SignalDB, creating a robust ecosystem for state management in React applications. This integration is facilitated by a dedicated reactivity adapter, designed specifically to bridge Maverick Signals and SignalDB, ensuring smooth data flow and reactivity between the two. While there are several signal libraries available in the React ecosystem, Maverick stands out due to its exceptionally flexible API and superior performance. Its ability to handle diverse data types and efficiently update only when necessary makes it a top choice among developers. This combination of Maverick Signals and SignalDB offers a powerful solution for building dynamic, responsive web applications, leveraging the strengths of both libraries to enhance user experience and application efficiency.

Step-by-Step Integration Guide

Integrating SignalDB and Maverick Signals into a React project is a transformative step towards enhanced reactivity and efficient data management. This guide will walk you through the process, providing practical tips and code snippets to ensure a smooth and successful implementation.

Step 1: Setting Up SignalDB

Begin by installing SignalDB in your project. You can do this by installing the npm package signaldb. Once installed, initialize your first collection. This collection will serve as the primary data structure for storing and managing your data.

import { Collection } from 'signaldb'

const posts = new Collection()

Step 2: Integrating Maverick Signals

Install the @maverick-js/signals npm package in your project. Maverick Signals will be responsible for managing the state and reactivity in your React components.

To integrate Maverick Signals with SignalDB, install the npm package for the reactivity adapter signaldb-plugin-maverickjs. To set up reactivity for your collection, pass the reactivity adapter to the collection options.

import reactivityAdapter from 'signaldb-adapter-maverickjs'
import { Collection } from 'signaldb'

const posts = new Collection({
  reactivity: reactivityAdapter,
})

Step 3: create useAutorun hook
To make it easy for you to integrate Maverick Signals with React, I'm happy to share my current implementation of my React Hook. Feel free, to use it in your project.

import { effect, untrack } from '@maverick-js/signals'
import type { DependencyList } from 'react'
import { useRef, useReducer, useMemo, useEffect } from 'react'

const forceUpdateReducer = (x: number): number => x + 1
const useForceUpdate = () => useReducer(forceUpdateReducer, 0)[1]

export default function useAutorun<T>(
  reactiveFn: () => T,
  deps?: DependencyList,
): T {
  const forceUpdate = useForceUpdate()
  const refs = useRef<{ data?: T, computation?: ReturnType<typeof effect>, isMounted: boolean }>({
    isMounted: true,
  })

  useMemo(() => {
    if (!refs.current.isMounted) return
    if (refs.current.computation) refs.current.computation()
    refs.current.computation = untrack(() => effect(() => {
      refs.current.data = reactiveFn()
      forceUpdate()
    }))
  }, deps || [])

  useEffect(() => {
    refs.current.isMounted = true
    return () => {
      refs.current.isMounted = false
      if (!refs.current.computation) return
      refs.current.computation()
    }
  }, [])
  return refs.current.data as T
}

Step 4: Create React Components

Query your SignalDB collections in your React components. React components will automatically re-render when the data returned by the query changes to ensure your UI is always up-to-date. You can query the data by calling the .find() method on a SignalDB collection. You can also pass arguments for filtering or sorting. Make sure you also take a look at the documentation page for collections. .find() returns a cursor and calling .fetch() on a cursor will return an array of objects to which the cursor is pointing to. Since, we wrap all these in the useAutorun hook, this will be reactive and will rerun if the data changes.

function MyComponent() {
  const posts = useAutorun(() => posts.find().fetch())

  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>
          {post.title}
        </li>
      ))}
    </ul>
  )
}

Step 5: Handling Data Operations
As your collection is still empty, the query in the created component won't return any data. Call the .insert(item) method on your collection to insert some data.

posts.insert({ title: 'Awesome post title' })
posts.insert({ title: 'Another post with a cool title' })
/* ... */

You can also update and remove data from your collection. These operations will automatically trigger a re-render of your React components. Take a look at the documentation page for collections to learn more about the available methods.

Step 5: Fine-Tuning and Optimization

Fine-tune the reactivity by limiting the returned fields of your queries. This ensures that your components subscribe only to the necessary data changes, preventing unnecessary re-renders. Only return the fields you really need in the reactive context.

// will include only the title and the id in the results
posts.find({}, {
  fields: { title: 1 }, 
})

Conclusion

SignalDB and Maverick Signals are powerful tools for building dynamic, responsive web applications. Their integration provides developers with a robust solution for managing state changes and data flow in React applications. This integration is facilitated by a dedicated reactivity adapter, designed specifically to bridge Maverick Signals and SignalDB, ensuring smooth data flow and reactivity between the two. While there are several signal libraries available in the React ecosystem, Maverick Signals stands out due to its exceptionally flexible API and superior performance. Its ability to handle diverse data types and efficiently update only when necessary makes it a top choice among developers. This combination of Maverick Signals and SignalDB offers a powerful solution for building dynamic, responsive web applications, leveraging the strengths of both libraries to enhance user experience and application efficiency.

Make sure that you checkout the SignalDB documentation at https://signaldb.js.org

And also please leave a star on Github: https://github.com/maxnowack/signaldb/

SignalDB: Bringing Meteor-Like Reactivity to the Modern Age

Max Nowack — Wed, 25 Oct 2023 19:03:01 +0000

TL;DR

Check out SignalDB at https://signaldb.js.org.

It was in 2014 when I quit my job working with Microsoft SharePoint to transition to a more modern realm of development tools. I started working at a small agency, building project management software from scratch. A year later, a colleague and I spun off and founded TeamGrid. TeamGrid was built with Meteor.js and, with a few small exceptions, I was the only developer working on it.

Meteor

Working with Meteor felt like magic compared to the hacky jQuery-Injections in SharePoint I had done before. Initially, understanding asynchronous development with node.js was a bit challenging. Also, working in a Full-Stack environment was sometimes a bit confusing.

One aspect I was entirely impressed with was how easy it was to work with data. One reason definitely was that a subset of the relevant data was synced to the client, and on the client, it was possible to use the same API to query and modify the data, thanks to minimongo. Minimongo was a client-side implementation of a database that had a very similar API to MongoDB. You define collections and save documents to them. With selectors, you're able to query data in collections. Data was synchronized in real-time between the client and the server.

Working with Blaze for the UI was also very easy, thanks to the built-in reactivity with Tracker. Tracker is Meteor's reactivity implementation. Although a bit complex to understand when looking at the internals, it offered an outstanding developer experience when using it. Like I said, it felt like magic. Once the UI and the reactive function were defined, they would automatically rerun when the data changed, and the UI updated seamlessly.
Meteor's Optimistic UI also really impressed me. It anticipated the server's response, allowing the UI to update instantly, which in turn improved user experience by minimizing noticeable delay. It blended effortlessly with Meteor, enhancing its real-time data synchronization and reactivity capabilities.

One thing which really blew my mind, was the meteor-reactive-class package. With this package, it became feasible to define a class and convert a collection's documents to it, such that queries would yield instances of this class instead of plain objects. This facilitated the writing of class methods to fetch related objects. For instance, when iterating over posts, each document would be converted to an instance of the Post class. The Post class got a method named author() that retrieves the post's author based on the authorId stored in the post.
Interestingly, executing author() within a reactive context triggers a rerun of the context not only when any post data alters, but also when the author's data (name, email, etc.) changes. This significantly elevated the developer experience by streamlining data handling and ensuring seamless reactivity, which in turn, reduced the amount of boilerplate code and made the codebase more intuitive and maintainable.

New Frameworks

Time goes by, and in 2020, I left TeamGrid as well as the Meteor environment. A lot has evolved in the JavaScript world since then. Modern view frameworks have now become the standard. Nearly everyone writes JSX instead of separating the markup from the UI logic. The tooling for JavaScript apps has become much more mature and stable compared to the earlier days. I transitioned to React on the frontend as it was the most popular framework at the time I switched.

On the server side, I've attempted various solutions to fill the void left by the absence of Meteor. The community has been buzzing about GraphQL and Apollo. The concept of Apollo is appealing, particularly for retrieving data from a server. Especially the synergy of resolvers targeting different data sources is highly potent. However, while the architecture is appealing, the front-end implementation wasn't as intuitive and resembled the early days of fetching data from REST-APIs. There wasn't much tooling available to integrate GraphQL seamlessly into your frontend. Integration is mostly done at the component level, but ideally, you would want your data handling logic centralized, rather than scattered across various components. Although you can create an abstraction layer, bear in mind that you will need to maintain it. In this scenario, you're the sole individual generating innovative ideas on how to simplify and improve the process. It appears that most individuals utilizing Apollo and GraphQL have adopted this approach, which is acceptable.
Besides Apollo/GraphQL, I also explored frameworks like FeathersJS and tools like Firebase, Appwrite, or Supabase. Each solution had a robust backend implementation, but none matched the Developer Experience of Minimongo and Meteor on the frontend side.

About a year ago, I discovered a cool offline-first framework called RxDB. Initially, I thought that on the frontend side, this was exactly what I had been searching for over the past years. After tinkering around and even using it in production for some time, I realized that it wasn't well-suited for my intended use.
RxDB was initially created as an RxJS layer for PouchDB with a server replication interface. Over time, other storage types besides PouchDB were introduced (e.g., IndexedDB, SQLite) and the replication interface became more sophisticated. The replication interface is really cool and exactly what I wanted.
The biggest problem I have with RxDB is that it is so tightly coupled with RxJS. While RxJS is technically very powerful, it offers a dreadful developer experience. It's really hard to understand at first and integrating it into an existing codebase, which isn't using RxJS, is tedious.

When RxDB seemed like the solution but then you met RxJS

Signals

A while ago, I encountered signals in SolidJS for the first time. I don't recall exactly when or where it occurred, but it was a few months after Ryan Carniato's "The Evolution of Signals in JavaScript" was published. When I came across the term "signals" in relation to reactivity, I instantly grasped its connection to the reactivity I had previously worked with in Meteor.
For those unfamiliar with signals, I highly recommend reading his other the article about signals. It thoroughly explains the concept.
Upon delving deeper, my initial understanding was confirmed. Further research revealed that many implementations of signals reactivity already exist within the JavaScript ecosystem.

When the concept of signals in SolidJS clicked with my Meteor days' reactivity experiences.

SignalDB

Upon realizing that signal-based reactivity is gaining traction again, I began exploring how I could integrate it with a frontend database to replicate a developer experience similar to what minimongo offered during the meteor days. After some experimentation, I designed the initial concept for SignalDB. I aimed to employ a synchronous interface to maintain simplicity. Given this, it was essential to store all data in memory. Although this approach may not be ideal in terms of memory usage, it’s optimal in terms of performance. For the rest of the API, I took a lot of inspiration from mongodb and also minimongo. To apply the selectors of a query to the data, I discovered the remarkable library mingo, which replicates many of the mongodb selectors in JavaScript, making them executable on an array of objects.

The first functional version of SignalDB was completed within a few hours and was capable of creating collections, saving documents, and querying them.

Following that, the next step was to introduce reactivity into the system. While exploring various signal implementations, I noticed that most of them had some similarities, which made it possible to write a generic abstraction layer, called a reactivity adapter, with which any signal library can be plugged into SignalDB. I also started implementing reactivity adapters just for fun when I found a new library that implemented signals.
When developing reactivity for queries in SignalDB, I was highly inspired by the minimongo implementation. It is amazing how far ahead of their time the Meteor guys were.

Since all data were initially saved only in memory, I needed to consider persistence. To maintain flexibility in terms of persistence, I followed a similar approach as I did for reactivity by implementing an abstraction layer. This allowed for the integration of any type of persistence interface. Initially, I implemented a local storage adapter for the browser and a file system adapter for Node.js. I encountered a challenge with the replication functionality, as finding a modern and general approach is difficult. Then I realized that I could postpone the replication functionality to a later point and just implement a persistence layer that saves the data in RxDB. This turned out to be a wise decision as it simplified the implementation of SignalDB significantly.

I have recently started using SignalDB in production and gradually phasing out RxDB. I am quite satisfied with the results, and I believe it serves as an excellent alternative to RxDB. Moreover, I am highly pleased with the developer experience, as it is remarkably straightforward to comprehend and integrate into an existing codebase. The one remaining obstacle preventing me from fully transitioning away from RxDB is the replication interface. Currently, I utilize RxDB as the persistent storage for SignalDB, which simplifies the transition process, requiring me only to replace data queries and incorporate signals instead of rxjs. For implementing signals, I rely on maverick-js signals and have developed a React hook that abstracts the interface, making it convenient for future transitions.

Learn more about SignalDB and also check out the documentation at https://signaldb.js.org