This course has been updated! We now recommend you take the State Management with Redux & MobX course.
Transcript from the "Jetsetter Solution: Q&A" Lesson
[00:00:04]
>> Steve Kinney: Cool, any large questions?
>> Steve Kinney: Yeah.
>> Speaker 2: So, [INAUDIBLE]
>> Steve Kinney: So we have a few choices. We have to persist it somewhere. So the first question to ask yourself is, where do you want to persist it? Step one would be if we want to save it in local storage.
[00:00:28] What we could do is say, we could pass a callback to all those set states so that whenever they're changed we could save it to local storage. We could parse that local storage when the component mounts. Right, and then set the state from there. Step two would be if we had a server somewhere, right?
[00:00:45] Things get a little more complicated now because when you have a server somewhere, things can go poorly. There could be no network, right? The network could be very angry at you cuz you sent invalid data. You could get new data back. So what we'd have to do likely is, a really great pattern for this is, we might have a state on the given things that we're submitting, the new item.
[00:01:06] Or changing the item to maybe are you loading or doing like this is what we're talking about communication stage in the beginning. We would need communication state to know whether or not we're sending something to the server. And then we would either, you have two choices. You can do stuff optimistically, right?
[00:01:21] Which I prefer as a pattern, which is assume that everything is gonna go well, right? They check the thing, move it in the UI, right? If things didn't go well, display an error and move it back, versus the user clicks the thing. Wait till you hear back from the server, right?
[00:01:39] In different situations it comes down to UI choice, if it is likely to succeed, right? At we have APIs where we actually don't know whether or not the transaction will succeed for two or three minutes because it goes on a worker queue, right. So we just assume that everything went well, right.
[00:01:57] And then if it doesn't, we deal with it later. But we would immediately set the state to show it as removed or toggled or whatever. Schedule a worker because they most always succeed because they're set to keep retrying. And then if for some reason after a lot of amount of time then we would put it back in the database, right.
[00:02:14] So it all really depends. For local storage, you do it every time you set the state. For a network, you're either gonna have to send the request and then wait until you hear back positively and then just do the same setting of the state. Or do it and then tell the network and hope everything is okay, right?
[00:02:28] And if that promise rejects, you could move it back and stuff along those lines.