Todd Werth:

Welcome back to React Native Radio Podcast brought to you by World Chaos. Are you bored of waking up and your home still exists? Try World Chaos Today, episode 335  state Management Revisited. Oh, and we're still hiring.

Jamon Holmgren:

Did you all watch or listen to the WWDC announcement?

Robin Heinze:

Yes.

Jamon Holmgren:

All of it or

Robin Heinze:

I was really paying attention for the first maybe hour and then I started tuning out in the second part.

Jamon Holmgren:

Yeah,

Robin Heinze:

But I don't know if we've talked about this before, but Infinite Red always almost always watches it.

Jamon Holmgren:

Yeah, we usually have a, we

Robin Heinze:

All

Jamon Holmgren:

Zoom, we jump in Zoom and watch party.

Robin Heinze:

We make fun of the presentations and

Mazen Chami:

The cinematics, is it Craig Cinematics running around and stuff?

Jamon Holmgren:

Yeah, at one point that was just so unusual and cool because a lot of times back in the day, tech presentations were so dry and they would really kind of make them an event. Right? Applewood?

Robin Heinze:

Oh yeah. That was like Steve Jobs thing when the iPhone event and the,

Mazen Chami:

Didn't Microsoft have a dance party or something on the stage? They really tried. They really tried.

Robin Heinze:

They're like, Hey, look at us over here.

Mazen Chami:

Yeah, dancing with their fingers kind of

Robin Heinze:

Thing. But everyone remembers the classic Steve Jobs events where it's like black stage, black backdrop. He had the black turtleneck, so it was just highlighted the tech, so he would hold up the iPhone and show everybody

Jamon Holmgren:

And there was the one more thing.

Robin Heinze:

There was always the one more thing.

Jamon Holmgren:

Yeah. Yeah. We got to where it was. There was no one more thing this year. Come on, we want, there's

Robin Heinze:

Always the one more thing.

Jamon Holmgren:

We want open a present, we want a gift of something new. But yeah, I don't know. I just can't get really very hyped about it these days.

Robin Heinze:

They're very corporate feeling now. It doesn't have the same magic that it used to.

Jamon Holmgren:

No, I did actually went to a WDC one time.

Robin Heinze:

20 20 16.

Jamon Holmgren:

Yeah,

Robin Heinze:

2016.

Jamon Holmgren:

Yeah. Nothing really big happened that year.

Robin Heinze:

Anybody can go, right, if you're registered as a developer.

Jamon Holmgren:

Yes. Is that the idea? But it was lottery, at least at that time it was a lottery and I got a ticket and I actually stayed at Todd's house in the Bay Area and this was not too long after we had merged. I think it was probably June of 2016, so yeah, I don't remember exactly the timing, but something like that. It was a fun experience, but man, it was like 6,000 people and I didn't know hardly anybody. I did end up seeing, I remember seeing, there's one guy that worked that still I think to this day works at Apple that I knew he was like a Rails Dev back in the day. Actually does Rails at Apple, so I knew him and I got a chance to chat with him a bit. He was actually,

Robin Heinze:

What's Apple doing? Rails.

Jamon Holmgren:

Oh, it was like documentation or something. It was like a bunch of docs and then actually someone we've had on the podcast, Orta was actually there as well and I hung out with him just briefly. I knew him a little bit. Wow. That was many years

Mazen Chami:

Ago.

Jamon Holmgren:

Yeah,

Mazen Chami:

And back then there were no leaks. You had an idea like, oh, something new in this, the phone sphere is coming out. You could guess it was a new iPhone or whatever, but now I feel like I read the, I dunno if you all do this, but Mac

Mazen Chami:

Rumors,

Mazen Chami:

I guess that's why it's called Mac Rumors. They pretty much nailed the presentation to a T and I read it the day before and then as I was watching it the whole time, I was like, yep, I heard about that off

Jamon Holmgren:

Next. I actually saw a lot of criticism, especially of their new kind of glass

Robin Heinze:

Transparent thing. Yeah, with glass. Yeah, it's getting made fun of all

Jamon Holmgren:

Over Google's announcements had way more positivity around them. There was a lot of wonder around Google

Robin Heinze:

Hating on Apple is like people's pastime now.

Jamon Holmgren:

That is true. That is true. Yeah. In some ways they've kind of earned it.

Robin Heinze:

