Panel: State Management (React Finland Mini-Conf #2)

[Music] Okay, how is everyone doing? That gave me absolutely nothing to go on with, like, sterile things to go on, like, thanks, thanks for the presentations, I think it was a good session. And, I mean, what's interesting for me to understand is what do you think is the future of state management? So do we have work left to? Or, like, what do you think we'll be doing like in five years with state? I think, well, no, no, I didn't talk about state management, but one of the things, that's why you're here. Yeah, exactly, yeah. But I've been reflecting on, like, after that, the cerebral project, which was, very much about visualizing what's happening inside the app. I kind of turned a bit to the dark side, with the overmind, focusing very much on the typing experience. And I thought about, like, it should be the visualization that should be driving us.

Not making, specifically, the coding experience better, but like the conceptual experience of building an app and moving into the visual world. So related to David and his sex state library, being declarative. And I've seen some stuff, related to visualization. And one thing is like showing what you have coded in a visual way, but if you can use the visual tool to produce the coding. That's where I see us moving, it's flipping that coin, so we do the visualization first, and then the code is kind of produced for us. Yeah, which is something that I'm slowly, slowly working on right now, and yeah, it is. Well, once you have that declarative structure, then it does make it easy to go from visualizing it to using that visualization to actually create.

Play from 0:00

The machines, so, or, you know, I see machines. I. I personally think like the future of seed management. I've always made a big bet on the fact that there's a lot of people that are a lot smarter than us. Who have researched this for decades. And they probably have a good idea of, you know, what state management should be like, things like actor model with distributed systems. All the way back in 1973, to state machines, which date back to probably the 1930s or so, to statecharts, which is. 1989. I mean, all of these ideas, and even more. There's like petronets, distributed computing, concurrent programming, you know, things like CRDts, just all these concepts eventually, come back. And I think right now, as developers, the easiest way for us to do status just to, you know, take an object and modify it whenever we want. But as Christian knows, as I know, as anyone who's worked on, you know, a like state management at scale.

So you know, even Redox ModBX developers know that's not sustainable. You can't just update state at any time, even if it's immutable like that only solves a very small part of the problem. So, yeah, it's all about being able to understand your app's behavior as a whole, and with that comes a lot of learning curve. And so that's why it's it's a slow adoption. But I've been seeing, you know, people, warming up more to the ideas of like, oh, hey. State machines in statecharts. I could research all this and I could use libraries such as such as over mind or such as X data. Such as any other library where you could implement a state machine, and so the ideas become a lot more important than the actual libraries.

Play from 2:00

So that's what I see in the future. Yeah, it's, it's really interesting. I was super inspired by David's Missionary, or what you call it, eventually imagining, yeah, yeah. And as you talk about it, it's about the ideas, it's not the specific API implementation. And yeah, like in Overmind, for example. Trying to take inspiration from those ideas and see how they can be most practically used in the context of what already exists there. But yeah, it's, it's the. It's about the ideas, that's for sure. Hey guys, I know I'm just a random face here, so I'm, stepping in for Smartly. One of the sponsors I'm. I'm Holly Gibson, a developer. And I was actually curious, like, what have you guys had experience with using? Like the context, provider and consumer? And kind of, you know how you would use it at scale? Because we do that at Smartly.

We have a lot of microservices and so we have things going on in the background and stuff. And by using the provider and the consumer. You know, we can get like state updates, but you know, it's handled by the different components and you know, their calls to APIs and stuff. I could answer. The context API, even in React documentation, is set like for thematization. Not for state management, since it's not very comfortable to work with when we are talking about the state updates or connection of different semantic events and so on. So, providing some theme for design system, maybe some preset values which should be displayed in the app. Yeah, context does all the job here, but if we need to have more complicated to more like for handling more challenging tasks than the just entitization. So then you definitely need to think about the state management tool for handling the state changes, and so on. From my experience, the thing with the context API is that the context API itself is just an object that stores a value and re-renders a component.

So you basically have to implement the state management to yourself, like it's so, if that makes sense, so like they give you an object and they tell you like, this will. If this changes, if you use useState inside of it, obviously, if this changes, this will re-render. So you have to make your own APIs to handle, so like, it greatly depends on how that API is built. But I have never really used it in a huge, like application, I've only used it in small ones. And there's been always a point where, like, it gets even slightly less small. And I end up changing to something. Because I'm not good at API design, and that's mostly the reason. So if you are good, or the person that did that is good at API design, then it's probably going to be fine. And it's going to be great. So I think it depends a lot on, like, who wrote the API for you to use the context API.

I hope that made any sense because I just used the word API. Yeah, yeah, it does make sense. I also was curious if any of you have played around with the experimental, you know, features that are coming in. React like, suspense and things like that.

Play from 4:00

Yeah, yeah, suspense. You can go. Christian Oh yeah, I was just going to. Say, I've tested it and I tried to understand how it works it. It's quite interesting what the React team get gets away with when they present it at conferences. Like, if it was anyone else than the React team presenting these ideas, they would never go through because they do some crazy stuff there. But it's very powerful and extremely interesting how they approach it from the perspective of, like, the science of user experience. And so, it's, it's really, really interesting, and also this new concurrent mode, which is part of that, that story, it's, it's really, really interesting. Yeah. So it's going to be fun to see when all of this comes together. How the React experience is going to be and how we are actually going to build our components and take advantage of that technology. Yeah, I feel like they're trying to flip it on its head, like you were saying earlier, Christian, you know, it's more about the experience of the user than about the programmers experience.

Yeah, yeah, which is good enough. I think I think a good balance between those two things is always a good option to go for. I think it's also really hard to find that balance. There is a question here from the chat, which is, do you think any solutions like GraphQL influence how much state management solutions actually get used and are necessary? So as my answer, we use Overmind with Roughquel on code Sandbox. So no, we still. I mean, there's something related to this question is that, these days I think it's Apollo that they did some kind of connector, directive or something like that. That you can mark that the part of this, is, like its local state, so you have graphical and you can literally tell that, yeah, this, this here is local state. And, it seems to work somehow. I haven't tried it yet, but it seems like I've tried it.

Doesn't look, it doesn't. From what I've used. It was kind of scalable, but at a point you just kind of lost track of it from what I viewed from my experience using it. Like, it's not bad, but I think they're also going to completely change it now, so they're gonna change the way it works. We've also. Used, our old dashboard called Sandbox question knows this was using just Apollo and it? It becomes kind of a mess because of all the things you have to update, so you end up almost always having to. Almost, if it's a big app, having to have state management because of the updates aren't automatic. At least that's my experience. I don't mind touching the dashboard now because it's fine now, but I did mine before, yeah. And it's also like, if you think about Facebook, where GraphQL came from, it's a data driven application, everything is about the data that's coming from the server. Well, for example, code Sandbox is more, it's more of a client application, everything happens in the in the browser.

So, and it's different kinds of state, I would say, at least with those examples, and they come from different perspectives on how to manage it and it. Like, with Apollo using code Sandbox, it gets very difficult to use Apollo to drive code Sandbox. But I totally see it in a different type of application that it will work. Just great. Yeah, I mean, if you're just showing this data, for example, or if you're changing it to go to the server and you don't need to update it automatically. Or as automatically as we do on both. Sandbox. It should be fine. But if you're a very responsive UI, I feel like at a point it gets kind of out of hand. And you end up having to have some state management around these mutations, kind of. Does anyone have any more thoughts? Yeah, I, I don't know. So with Apollo, I just posted a link where, OkCupid, which has a big engineering team.

They decided against using GraphQL for local state management. They bring up a lot of really good points, and they say that they do love Apollo and they love GraphQL. But as far as local state management. Like I like, I talked about earlier today, the problem isn't, the problem with state management isn't. Oh, we have this big, huge object and I want a nice way to update it. That's not the problem. The problem is how that behavior changes over time. And dealing with the logic, especially as the logic comes from so many different sources and. With GraphQL, you're essentially adding a lot of complexity just to get that fancy GraphQL syntax for updating your states, which I don't see much benefit there. Some people might say, Oh, well, Apollo has a caching layer, which is really helpful, but, caching layers are, you know, hard to debug. It's like, why isn't this changing? And you have to dig in and understand why.

So, refresh player is all, yeah, so GraphQL. It is interesting and it's very useful for specific use cases. But as a general state management thing, I, I don't think that anything really warrants the complexity. Yeah, I think that was also the experience I had when I would have less complexity. Using something else and using GraphQL for fetching data and mutating data on the server. And then you get sent to some other state management library. Yeah, that's awesome experience. Does anyone else have any experiences with GraphQL using poor state management? I'm sorry, I just have to say I have to go. I'm being thrown out from the birthday party, my girlfriend is calling and wondering where the hell we are? Yeah, sure, yeah. Thanks for the talk. It was great to have you here. Don't get kicked out of the house because of this. Please, bye, bye, bye. So now that Christian's gone, Oh, oh my God, Alex, please turn off the lights.

I don't know, but that was very creepy. Has the light turned on at the exact same time as Christian left? That was not good. Okay, is there anything anyone else wants to share? I like the idea that everyone was saying. I was like, the next big thing about state management is not going to come from an API. It's probably going to come from the past, like from people adjusting the ideas of year days to, like, new ways of doing things. Yeah, so I've been actually experimenting with something in a client, guys. So the challenge is so that we have hundreds of thousands of rows of data. And then the issue is that the users, they don't want to wait. So we have to implement some kind of caching layer and push a lot of state into indexed TV and do synchronization and this kind of stuff. So my question to you is, do. You see potential in using workers for state management, or pushing logic and state outside of React and into outside of main thread, into something else, something that's living outside.

So you mean, like running certain functions in workers, or like doing all of the state in workers. I mean, like, yeah, it's two questions, I mean, how much? How can you do everything? And I mean, we encountered some chances with this approach. But at the same time, it's it's like it might be something we might want to do in the future as well. So yeah, in fact, there was a library by Google called Comlink, which is essentially Redux. But in a web worker. I'll go ahead and, post a link to that. I think it was created by Das Cerma. Why don't you get these links so fast? I don't know, I just I. I have a, I mean, I have one and a half. I have my little, iPad here I'm using as a, you know, sidecar sort of thing. Yeah, just because I'm, I'm quote unquote. Traveling, well, you know, can't do much traveling in coveted times.

But anyway, with something like doing logic in web workers or really doing logic anywhere. And this is something I ran into when creating the new visualizer for XState is that it shouldn't matter where that logic lives. But you need a, you know, you need a model like the actor model, that really doesn't care. If you have your logic in the worker, or if you have a logic in a separate window or an iframe, or via some websocket, it shouldn't matter. And so, yeah, I think that there is a lot of potential in, you know, web workers, you know, but there is latency with web workers too. That's the main issue we have. That there is a cost in and getting workers to run, and then there is cost related to moving data from worker. To do from app to work around from back. I mean, there are some ways around it. Yeah, but then some weird things might happen, like the workers die, like you don't expect them to die, and they just get they're gone.

So it's, but yeah, that's hard to debug, to be honest. Like from the times I try to debug it, they're also pretty tough to debug it. Just they kind of just die and you don't know what happened a lot of the times, yeah, or they can even stop. And then if you have something that's supposed to like, pick up the job, and then you can actually have duplicate workers. You know, working on stuff that will take it's messy, yeah, but I do see a future for workers. We use it at a lot of stuff in code sandbox because not everything can be done in one thread, mainly if you have a crappy computer. I do see a future, but there are some rough edges, like there are definitely some rough edges. It takes a long time to pick up a lot a lot of the times and it sometimes doesn't even make it faster. Because where you're running doesn't really like.

For example, if you're running a huge search, you don't know what the user typed in. And sometimes putting it, putting that search through a worker. If it has thousands of rows and the user search something very specific is actually not worth it. There's a lot of like, weird things, but I do see a future in it. I think it's going to be kind of like the big, the big kind of thing to use in these kind of. Either that or Ross, to be honest. Because pigment is a lot of rust, so yeah, people just may, like, completely skip white workers and go straight to rust and web assembly. Yeah, so I have a friend that did an experiment years ago and he is working with these junior developers. And and his point was that if you push all of your business logic and stake inside workers, then the developers cannot test it on during these operations.

So it's actually going to bring some discipline as a side effect, because you can only do this certain kind of transformations. So you're kind of forcing developers into sandbox. I mean, for me, it sounds good, but of course, is it practical? It's another, I think in your case, there you have thousands and thousands of rows. Yeah, [Music], that's, that's the thing. I think it's also a very specific case, and in your case, yeah, I think it should be a. Good idea, to be honest, yeah, what do you need to feel about? Just what do people feel about just using webassembly, if any of you actually used webassembly in production, like anything that transpires to webassembly?

Play from 8:00

Not yet, nope, not yet either. Do you see that as the future? Though? That's the sorry. That was the main question. Do you see that as the future? In terms of performance? It is like, I just keep thinking about how fast Figma is, and I can't get over how fast Figma is. Yeah, it's definitely a future. I think, again, learning curve, and, you know, availability with tools and things like that, it's not, but, you know, I, I would gladly welcome anything that improves performance. Honestly. Building an app with a React with reacts that scales at a level where you have so many things interacting with each other. You begin to realize, and this might get me kicked out the conference, but React is slow. By defaults like it, yeah, it does the most sub-optimal thing by default, where it's like, did one tiny thing change? All right, let's let's just re-render as many things as we can, instead of a framework like Spelt or View.

Where it's like, Oh, I know exactly what changed, and I know exactly which components need that thing that changed. Those are the only ones I'm going to re-render. So, and you have to, like, advanced React is just getting over those performance hurdles, you know, by using React's memo, using useCallback, useMemo. Or what I like to do, get a reference to the DOM node and do some manipulations myself and just sort of bypass React. To get that nice, fast performance. So anything like webassembly, you know, much welcome in terms of performance. Oh, sorry, yes, sir, please go ahead. I just wanted to add that, React useMemo is used mostly since the store, which is transformed into props, into Redux case, right? The application itself has only one store. So that means that, if anything in the component has been in the source, sorry, has been changed, the whole tree will be triggered.

So that's why we need to have escape hatches like reselect, just like, and make a used memo. But on the contrary, I guess the application in. Future just need to have a set of reactive values which will be displayed directly into that particular component, and the whole application will be just a set of that particular components. Containing the small atomic, let's say stores, which would be reactive values, just changes, and the UI itself just reacts on the change of that small atom. And this, like, let's say, this path will lead us to the ring. Yeah, that is perfect sense. No, yeah, that makes perfect sense. Everything has to come from the top, so everything re-renders and that is the main issue that we have right now. Okay, we are, unfortunately, out of time. So thank you all for coming, thank you so much, for your talks and for your also for your input in this channel.

And everyone. Have a great day. You are all free to go. Please, you're all free to go. Thank you so much and have a great day everyone. Bye guys, thank you all, thank you bye.

Play from 20:00