Building Web Applications with Signals at Grammarly

Hello, welcome, everyone. My name is Lesh Levzhinsky, and today I'm going to talk about building web applications with signals in Grammarly. I was already introduced, but anyway, I joined Grammarly many years ago. I joined like a web developer, and now I'm working with a couple of Grammarly clients, primarily web. Also, I'm a maintainer for our Grammarly open source library that's about reactive state management. It's Grammarly for Kal, and also I'm a member of FW Days conference. It's the biggest conference about JavaScript in Ukraine.

Well, about my talk. Today, I would like to share our experience at Grammarly, how we are using signals to build our applications, as well as I would like to maybe encourage everyone to think about using similar approaches, if you are not yet.

Well, and before we dig into details, I have a couple of questions. First of all, have you ever used it as signals? Could you raise a hand? Oh, nice. What about FRP, functional reactive programming? Maybe something? Oh, it's going to be easy talk. Nice. But anyway, I'm not going to start with the technical definition. I would like to start with the use case.

Grammarly is a writing assistant. At Grammarly, user may type a text and we will provide a refinement for this text. We'll provide suggestions so you can go ahead, update it, rephrase, and so on. On this slide, there are a couple of typos, and red underlines it's something from Grammarly. Well, also, we have a Grammarly editor. It's like a typical editor where users can go ahead and create documents, as well as to get the full power of Grammarly to refine, do a revision of your text. Well, in this editor, we have a couple of features. First of all, yeah, maybe not first of all, but also move to the primary function like writing text. We would like to show some statistics. Also, we definitely need to send it somewhere to the backend for permanent storage. We would like our users to be able to edit it from different devices, maybe. And for sure, we need to provide a Grammarly check, so we need to send this text to maybe another service. As well as there could be multiple of different features that needs to be updated, recalculated as soon as text changes. Well, it sounds quite a lot for just one key press.

Well, it sounds quite a lot for just one key press. And here signals may be useful. So, in this case, what might be a signal? The signal might be actually text. It's like a value, static values, that we can work with at any time, as well as the fact that it changes over time. And maybe a bit of what it is about.

It's a classical diagram. Nothing special here. On the left side, we have just a value. Okay, we can, what is the value, we can access it at any time synchronously. On the opposite side, we have a sort of observable, just a stream of events, like without the sort of static value, but rather you need to listen for it. And the signal is something in between, first of all. Usually, here it's like a bucket. There's a value that you can access at any time, as well as you can subscribe to it, so it behaves in both ways.

Well, this is another presentation. So, signals in general, it's a concept of reactivity. I'm not going to dig into reactivity, but, yeah, in general, we need to react on some change in state and update in a reactive way our UI, or maybe execute some business logic. Well, here is just an observable part of our signal, like we're applying to the stream of events, we're applying the bonds function in this case, and getting another stream. Well, what about the usage? There are quite a lot of libraries, frameworks that contain this concept of signals. For sure, there are signals in Angular, as well as Angular uses ArigGS.

Probably, the term signal become popular after solid.js introduced it. And for sure, there is a standalone library, ArigGS. It's not only about the signals, but there is a concept called behavior subjects that may contain the value that can be accessed synchronously. There is a standard proposal, for sure. At Grammarly, we have our very own library that was developed quite a long time ago. It provides a code called GrammarlyFocal, and it also basically provides or shares the same concept of signals, and there are a lot more examples.

Well, enough with sort of introduction. Let's look at how we are leveraging the idea of signals in our Grammarly editor. It's like the same screen, nothing fancy. I'm not going to dig into details, but let's look at how it might be, in theory, implemented with React. This is very simple, just for the sake of the demo.

It's quite a simple React component. There is a text area. In real life, definitely not a text area. And here we need to track the state, the change of the text. Here is a simple use state. And for sure, as soon as user types something, we need to send this value to somewhere, to the check-in service, to get some suggestion, to get some improvements. And let's dig into, let's dig a bit into this client sort of server communication and text processing.

So in this case, we have an editor. As soon as user types something, as soon as text is being updated, we need to send it somewhere. So it feels like sort of a stream of events. We need, for sure, to get the suggestions, but almost immediately we need to answer a couple of questions. Well, how frequently do we need to send this text? Do we need to use buffer? What about if it will fail? Do we need to send a full text? There are cases when user works with very long documents, like 10 pages, 100 pages document, it might be quite a huge payload. Well, and we need to remember that we would like to get to show on this underlines live, not to wait for a couple of, even for a couple of seconds or for a minute for a check-in.