If you're from Apple and you're listening to this, we appreciate that you

Jamon Holmgren:

Yeah, we have to do

Robin Heinze:

Provide us with a platform that lets us have a job. This

Jamon Holmgren:

Is true. This is true.

Robin Heinze:

So the liquid glass thing, it's from a technological standpoint, super cool that they figured out how to do this from design and technology. Incredibly impressive, but it's one of those just because you can doesn't mean it seems like they didn't really think through all the practical

Mazen Chami:

Implications of it. Exactly. I think I said it in the watch party. I was actually working on an accessibility ticket for my client while I was watching it and then as I'm doing the accessibility testing, I look at my simulator and I look at the screen and I'm like, there's no way that's accessible. Someone who has vision, whatever it is, it just doesn't make sense.

Robin Heinze:

There's no contrast.

Mazen Chami:

I think even someone who can see clearly 2020 vision

Robin Heinze:

Even. Yeah,

Mazen Chami:

You would still miss some of that text on the screen. It just seemed very hidden in the background.

Robin Heinze:

Very busy and

Jamon Holmgren:

Some of the states aren't obvious whether a button's pushed or not and things like that. Yeah.

Robin Heinze:

Obviously it's going to be in beta for a while, so with user feedback they may adjust, be able to tweak it and

Mazen Chami:

It'll turn into murky liquid

Jamon Holmgren:

Glass so that you can see

Robin Heinze:

It. Liquid Mud

Jamon Holmgren:

Jordan Walk tweeted that he thought that maybe Apple was just trying to introduce features that are hard to do on the web.

Robin Heinze:

Yeah, it's a bit of a cynical take, but it wouldn't shock me. Our team was discussing though what Liquid glass means from a React native perspective and speculating about how that'll be possible with React native and it's hard to say for now, but Evan Bacon already did it with Expo. It sounds like at least he tweeted about it, so it'll either probably either be baked into React Native Core or baked into Expo or a third party library or something. It'll be really interesting to hear how it works.

Mazen Chami:

I believe someone from Call Stack already tested the bottom tabs in Liquid Glass and it automatically works. I think it's

Robin Heinze:

Just automatically works.

Mazen Chami:

Bottom tabs. Yeah. All they said was they updated Xcode to the latest beta ran their React native project and it worked

Robin Heinze:

Well. It must be the UI views underneath

Jamon Holmgren:

And that's

Robin Heinze:

Are automatically doing it.

Jamon Holmgren:

That's the benefit of React native. I mean Flutters going to have to emulate this if they want

Robin Heinze:

It. Yeah, that's what I saw that a lot on Twitter that was like, oh, oh, sorry, Twitter flutters probably really not happy because they recreate all of the UI components components in their own system and now they're going to have to recreate

Mazen Chami:

This

Robin Heinze:

Glass effect or just not use it. Whereas React Native is like, no, you're literally rendering UI views.

Jamon Holmgren:

Yeah, you get it for free.

Robin Heinze:

Yeah, you do get it for free

Jamon Holmgren:

More or less. Yeah. Alright, well I suppose we do have a real topic topic to talk about here.

Robin Heinze:

That should have been our, we should have changed our topic for

Jamon Holmgren:

Maybe we should have. Yeah, that's okay. Anyway, I'm Jamon, she's Robin, he's Mazen and we are React Native Radio and React Native Radio is brought to you by Infinite Red, which is a premier React native consultancy located fully remote in the us. We're a team of 30 senior plus React native developers and support staff. We've been doing this for just about 10 years. We'll let you know when it has been 10 years, but we're getting there.

Robin Heinze:

I feel like we've been saying just almost 10 years for maybe a little too long, but it's close. It's legitimately closed now.

Jamon Holmgren:

As soon as it flips I'll be like working on 20. Right. It's been almost

Mazen Chami:

10 years for almost 10 years.

Jamon Holmgren:

Yeah, there you go. I like it. We are in the year though that we did the merger. Merger and all that, so yeah, if you're looking for React native expertise, hit us up Infinite Red slash Radio and don't forget to mention that you did hear about us through the React Native Radio podcast. Alright. If you stuck with us through all of that WW DC talk and everything, we do have a topic today and that is state management revisited. So we did a state management episode, I think it was, was it like our second episode or something?

Robin Heinze:

It was our second episode after we took the podcast over. It was episode 1 75 in October of 2020. I forgot that we started the podcast during COVID, but it's been almost five years.

Mazen Chami:

It was before. My time doesn't count.

Robin Heinze:

No, it doesn't. I don't think

Mazen Chami:

It does.

Jamon Holmgren:

We didn't get your take on it, so

Robin Heinze:

That's why we're doing it. That was before Mazen joined us,

Jamon Holmgren:

But things have changed a lot and let's just talk really quickly about the background here of state management in the early days, and I'm thinking, I think of everything sort of in the timeline of both React Native and Infinite Red, which is similar obviously both started in 2015, state management was in Flux BA router. It was both in Flux and it was Flux Pattern. Yes, there was, well Router Flux was more of a,

Robin Heinze:

That was a navigation

Jamon Holmgren:

Navigation library. Library,

Robin Heinze:

But it was based on the flex pattern but for navigation

Jamon Holmgren:

And then Redux came onto the scene and we adopted it. We brought it in especially into Ignite in all of our projects and stuff.

Robin Heinze:

We even created our own little wrapper.

Jamon Holmgren:

Yeah, Redux,

Robin Heinze:

Not wrapper. It was like a helper. It was called Redux Sauce.

Jamon Holmgren:

Yeah, it was sort of to

Robin Heinze:

Help mitigate some of the boilerplate

Jamon Holmgren:

Sort of directionally toward RTKA little bit. There was some cool stuff there, but a couple years later we were looking for something else. All the boilerplate was just getting really annoying to deal with and so we settled on Mobic State Tree, which kind of was our go-to for many, many years.

Robin Heinze:

If you've listened to the podcast even a little bit, you probably know that we were MBE State Tree fans for a really long time. It was in our Ignite stack. We used it pretty vocally and talked about how much we loved it and preferred it to Redux, but with that is

Jamon Holmgren:

We

Robin Heinze:

Seem to be the only ones.

Jamon Holmgren:

Yeah, I mean there are other people using it, but it's a smaller community for sure. I was the primary maintainer for a while. Tyler Williams who works for us has been maintaining it. We have a few other people on the core team that are doing a good job and this is definitely not against MST because even when I asked people not that long ago what they would prefer to start with, a lot of people still said MST at Infinite Red, so it's still a pretty popular thing within Infinite Red, but we're a consultancy. We're not a product company that can sit here and make sort of super opinionated choices that are out of step with the broader community. I think that's just kind of the reality and especially with React compiler coming on the scene and suspense and things like that, we started looking at alternatives.

Robin Heinze:

Do you want to explain just for people who don't know why React Suspense coming down the line was going to impact our decision to keep using MobX Day Tree?

Jamon Holmgren:

So suspense was more somewhat theoretical problems. There's a possibility that it could cause issues. I think the bigger issue was actually more rack compiler because Rack compiler does static analysis of your code, your rack code and Transp compiles it into you're not going to have to do use Memo anymore. You're not going to have to do use callback. A lot of those things will go away, but it has to be able to read the code in a way that it really understands how it's working and MobX State Tree has at least from the component level, a little bit of magic happening where it's watching what properties are accessed and then rendering based on that React, MobX React is

Mazen Chami:

And so observe function that you're talking about that you would

Jamon Holmgren:

Wrap. Yeah, observer. Yeah, around it. Exactly. And then Tyler came up with the use observer selector basically, which gets around it, but then it starts making it feel a lot like the other ones and so it's sort of like, well, you're kind of losing the magic and so why not take a look around and see what's going to go on. So spoiler alert, there is not a clear winner anymore. We are actually becoming less opinionated at Infinite Red. So let's talk about the alternatives first and then we're going to talk about how we think about state management internally and then lastly, we're going to kind of hopefully teach you from our perspective or at least discuss from our perspective how to make these decisions because the biggest question here is how do you choose a state management library when you're starting a project? Let's talk about alternatives.

Robin Heinze:

Well, the obvious one that I think everyone's probably going to know is Redux, which now includes Redux as well as RTK, which is Redux Toolkit, and then tangentially RTK Query, which is based off of Tant Stack Query, which is more integrated with data fetching, but the primary state management library is Redux with RTK

Mazen Chami:

And even before you go to third party package. Again, we're only talking about alternatives here. We're not going to put opinions within there just yet, but you could just go simple, use state, use context, use reducer, create your own hand rolled one

