Bringing Controversial Ideas to React

Hey, everyone. I'm Sanket and I work at Geeky Ants. These days I'm building a full stack framework called GlueStack.

Today I want to talk about bringing controversial ideas to React, talk about controversies and signals. I'll also discuss how I built a plugin architecture and used it in multiple projects. Additionally, I'll share how I use Redux without React Redux and the connect method to achieve higher performance.

Let's start with the plugin architecture. If you're familiar with WordPress, you might have come across its amazing plugin system. I've tried to build something similar in React, which goes beyond just functionality and includes visual boundaries and communication between plugins. I'll provide an example of two plugins, Settings and Profile, and explain how they enhance the UI and add functionalities. The Plugin Manager acts as a store, and I've used MobxStateTree for managing plugins.

The second topic I'll cover is how I used Redux and ultimately realized that I don't need the Connect method. This will be discussed in detail.

The first one is the Settings plugin and the second one is Profile plugin. This is more than just the visual part of it. It does inject these two things in the UI, but also adds a lot of functionalities. For example, the Profile plugin altogether implements a part of authorization as well, and that can be used by other plugins to detect if the user is logged in or not. So yeah, these are the two plugins.

And in the Host app, I can iterate over the plugins from Plugin Manager and go over and render things like Plugin.getSVGLogo, Plugin.getName. So at the highest level, Plugin Manager is like a store. I've used MobuxStateTree, which is in itself a very discussed topic. So yeah, it has got load plugins and plugins are stored in an array.

And if we look at one of the implementations of a plugin, for example, Settings plugin. So it has got a load plugin. For example, Settings plugin, so it implements the functions, getName, getSVGLogo and it just works. So this is not like micro frontends, because here we are staying in context of the host app and we are trying to communicate between different things. And yeah, this is more than just a container storage. This is a change in the mindset of how you build apps, wherein you can enhance things totally separated out from your host app. Great.

The second one is how I used Redux and ultimately realized that I don't need the Connect method. And after removing the Connect method, I had to implement my own re-renders, which I implemented and achieved greater performances. So this is the design tool that I was working on. And this is called BuilderX. And every element that you see on the screen was rendered by React, even the artboards that you see and the smaller elements, like layers and text in there.

So connecting everything to Redux was a bit of an issue, because if you look at the DOM structure or the virtual DOM tree, we have to add Connect method at every location. And this Connect method is executed whenever there is a dispatch, whenever there's a state change, these Connect methods are executed. And the problem here is that I had a lot of elements and all those elements had Connect methods, which was getting called on every mouse move in the design tool. So there were initial optimizations with selectors and those things, but it didn't really work. We removed the Connect methods and we implemented a hook that was the path of the change, and then it just re-rendered that specific thing. We created a hook and whenever there was a change in the entire tree, only listeners of those paths and different components were re-rendering.

Great, and the third one is obviously signals and observability. Signals has been there since the early days of MobX, and that's how Ryan also puts it, React was a signal 10 years later. And there has been a lot of discussions over and over again, from like we called it observability and observer earlier and now we call it signals. So I won't get into the depth of it, but it's being used. If you look at MobX, MobX is being used, even the Blue Sky app that came out, it uses MobX, which is amazing. But as a library maintainer, or if you are building a general purpose library, your philosophies has to stay at the very ground level without adding a lot of complexities. And that's how Dan puts it, that React props and states are raw values. Raw is unsophisticated, and that's the essence. He also says that React will always be a home to those who appreciate them, because raw values, you don't have to create models and wrap your values and do all those things, which is the core principle of React, which is nice that makes perfect sense for a general purpose library like React. But what I want to say is, don't be too burdened by idealism. Know the basics and explore new territories. Something that is generic and widely accepted, it's okay if that does not work for you and you want to do something that is considered as an anti-pattern. Controversial ideas bring new perspectives, keep them coming, and stay kind and humble, learn from each other and build great things. That's me, Sanket.