Plug and Play Design: Building Extendable React Applications

Hi, New York. It's nice to be here. So let's get started. As said, I'm Mateusz Jagodziński. I'm principal developer at Synergy Codes, which is a company that developed the Workflow Builder. Here we have linked to my LinkedIn or my email.

So today's talk is called Plug and Play Design Building Extendable React Applications. In this talk, we'll talk a little bit about feature flags, modularity, and the use case we had in our product and how we approach these cases, these problems. I'll show you a quick demo of this Plug and Play Design, and then I'll go into a little bit more detail on what it is, how does it work under the hood, and what impact this solution has.

So feature flags. Quick question for the audience. Feel free to raise up your hands who has worked on a project which had feature flags. Okay, I see some hands. And how many of you have found sometimes in a situation when you were wondered where is this feature flag from? Is it from three years ago or somewhere? Okay, I see some hands as well. So feature flags. Why do we even use them? They are quite useful things. They allow us to do gradual release of features. They provide a way to do A-B testing. And I'll go into a little bit more detail in a moment. In our case, allow us to prepare different versions of the same product for different clients, essentially.

But feature flags, in general, can have some of their problems. So there is more conditional logic in our code. That's not that great, those if statements and so on. Like with the question I asked, with those old feature flags, they can become technical debt if we do not manage them properly. So maybe we release a new feature but forget to remove the old one, the feature flags remains, and well, it becomes a technical debt bloat within our code. And one thing that will also is relevant for our case is that unused features code is typically still shipped in the bundle. Because if you have a feature flag conditional that serves one component or another one, well, you still need both of these components within the code.

So the question I wanted to ask yourself today is, what if features could be just added or removed just by dropping a folder in and out of your project? So like if we had an alternative to feature flags, but at the build time, where we could say, okay, this folder has one feature, this another, we can pick which one we want to choose. Imagine a car configurator where you drop specific components or features within your code. So what if? Well, typically, if we try to remove a folder from a React application, something probably like on this GIF would happen. And this is because, well, modularity. Yeah, so definitely this approach would require a good modular approach to what we have in the application. Good separation of code.

So, well, this folder that we want to remove actually contains all the things related to that feature. And, well, we would generally like to avoid situations where we need to touch five different places in the code, just to add one thing. So, yeah, modularity. Here I found some definition for it. So, what modularity in general, that's another topic from feature flags, is probably good to have, allows us to separate concerns with our applications and encapsulate those specific functionality. Basically made our code cleaner, make sure that it's easier to work with. So how to achieve it? Well, there are obviously different ways in which we could do it, but let me jump into a specific case we had. Right?

It is designed to be configurable for different use cases for different clients, and a lot of it can be done by configuration. So like on this screen, you have this palette. You can mostly specify this through the JSON config files and so on, right? That was the idea, but not everything can be specified by configuration. There are maybe ways that you need to render one component or provide different behavior and so on.

And with our tool, this was a very common case for us where we wanted to ship essentially the same tool, but like different versions of it for different clients. Right? And feature flags were not really an answer to us because of some of our constraints. But now what I would like to show you is this plug-in plan design that we have quickly in a short demo and show you how it works, and then I'll dive a little bit into the details.

So here I have just a local version of our project running. So yeah, here it is, some diagram with a workflow, right? I'll pick one of the features that we have here. We have something called widgets. This allows us to basically display additional data on those nodes. But yeah, so let's say I'll add some another widget, enable one tool. So as you can see, it appears in several places in the code. We have this widget picker on the right-hand side, at the same time, we're modifying the React components that we have within here. So yeah, the feature, like a typical feature, captures a couple of places within the code.

So let me go back to the code. And yeah, here within the structure, we have our plugins folder where the actual logic for the widget features is present. So we have these components that define and etc. I'll talk a little bit more about this code in a second. But what I wanted to show you is that I can do, well, delete that folder. I do need to re-run the code because the hot module reload won't work with it. But in a second, as I just spin up the application, and yeah, it should work. And it did not work. Okay, let me check. No, it's working. It's just reloading. Oh yeah, the demo syndrome, no stress with all the audience. Okay, yeah. Now it's loaded. It just needed a little bit more time.