Jamon Holmgren:

Just from what React provides. And I think that's a lot of times what the React team at Meta likes to kind of advocate for is start there.

The survey, the React native survey which came out for 2024 actually shows that the Bear, both of those options redux and just sort of the Bear React state tools as a dropping in popularity a little bit. So there are some other alternatives kind of coming up. Tans Stack Query for sure has been rising in popularity. Tanner is coming out with a state management system of his own that's kind of attached to that or compatible with that, so that's going to be interesting to watch. And then Zoo Stand has been really interesting. That's the one that has actually been gaining the most usage. I think it's

Mazen Chami:

A steady incline.

Jamon Holmgren:

Yeah, exactly. Very interesting. It's sort of how Redux was like let's take the flux pattern and do it simpler. Zan is sort of like, let's take the redux pattern and do it even simpler. It's like continuing to refine on that

Mazen Chami:

Pattern. You then have a new one on the scene. Legend state from Jay Meistrich where you've had him on the podcast, talk about legend list, so that one's brand new. Another one on here is X State survey said it wasn't very popular and I think we'll talk about it a little bit more later.

Robin Heinze:

There's one called Jo T Tie, which is moderately popular, not really going up or down according to the survey, but I know there's some people that use it. And then of course MobX and MobX Day Tree, which we've used a lot and then there's some more unconventional ones that we see. We used occasionally Firebase and Fire Store, which is kind of a serverless solution, but it also provides a client side state storage. There's watermelon DB realm, Apollo, which is a GraphQL client, all t Dan Js, these are

Mazen Chami:

Some of these I'd never heard of. It's very random ones. I don't know, I feel like one-off, they're used one-off.

Robin Heinze:

When you see a project using it, you recognize the name, but it seems unusual.

Jamon Holmgren:

And then Recoil, which came out of Facebook that again is dropping in popularity even though it never really got that popular. I think that the meta team, I think they use it internally or they have used it internally, but they never really pushed it all that hard and that was an interesting one and then one that I added to our list Convex. So convex is a very interesting one. I know that Theo really likes this library. He's building his T three chat on it and I'm looking into it because I think there's some interesting things there. So anyway, if we missed one that you're using that you're thinking Let, wow, you really should have mentioned this, please let us know. But that was sort of pulling from the survey results and internal conversations as well. Speaking of which, let's talk about how we currently are using state management. I think that is also important here. What are we seeing out in the wild? So we pulled a sample of eight projects that we've been working on either currently or recently. We're not going to say what apps they are, we are not allowed to, but these are actual results from various people. I'll just run through it really quick. First project uses U State, everybody uses U State, so you're going to use

Robin Heinze:

U State, right? But for some things,

Jamon Holmgren:

Yeah, react query some context. And this is actually, I think Mazda, this is your project, right?

Mazen Chami:

Correct. Yeah. This is the one I'm on and I think I can give a little bit of a story around why we chose that stack. I can say the context is mainly coming from third party libraries or if we created our own context for things like push notifications I think is the latest one, which funny enough, I bring that up. I actually just stripped that out today.

Mazen Chami:

So

Mazen Chami:

There goes one context, but yes, I guess you could say no one really uses U State in there top app level, right? Because then it renders the entire app. That's not performance, that's not cool. So we use it in a simple, you need a bullion to show a modal for example.

Jamon Holmgren:

Yeah,

Mazen Chami:

Simplicity.

Robin Heinze:

I think there's tons of really great use cases for use context and definitely for use stay state. I wouldn't be surprised if almost every screen has something that they're using U State for

Mazen Chami:

Exactly. But

Robin Heinze:

There's a difference between using it for a specific purpose and using it for your entire application state.

Mazen Chami:

It's funny you say using it for a specific purpose because that then leads me to when we started the project, the client goes, what are we going to use for our state management tool? Always my first response, no matter who I'm talking to when it comes to architecture decisions, do you need a state management tool? I dunno if I've said this on the podcast before, but I usually tend to lean towards the, we don't need a state management tool until we really are put in a corner and then we need to use

Robin Heinze:

It, right? Your first question should be, do we need a state management library? Not which state management library.

Mazen Chami:

Correct. And that's when I was like, well we need data fetching, right? An app. Our app needs data fetching of some sort, so let's lean to React query because it seems like everyone is using React Query these days and I love how easy it is to use a documentation is great, let's use React Query. Then as things evolved, we did find out that okay, yes, we do need a state that is held for a specific life cycle of the app for the user, so we do need to implement something. And at that point I kind of looked out and I'll get into other of my likes or dislikes in state management tools later, but then we landed on Zest and I showed it and I was like, look, it's easy to use and here are the other reasons why. And that's kind of how we landed on that stack. So do you need a state management tool? Should be the first question in my

Jamon Holmgren:

Opinion. Yeah, and the other part of that is I've seen people push that too far also where they're rebuilding redux in using use reducer and at that point it's like okay, just go find a state management. Our second project is using MobX State Tree and U State and that's kind of interesting because MobX State Tree, often when we're using it, you don't have a long list of other things because it comes with so much built in, it's just ready to go. So you just use MobX State Tree and so that's kind of cool and one of the reasons we like it, the third project also MSD and U State, that's it. Just those two things. Project four, pretty big project, a whole bunch of people working on it. This is using Redux Toolkit, RTK and RTK Query. It uses some use stay in some context and I think that one, the decision to go with that was because they were already using Redux on their web side of things and so they were already familiar with it or at least the web developers were Project five. I think it came to us with the state management already set and that was Redux and so that's using Redux and U State Project Six is actually using Mob X and Apollo client again, they came to us. Interesting combination. Yeah, the state management already set. It is a little bit of an awkward fit, but this is a very large app and so there's historical reasons why it is the way it is.

Robin Heinze:

If you're not familiar with MobX at all, the difference between MobX and MobX State Tree MobX provides the observability, which is the fundamental feature of it that your views update when the state changes by being observers. And then the state tree portion just adds a lot of type safety and structure structure, whereas MobX is very unstructured, but it provides the observability component.

Jamon Holmgren:

Exactly.

Robin Heinze:

You can use MobX by itself. It just doesn't put any rigor on what your

Jamon Holmgren:

Exactly

Robin Heinze:

State looks like.

Jamon Holmgren:

Seventh Project actually uses X State and U State, so that one's been kind of interesting to work on. We haven't done too many state projects, so that's good. That's a good experience for us. Project eight, the last one is actually as in watermelon db. And so that one has also been interesting for us to go through that and that one came to us again with that already, that decision already made.

Mazen Chami:

Usually I feel like apps lean to something like Watermelon DB when it's offline heavy. That's usually been the context.

Robin Heinze:

It provides support for syncing versions of the database if you need to reconcile.

Mazen Chami:

But then of course I say that out loud now and someone will be like, well did you know React Query can be used as a state management tool and it can do all this

Robin Heinze:

Just by the number of options that we just talked about. It's clear that there's no silver bullet for this and that everything is so dependent on your project's needs and your personal preferences as a developer, your organization's needs. So there's not a wrong answer. You're not going to be picking something that completely goes against the grain because there's always going to be someone out there using what you pick. The landscape is pretty varied.

Mazen Chami:

That is true. That's very true Robin, because looking at this list real quick, four of the apps are pretty much the same esque apps and each one is using a different stack

Robin Heinze:

And probably could have used any one of these apps, probably could have used one of the other state management libraries successfully. It is very hard to make a super, super wrong choice. You may get into it and not like the feel of something, but it's never going to be impossible to do what you need to do

Mazen Chami:

Unless you choose Redux right then. Yeah, Redex

Jamon Holmgren:

Is probably the same then you're just wrong

Mazen Chami:

Choice to be honest. I wouldn't be surprised if the project that you mentioned that uses Redux was initialized a longer, much earlier than the other ones that we'd recently discussed. Right? That's a trend that I've seen. If any app is using Redux specifically, it was initialized much earlier in the life of React native than it would've been if it was initialized say two years ago.

Jamon Holmgren:

So what makes us like or dislike a particular state management solution? Let's just kind of go through a few things for me. I don't like, and this is a little bit counter, it sounds counter to what Zen was saying. It is actually not, and I'll explain why I don't like you state scattered everywhere because that means your state is actually not in a try to gather up that state and persist it, try to restore that state at some point. It's actually really hard. It's

Robin Heinze:

Really hard to do. I'm a firm believer that you state should be as local as possible.

Jamon Holmgren:

Local as possible, and also more something that doesn't

Robin Heinze:

Need to be persist, persisted. It's temporal. Something that you can throw away when the screen UNM mounts.

Mazen Chami:

Exactly. Can I give a perfect example of this? Sure. We had a screen that showed a toast. We used use state to show that toast and it went away. Ticket number two comes in, let's add another toast to this other screen. We add the toast using use state. Cool. Now we have the same code duplicated twice on two different screens. What we did elevated that toast higher up, put the state in Zeus

Mazen Chami:

And

Mazen Chami:

Then basically you call your zein store to create a toast and that create toast function. Set a time out for clearing the toast, did everything that needed to be handled in clearing that toast and then that toast component then interacted with zein to know when the user tapped it to dismiss it and all that kind of stuff. And you would pass in, let's say the text, what text to show on there sort of thing. So if you notice you're doing the same use state to do the same function more than once, that's probably a good point to elevate it even higher.

Jamon Holmgren:

And that kind of brings in a point that a lot of times this isn't just state management but it's also eventing and its communication between different levels. State management sort of becomes that orchestration layer on top of it, which is very interesting. Another thing I don't like is when there's a lack of documentation or the documentation is wrong, that's a fairly common one. Lack of third party integration. So like, hey, we have real world needs. What if we need to connect in with GraphQL? What if we need to connect to a fire base backend? What if we need to have, again, persistence or

Some sort of offline sync or maybe other third party integrations. So having lots of third party integrations is important. I don't like boilerplate code, I just want it to get out of my way. I want it to be very concise. Actually probably more than a lot of developers will do a lot to try to get that stuff hidden in the background. Back in the day when I did iOS development, I actually built a library that abstracted away a lot of the boilerplate for navigation in iOS because a lot of times you'd write five lines of code just to present a modal or something like that or to create a navigation stack. And I turned that into a much smaller one or two lines of code. Very, very tiny. And I think also what we already know for me, what I already know does factor in to my initial reaction to a state management library. And I don't think that's a unique thing. What about you, Robin? What makes you enjoy or not a particular state management system?

Robin Heinze:

So I really enjoy state management libraries that have a really strong connection to your mental model or your data model, which is honestly one of the reasons I really liked MST is because it was very object oriented and it really fit my model of, okay, I have a collection of users, I have a collection of whatever. Because my background was originally Rails and I absolutely loved database design and figuring out what your records were going to be and what tables you needed of those records and how things tied together. And so I really loved things that felt object oriented like that. And with Redux and stuff, I always had much more trouble piecing together the flow of data and how things fit together and it just was an extra level of just friction. So that's always what I preferred. But there's obviously other considerations like developer experience, how much boilerplate there is, how performant things are is a huge consideration. You want things to be efficient and fast at retrieving data and getting it back and forth to the UI whenever you render.

Mazen Chami:

Yeah, and I'll say I think for me we've all kind of touched on the same points pretty much making sure it's not boilerplate e. That's something I very strongly opinionated on. And I think the one other thing that I'll say, and I think I kind of mentioned it at the beginning, if you had one tool to rule them all, I would love that. Which includes a data caching layer, like React query. So if React Query had a state management tool, which I think tenner is working on part of his 10 stack to do a tool like that, I think that would be something nice. Right. You mentioned documentation. I agree. And the big one that I will also add and elaborate on what you said, Jamon is as a consultant for me when I'm choosing a state management tool, it's what is my client familiar with?

Because with my comfort, my ability to use it, the client's needs kind supersede that, right? So I need to learn, get up to speed on it and making sure that if they have web devs, what are the web devs familiar with mainly so we can kind of work together to use a state management tool that works for it. Which leads me to why we decided our stack within my project. It's because we knew web was going to be a project towards the end, one repo for all three platforms. So I was like, are you all familiar? Have you used this in the past? And the answer was yes. I was like, okay, we should wait this one more heavily than something else that I'm more familiar with. For example,

Robin Heinze:

In a lot of ways our approach has changed in that regard just because our clients have changed.

We used to do a lot of startups where they didn't have any development team at all. And so we would come in and we were completely responsible for building the app. They weren't going to take it over from us, it was just us. And so we could kind of make a lot of these architecture and stack decisions completely on what we preferred and what we were comfortable with. And in the last four or five years, our clients have gotten bigger and they have their own teams, they have their own existing technology preferences and they're a lot more sure of what they want. And so then it becomes our job to integrate with that, which we're happy to do. It just means that we don't have as unified of a standard of a stack between our projects, which is fine and it means we get to learn and know a lot more different tools.

