Join me in a thought-provoking discussion on Bringing Controversial Ideas to React.js, where we will explore some of the most debated topics in the React ecosystem. This talk delves into the concepts of mutability and observability in React and compares them to frameworks like Solid.js and Svelte. We will also discuss the debate on granular updates versus Reconciler and the potential of a plugin system to extend React applications, and the impact it could have on the React community. Attendees will gain a deeper understanding of React's challenges and controversies compared to other frameworks and how the community is addressing them.
Bringing Controversial Ideas to React
AI Generated Video Summary
This Talk discusses bringing controversial ideas to React, building a plugin architecture, and using Redux without the Connect method. It explores the implementation of plugins that inject functionality into the UI and the use of MobxStateTree. The Talk also highlights the challenges of connecting everything to Redux and the benefits of implementing custom re-renders for better performance. It emphasizes the importance of exploring new territories and embracing controversial ideas for new perspectives.
1. Building Plugin Architecture and Redux Usage
I'll talk about bringing controversial ideas to React, building a plugin architecture, and using Redux without the Connect method.
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.
2. Plugin Architecture and MobxStateTree
The Settings and Profile plugins go beyond just the visual part. They inject functionality into the UI, such as authorization. The Plugin Manager acts as a store and allows iteration over plugins. The implementation of a plugin like Settings involves functions like getName and getSVGLogo. This approach enables the enhancement of apps separate from the host app.
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.
3. Redux, Connect Method, and Signals
I used Redux but realized I don't need the Connect method. After removing it, I implemented my own re-renders for better performance. Connecting everything to Redux was challenging due to the large number of elements. We replaced Connect methods with a hook that only re-rendered specific components. Signals and observability have been discussed in the context of MobX and React's core principles. Don't be burdened by idealism, explore new territories and embrace controversial ideas for new perspectives.
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.