It just needed a little bit more time. So as you can see, it's the same diagram, the same thing that I worked on. But well, right now, it just doesn't have those features, the data and everything remain the same. But we have the nodes, and there is no picker here on the right side. And there's no extension here on the node. So going back to the presentation, I'll like to show you how we did it, how we achieved it. I know it's, you know, deleting a folder might not be a big thing, but anyone who worked with a React front end code knows that you cannot simply, you know, remove pieces of codes and, well, just make it typically built and work.

So a couple of things with this, as we call it, plug and play design, the what constraints we had, what we tried to achieve was this couple of things that you can see here. So we needed a way to easy add and remove code. So we can, you know, prepare those different builds. What we really wanted is to have removed features not shipped in the code. So basically have this, well, smaller bundle size, but, you know, smaller source code in general, not shipping what is not needed. At the same time, we wanted to have full type safety within our TypeScript project. So all of this code would live in one monorepo, and we wanted to have all the references not, you know, having those plugins somewhere else.

So how does it work? I think it's, excuse me. So how does it work? There are three steps and pieces of code that will show adapters, plugins, and general build setup around it. So the first thing, adaptance. Here's an example of the code. So we have this, essentially, a wrapper with optional component plugins. So it's like a wrapper that allows us to wrap any React component with additional components. With additional logic. The first piece that comes here allows us to basically modify props of any component. So we have a plugin that defines functions that modifies those props. The next thing that we can do within this adapter is to insert a component before, after, or create a higher order component and a wrapper right around it. Obviously, together with those modified props. So this is a way to modify existing logic within the application. Right? Now, besides an adapter for the components, we do have an adapter for functions. So basically we can take any function within the code, wrap it with this adapter and allow this, you know, to basically change the input values or maybe output values of that function and return it. Yeah.

Yeah. So here's just the continuation of that code. So the next thing we need within the application, within the adapter logic is to expose a function to register this new plugin within the app. And this is like, you know, just a set that has all those plugins that apply separate components. I will show in a second how this is being used. So to sum it up, adapters, with them, we can wrap a component and a function, modify their pros, insert other components. So like in case of those widgets I've shown, there were a couple of, you know, pickers, widgets, et cetera. And we expose a function to allow us to register new plugins.

Now on the plugin itself, on the plugin side, we have, well, we're basically, first thing is to specify the components that can be wrapped. So here we have like this example, properties bar component that gets wrapped with this wrapper. And well, now the plugins can make use of it. And below is some example of a function. So that's the first step. Plugins live in their own folder. And the idea is that all the logic related to that plugin is within that individual format. Be it components, functions, hooks, styles, everything.

Now the first thing, build setup. All right, so where's the connection between the plugins, right? So we have this import of all the plugins within one place. There is this SlintRuler that I'll get back into a second, but basically this is the only place the application actually references those plugins code. Now for this app, we're using Vit to build the config for building the application and how we do it that we actually can remove those plugin files. The idea is we have this replace files plugin that basically allows us to replace with a simple stub, right? So we set it up to the Vit plugin. This is the code, we call it fallback for a missing plugin, that basically replaces the code whenever plugin is missing, right?

This is the code, we call it fallback for a missing plugin, that basically replaces the code whenever plugin is missing, right? And this allows us to, well, remove something without, and the application still works, right? The imports are working. Well, this is the stub, pretty basic.

The last thing within the build setup that we found that is very useful for us is a custom SLint rule that we provide that prevents any piece of the application code from importing from the plugin files. Whenever we try to import something directly from the plugin, it shouldn't allow us because it's an error. This enforces the programmers to keep the plugin code within the plugins folder.

To sum this up, expose the components for us, but the plugins import plugin files. We have this fallback. If we delete something and use SLints to enforce this on the developers. Here, like a diagram, I think that maybe visualizes it better, the older relations. So we have these plugins within their own folder, they're making use of the application and components wrapped in adapters. At the same time, we prevent those imports and have this Vit plugin that allows for replacing missing plugins with the code.