Jamon Holmgren:

And I think really that leads us into our last thing here, which is really you should form your own opinion and there are some individual needs that will happen here no matter what. I like to use AI to help me decide and just sort of put in my preferences and then ask it which one sort of matches those needs the best. Not just preferences, but also constraints and what people know and things like that.

Robin Heinze:

My AF needs offline support, data caching and data input, data caching. And I as a developer really like things that have a lot of boilerplate and good documentation. What's a library I should use?

Jamon Holmgren:

My list would be is it performant? Is it easy to debug? Are there good

Robin Heinze:

Debug tools? That's a huge one.

Jamon Holmgren:

Elegant API don't like boilerplate, seamless offline persistence because every app really should pick up where you left off. It shouldn't reset to the beginning if it happens to get killed. There's some apps where I know that no matter when I open it, it's going to be right at the last page. The athletic is a good one where it doesn't matter if it's been months and months and months. I open that app and it'll be at the article I was last reading, which is awesome.

And it keeps the whole back stack of all the previous articles that I had opened. So it's really cool. Great documentation, of course, great third party integrations, service side APIs, like a variety of those, GraphQL, whatever, because we don't control the backend. So for me that's important. Maybe you can get away with something where you have to use one specific backend and that's fine. But this is just sort of from my perspective, having a positive and helpful community is big. I think there are some communities that aren't that, and I don't want to be tied

Robin Heinze:

To that re you're going to get stuck at some point.

Jamon Holmgren:

Yeah. Oh yeah, totally.

Robin Heinze:

And having a place to turn to that's separate from the documentation because likely if you're stuck, you've been reading the documentation and you're still stuck and you need someone with experience to read your problem and help give experienced advice. So it's always nice when they're nice about it.

Jamon Holmgren:

And that starts with the maintainers. And so that's my last thing is active maintainers who really care.

Robin Heinze:

It's a good list.

Jamon Holmgren:

Do you have a list, Robin?

Robin Heinze:

I don't have a list, but I would say I'm a person who learns by doing.

And so if you're trying to decide what state management library you prefer or is right for your project, just try it. Try it in a side project or even try it in your actual project for a and see how it goes. Because really the only way you're going to get a feel for is this working for me is to use it. That's why I always like to have a side project or two just going all the time so I can kind of use it as a playground or a test bed for this kind of thing. I really have to get my hands on it to see.

Mazen Chami:

And mazen, what do you have? Cool. Yeah, mine was Do you need it? I feel like I say that I ask that question a lot. I was like, yeah, you need this one on top of your list performance and usability. So I would, to me that sounds like elegant, A PIA clean API to use. And it was documentation and community support because again, all of our packages are open source, so we need that community support.

Jamon Holmgren:

So if you had to decide right now and you couldn't say it depends, and you were building an app for yourself, Zen, what would you use for state management?

Mazen Chami:

I would use ent.

Jamon Holmgren:

Okay. You'd use ent.

Mazen Chami:

Got it. Along with React Query for my

Jamon Holmgren:

Data layer. Yeah. Alright, Robin?

Robin Heinze:

I would use React query.

Jamon Holmgren:

React Query, okay.

Robin Heinze:

And if I needed more beyond that, I would probably try to stand because I haven't actually used it, but based on what I've heard, it seems to be pretty good and a lot of people are happy with it. So that's probably what I would try. I'm going to leave it there because there's a million. It depends. There's a million if depends. It depends. It depends. Qualifiers.

Jamon Holmgren:

I think for me, I would do Legend State and use the sync system that Jay built mostly because Jay's a good friend and anytime I report a bug he fixes it. So it's nice

Robin Heinze:

When the person responsible for the bugs is a close friend and you can just ping him.

Jamon Holmgren:

I love Legend State. It's great. I have used it on a couple of side projects and stuff. So that's that. Robin, do you have a mom joke to take us out of this episode?

Robin Heinze:

All right, I've got one. This is Jam's joke, but I'm going to tell it because that's how this works. I met a microbiologist once. They were a lot bigger than I expected.

Jamon Holmgren:

Didn't see that coming. Alright, we'll see you all next time. Bye.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Hines and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.