And that's only one part. Another part is we have a quite a dynamic UI. And as soon as something is changed with the text, we need to update all of these pieces almost immediately. Still, it sounds like too much for just one React component and maybe for a couple of use cases. That's why let's, for the sake of the demo, let's introduce additional layer. We will call it sort of view model. It might be called in different ways, but all the logic will be, all the like a state for our visual component, as well as the business logic that will pass data to, let's say, API to the backend will be here. And what is view model in our case? It's just a class, a simple class in this way.

But here we have a couple of signals. So here, here we go. Now, the line number two and line number three introduces two kind of signals. In our case, we are using atom term because our library was invented before the signal term become popular. And for sure, all of them contain some default values, like the initial, and will be updated later. But then the next question is how to plug them into the React and how to make React works with these changing values, given that React already provides the hooks. And there is quite a simple way to implement very own hook. I'm not going to show the implementation, but in general, under the hook, it's just a use state and use effect that listen and subscribes to the signal. Well, and the same we need for the suggestions as well, because they're going to be dynamic and we need to React and render them as soon as they will arrive from the server.

Moving on. So what's the point? Okay, we have introduced a couple of signals, so we have plugged them into the React. But what bonuses does this bring us? What possibilities do we have right now? And there are two primary things. The first one is basically the signal. In our case, it may behave like an observable. It kind of allows us to use all the beauty of functional reactive programming and declarative programming, so we can define what we actually need to do. And on the line number eight and nine, for example, we decided that we don't want to send the full text to the server, but rather we need to calculate the diff. But also it doesn't make sense to calculate it for every single key phrase. But rather we maybe need to introduce some logic, maybe to throttle. In this case, it's throttle, but in real life it's much more complex. We are waiting for, let's say, word break and for maybe when the user will finish the sentence, because it doesn't make sense to show suggestion for not completed word, for example.

And another, maybe simple example as well is, okay, the same text value. It's our signal that emits as soon as the user changes the text. We need to recalculate the stats. And we are quite flexible here. It's like the same stream, but we can use a different technique. In this case, we decide for some reason, I don't know, we decided to use the bonds and wait until the user will stop to recalculate the statistics. Maybe there are not a lot of users that will type and check the statistic at the same time. Anyway, it's just an example.

And the second cool thing about our signals is they behave like a classical value. They can be accessed and we can get it synchronously at any time. This is quite a simple example of implementation. Copying to clipboard. We need to basically, user may want to copy selected text, or maybe the full text. And on the line number six, there is a method, basically getters, that allows us to get it immediately. Well, what's the result? We achieved quite a couple of things here. First of all, we have decoupled our state from the view layer. All business logic can be easily plugged to our streams, because it's a stream. We can use a declarative programming to describe what's going on. Also, all of these pieces might be done in quite isolated state, because nothing depends on each other. That's basically it.

When we are talking about the streams, quite a frequent question is, well, but how to test that? And still, with the signals, there are a couple of techniques. The first one is just about, okay, this is a classical unit test. We are trying to test our logic that copies to clipboard. In line number seven, we are creating our view model. In the next line, we are copying it to clipboard, and then we are asserting that, okay, our service that probably should do it, depending on the platform, can, what's called, with the proper value. Nothing special here. It's just a classical unit test. This is because the signal may behave like a classical, like a static value that exists always. But here we go. Another piece of our signal is the fact that it's a value over time.

So, we need to somehow test it as well. Let's look at the example. We have a text. User decided to type hello. Then user decided to change it to hello world. And we would like to ensure that our different functions, different function works properly. So, for the first case A, there is nothing before, so it's going to be hello. For the second case, it's going to be just a world, as a piece that was added. And later on, we will send this maybe to the back end for the sake of checking.

Well, how it may be implemented? There was a teaser on the screen. We are going to use a marble test. Marble test, marbles, we have a stream and marbles on it. This is quite a simple example. Still, we are using to define our behavior, to define the behavior of our signal as it changes over time. We are going to use just the characters, a couple of them, the dashes and the values. Also, we can define it on the line number two and line number three. We are defining the values. This should be, that corresponds to this A and B value. Also, on the line number five, we are defining what's expected.