So let's sum this up. Well, there are some pros of this solution. So features built as plugins are self-contained, right? We have this better encapsulation of our logic. With this build setup and SLint, we enforce those rules. So there's less place for an error. You know, typically the React application doesn't, React itself doesn't force much on the developers but itself. So it's sometimes good to constrain yourself. One thing, unneeded code is not in the final bundle. So if we remove something like a plugin, it does not get shipped, does not get built. And at the same time, plugin code can use main code and its types.

But of course, there are some not so great things about the solution. Obviously, there's some implementation overhead on the features. Well, when implementing a single feature, it probably would be much easier to just skip all this plugin stuff, just put in a couple of new components. Don't worry about creating those, using those wrappers, putting all this code in a specific place. The next thing, figuring out what should be the plugin is not an easy thing, right? It's an architectural discussion that you need to figure out, that we had to figure out. Okay, what is the actual core of the application and where the plugins come, right? This separation is not obvious. And, yeah, as we found out with iterating over this solution, right, when we started nesting multiple plugins, it could lead to some problems. So, yeah, is it worth it?

I would say, I mean, is it worth it to go with such solution, to implement such solution? I would say it depends on the use case, right? For our case, this was quite useful as we know, ship those different versions to different clients, but hey, maybe feature flags and in general, good separation of code is fine enough for your case, right? However, I think that this solution might have one useful application this time. So, the how ubiquitous the AI coding tools are right now, the code generation tools, we know how they're notorious, they are for touching different places they shouldn't touch, right? And having this separation, basically forcing a feature within one folder can also make it much easier to work with these tools, right? Because you can clearly see, okay, it's trying to put the code something else, right? So, those constraints might be this enforced modularity can be quite useful for these cases.

So, I would like to know your thoughts. I think the big Q&A in a second and yeah, if you'd like to discuss, you can also visit our booth, Workflow Builder booth, right at the exit of there. When it comes to resources, you can find the community version of the Workflow Builder on our GitHub. That's the first link. And the second one, one of our colleagues prepared like a demo of essentially what I've shown. I know that showing up pieces of code here and there might not be the best way to learn, but if you'd like to check it out, you can just visit the GitHub and see how it works by yourself. And yeah, thank you. Thank you so much for the talk. Thank you. I thought you made it look so achievable, and you outlined the ways, like when we needed the pros and cons. So, yeah, really informative over there. Yeah, thanks. I know that, well, summing this up in 20 minutes, there's actually a lot of code.

Alright. We have a question coming in from Velt. So, how do you decide or manage which plugin ships to which customer? Well, how do we decide? Well, this is actually a part of the, I would say, the sales process. So, you know, business analysis, okay, what the clients need. So, we try to pick a set of features that actually solve their needs, right? It's not an engineering decision per se, right? From an engineering perspective, we make sure that, okay, you can make those modules, you can plug them in, plug them out, right? But okay, what we ship to the client is actually, okay, what the client wants, what the client needs, right? So, that's where the decision lies. And it's different for those cases. For sure. Yeah, really, I think listening to the customer is the answer there. Okay.

And next one is from Ryan. How does this approach scale when you have customers constantly changing product requirements that require feature flagging, smaller incremental changes? Are you duplicating a lot of code for minor tweaks? Well, I don't think we're duplicating much code, I would say, well, for minor tweaks. Okay, one thing, this is a specific use case, right? It's not necessarily a replacement for all feature flags; they still have a use sometimes, but for our type of product, this was possible. I don't think we're duplicating the code. The main challenges that we found out were, okay, if there's a plugin that modifies the same component, okay, maybe there are different versions of it, right? So, this was probably some challenge, but I don't think we had challenges with the application of code. Nice. Okay, so look for what they have in common, try to extract the shared code.

Okay, so look for what they have in common, try to extract the share code. Yeah. Nice. Okay. All right. So, if you have plug and play components and many customers, how do you keep track of all the versions, like one for Netflix, two for Apple, three for Paramount, is that troublesome for you? Well, it can be troublesome, I imagine. Right now the approach we have is that essentially the way we ship work for builder right now is we ship the code, right? And it gets to a customer and can be modified afterwards, right? So, what we have is in our build system is that with certain features, we actually build a separate version and ship it there, right? And it's not impacting the other customers, right? So, it's kind of separated there. But yeah, maybe in the future we'll get into some troubles with managing them. Right now I think there's not that many plugins yet, so it's manageable. Nice. All right.