And the second piece of our code is basically to define the logic. In this case, it's just a demo example. It's not a real one. In real world, it's probably going to be a creation of the view model. That kind of exposes the observable or exposes the signals in this case. And also, on the last piece, we are doing a sort. And the marble test, there is a framework, there's a library that allows you to run it. Definitely, there will be a wrapper that creates sort of the scheduler that needs to be used because it's not, its value changes, that changes over time. So, there will be a bit of boilerplate, but the core of this test is quite readable, for sure, if you know the syntax on how to define the events. Well, basically, testing is done. And let's wrap up what we have.

For Grammarly, in our case, the idea of signals and idea of working with the streams and at the same time with a single value is perfectly fits to our domain because the primary function is working with the text user's writing test in whatever place. We have a browser extension. We have an editor where we need to sort of observe the text and provide a lot of things on the, I don't know, text lengths, on what was changed. Our Grammarly extension, Grammarly editor that I just mentioned, powered by React and signals, in our case, we're just using Atoms, by our own open-sourced library. The bonus of idea of signals, they can be easily plugged into, there are a bunch of libraries that provide this concept. You don't need to have them built into the framework. They can be easily bundled together with React or even React Hooks. So, in this case, you are free to try and you don't need to change your framework or rewrite everything. And maybe like a side effect, but they allows you to kind of straighten your code isolation. So basically the nature of streams that you can plug and unplug at any point of time, but with this power comes that you need to think about the integration testing twice. Because the isolation may lead to some quite unexpected and hard cases when you need to think about testing. Well, and maybe to sum up in general, so yeah signals are framework agnostic. You can use it for quite a lot of cases. Maybe it makes sense to talk about a couple of them. So like in my examples, like you have a single data and the application that needs to react in multiple pieces to this data. It might be in other case, it might be okay, you are doing some, you need to listen for a scroll and show at some point of time some banners. It's also like in single data, but not in multiple places, but the one. And for sure, it's like processing the task, the long tasks that you need to react on and you need to show a couple of states, listen for some events. So it also makes sense to use signals as well as reactivity. And a bit about resources. They're quite a lot of useful. I would suggest to go ahead and read at least about the proposal, the latest in this list. There is a community trying to standardize how signals should look across different frameworks. There are a lot of interesting ideas. Maybe it will become, eventually will become to the core of the JavaScript, but at least they are mentioning that it will not happen this or next year. It's quite a long pass to standardize it. And that's it. Thank you so much. All right. So we're going to start with the one which is right at the top.

How do you handle cleanup or unsubscribing to signals within your view models? This is a great question. First of all, thank you for asking. And this is probably not really about the signals. Not only about the signals, but probably about the architecture itself. So in this case, it's definitely in view models that can be created at some point of time. And unfortunately, in JavaScript, you don't have a kind of clear way to define how to destruct it. But there are two options and there are two ways for doing that.

The first of all, in some cases when we realize that we need to reinstantiate it, maybe or like explicitly dispose, there is a dispose method. And we are kind of plugging this to the React lifecycle. As soon as React components are being rendered for the first time, we are starting a subscription. And on this sort of kind of unmount phase, we are doing that, like unsubscribing. Another option, it also depends on a lot of, like on the architecture. For example, if it's sort of single SPA, single page implication. In this case, if you're moving from one route to another one, you don't... In most of cases, you don't need to think about it unless you are keeping your subscriptions in the global namespace. In this case, garbage collection will handle it.

Awesome. Andreas, thank you for the great question. The next question is anonymous, but it's asking about what's the main difference between two MobX with observables. I think ModX is the signal-based framework, I believe. Yeah, as well. It's maybe, I would say the biggest difference from what we are using, we are using under the hood is a Rigs-JS to power our signals. Like I mentioned, we are using BehaviorSubject and GrammarlyFocal is just a wrapper that allows you to... That provides a couple of nice methods to work with a signal. Basically, it limits the interface of Rigs-JS because with Rigs-JS, you can do almost whatever you want. And the primary interface in Rigs-JS is observable. But observable is something that doesn't contain a value. But yeah, we've wrapped it. And basically ensures that there is always a value, like we're using BehaviorSubject and additional types. Regarding the primary difference, I would say because we're still using Rigs-JS, we have quite a huge library of helpers that allow us to easily work with the streams, to combine them.

Somehow the bonds switch from one to another, pass it to another observables, and so on, so on. So probably this is a primary difference in our case.