From Mohan, how do you do automated testing with so many different possible combinations of plugins? Yeah, that's a challenge, right? But I don't think we have a good answer for this to test all the combinations because yeah, there can be places if you'd like to test it all where you have one plugin adding one component, another plugin adding another component beneath it, right? And they can interact with something. So, I don't think we have a good answer for how to do it. But at the same time, we're still developing this solution. So, I think we'll get there eventually. Yeah. So, right now it's just duplication but it will be TBD. Yeah. If you want to test everything, you need to write a lot of tests. Okay.

We have a question from Brandon. Can this be used for shutting off certain features depending on the environment? Yes, I think so, right? Well, it can be embedded within a build process. So, for example, the version that the workable version that we have on GitHub that is community edition that is available to everyone doesn't have all the plugins. But the way we have it, we have another repository where within the build process, we just remove some of those plugins and this gets shipped to this another repository, right? So, I'd imagine this could be done based on environment variables within the build process basically just erasing some files. Yeah. Okay. So, theoretically possible. Okay. And we have a question from Kiran. How do you manage compatibility when the adapter needs to change? Yeah.

Good question. I don't know the answer to that yet. What I can add is that I haven't built all this logic. I've just tweaked here and there. But yeah, definitely we had several iterations of it. For now, we didn't have that many plugins. So, when we changed adapters, we changed all the plugins using those adapters. Those were mostly cosmetic changes. But yeah, this was kind of propagating to those plugins. But I mean, for now, I think with the road that we went so far, we believe we're pretty solid that the adapters shouldn't need to change that much. Yeah. So, it's working so far. But I think all the audience is helping you source your product roadmap, huh? Yeah. For sure.

Okay. So, how can this be achieved without reinventing the wheel? Is there anything we can reuse from the process? Without reinventing the wheel? I am not sure I quite understood the question. Yeah. So, I believe... And the person can come off anonymous, by the way. But I think they believe maybe implementing this is like re... Okay. So, yeah. As I mentioned, there was a link there, presentation where you can see a demo of it. So, we can try it out. Maybe there is something that you can make use of it. Well, one thing that even without going into those entire thing with adapters and so on, I think one thing that is very easy to implement is this SLint plugin that can help without going to this plug and play design can really help manage the imports within the application. Like if you know, okay, when building new feature, it should stay within these folders, right? You can implement just these plugins that will force your dev team to keep this code that is related to itself in one place. I think that's the easiest thing that you can pick up from this, even if you don't want to go into all the complexity there. Yeah. Yeah, for sure.

Okay. We have a question from Melinda. My team doesn't ship separate builds for multiple customers. Would you recommend this setup just for the use case of wanting to make it easy to remove old A-B tests or feature flags, or is that too much overhead? Well, I don't know how your project looks like, right? I think there are many considerations there. It was useful for us, but I cannot really tell you if it will be useful in any project, right? If you have different set of constraints. Yeah, their constraint is they don't have separate builds for multiple customers, just one build. Yeah. I would also think in terms of, because there are other pros like, okay, you don't ship the code. So smaller bundle size and so on. How important is that? That could help you with the decision. Yeah. Once again, it's definitely easier to try it out with something like a new feature, because if you have an existing feature and you would like to separate it to a plugin, this can be actually more work. So I would say for figuring this out, right, what I would do if I was placed in such a decision, I would maybe try with like a single thing, right? Because you don't have to use it anywhere. Maybe you can try it out and see, okay, is it really enough overhead for our use case? Is the developer experience good enough for our team? Everything is slightly different, right? Yeah. So whoever, or Melinda can follow up with you after and share more about how their environments like. Yeah. Yeah. That's good.

Alright. We have time for one more question. Can plugins be code split by the bundler or would they always end up in the main bundle? Could you repeat that? Yeah, for sure. Can plugins be code split by the bundler or will they always end up in the main bundle? Yeah, they could be code split. It's just a matter of how you configure the build, I think. Yeah. Yeah. Okay. So the answer is yes. Very cool. Alright. That is all the questions we're going to address. Go talk to him afterwards. So everyone give it up. Thank you.