We've got another question from an anonymous person. And I know that even just from some of the talks today, and I can even see some familiar faces in the crowd, which I will call signal evangelists, right? There's a lot of these signal-driven systems. And what are some of the main challenges that are affecting them?

Another great question. Thank you for asking. This might be quite a huge talk. It might be a discussion room at the next React Dig Berlin. Yes, I think so. Well, the main challenge, like I mentioned probably at least from my understanding, is like how to test it. Because in case you have a lot of streams and everything is dynamic, in this case, definitely the integration part will be quite huge. You will need to ensure that, I don't know, you are using the proper, you're applying the proper functions like, I don't know, diffing, debouncing, and it works properly. Marble testing is quite helpful here, but still there is a lot of boilerplate and you need to really understand how it works.

Also, the big idea of this proposal that I mentioned to make it to the core is to simplify the debugging of streams. Because it's still, if something is happening, you will have a huge stack trace with some inner functions about who called it, how it was called, how it arrived to this place. So, yeah, maybe these are two challenges. I feel like you could keep on going on that question. So, if you do want to chat to him afterwards, feel free to do so.

And you spoke about marble tests and this person has asked about the marble test syntax. What's the benefit of using it as opposed to using like an array with values over time?

That's a great question. The idea of marble tests and basically the libraries that we are using is that it's not just an array. It provides you a flexibility over the sort of execution time. So, with dashes on the screen, you can define at which point of time the event was fired. It's like it's one dash, it's one tick, three dashes, three ticks. And also, you have a control, still, with quite complex cases, it's become unreadable. But you need to be kind of meaningful here. Another great help from this library is it also controls the life cycle. You can subscribe, unsubscribe, and with all the syntax, you can do that. So, it's not just about array.

So, it's not just about array. With array, it makes sense, but for the simple case, like if you just need to emit at any point of time a couple of events. But with marble tests, and basically powered by library, you can control that, for example, this sort of the signal emitted a couple of values and then stopped, like unsubscribed, the feature was complete. Nice.

The next question is from Alexey. I was like, what? Alexey? But it's slightly different spelling. There are a lot of different variations of the same name, for sure. And this is about combined states. So, what does combined state look like when you need to calculate a signal from other signals? And can OVMs have a dependency from signals? It's hard to explain, probably in words. I would suggest someone who asked that to open Grammarly Focal repository on GitLab. It's called Grammarly slash Focal. And there are a couple of examples on how it may look like. In general, there is a function, we are using the view function in our libraries that allows you to somehow rely on the previous value and calculate it. If it's about combining, you can combine, there is a combine helper that combines a couple of states. And there is also a sort of callback, let's call it callback, that allows you to somehow create a computed value. Nice.

We have a question back to testing from Jacob. He says, have you considered something like property-based testing to expand beyond marble tests and check invariants when the combination space is large? Property-based testing. This is a great thing. Recently, at Grammarly, we had a talk about the property-based testing. I would suggest everyone to search for this talk, or just come here. We have a presenter, Nastya Zelenka is here as well, and talk about property-based testing. My suggestion would be maybe try to limit the overlap between the marble test and property-based testing, because it definitely will become a complex. But by itself, it's a very powerful thing in case you don't know the output. And we are heavily using properly-based testing for our divs. We need to be sure that divs that we are producing are stable enough. As well as not only divs, we are also doing some optimistic kind of dates for these divs on the clients, for the suggestions, and so on. Another topic. That makes sense. And again, remember, you can catch him at the speaker's Q&A over by the entrance after this talk.

And the last one. You only have one minute to answer, so it's got to be quick. How do you feel about the signals proposal? Are you thinking that Grammarly might migrate from the Grammarly-specific code eventually? It may happen. So far, maybe the biggest limitation about this proposal is that it's not providing the solution for working with signal like a stream. So basically, it's more about how to plug the signals idea into the existing frameworks, into UI updates. But the stream part is missing. In our case, it's definitely important, but still there is a way I believe Angular did something similar. So they introduced the signals, but also they added a couple of helpers that allows you to convert from signal to RxJS, for example. So we'll see. Even so, in this proposal, there is a mention that it's going to be quite a long way to make it to JS core and also to adapt it. So maybe in a couple of years, we will consider that. We'll keep an eye on it. We'll keep an eye on it. Thank you so much, Alexey. Can we give him a round of applause?