A user can now enter in a new blog post but we need to automatically navigate back.
Now there's definitely an easy way to do this and a slightly more complicated but slightly better way
to do it as well.
Some inside of my create screen component inside of here.
Remember we had actually copy pasted all this code over from our show screen and so we've actually got
some leftover code inside of our props argument right there where we d structuring out our navigation
prop so if we wanted to handle navigating a user back to our next screen very easily we could go back
down to our button element right here.
I could add in a set of curly braces around the body of the on press function and then immediately after
we call add blog post we could then call navigate or see me navigation dot navigate and pass in the
name of index mail take us back to our index route.
So like I said this is a very easy way but maybe not the best thing to do.
Nonetheless I'll say this and just do a quick test now I should be able to make new post it at blog
post ensure enough it does in fact take us right back.
So that definitely works.
But why is it maybe not the best.
Well it's actually really simple right now.
Add blog post is taking in a title and content and if we flip over to where that function is implemented.
So here's add blog posts inside of our blog context file.
You'll notice that we immediately commit that change and save it inside of our reducer or essentially
we update our state.
And that's all a very automatic and instantaneous process.
Now there might be some scenario where we start to change our application and actually we are going
to eventually do this where instead of just updating our state we might want to actually make a network
request to some outside API.
And when we make that request we might then want to wait to get some kind of response that our blog
post has been successfully created on that outside API before we navigate our user back to that big
list of blog posts.
So if we decide to add in some functionality to save this new blog post to an API we would not then
want to immediately call navigate after calling add blog post because we would add the blog post that
would initiate the call to the API.
We would then instantly navigate back to the index page and then some amount of time later we might
then eventually get a response back from the API and we might actually get an error maybe the API for
some reason would reject our request to make the new blog post.
And so in that scenario we would have navigated back to the index page way too soon.
So in order to solve that we could possibly.
This would be just a little bit more challenging.
We could essentially passing that navigate call inside of a callback to add blog post.
So in other words inside of ADD blog post I'll put in a third argument right here.
I'll give it a callback function and I'm gonna put the navigate call inside there.
So now we can go and modify add blog post and we can say after we have successfully saved or dispatch
an action to save the blog post then we can go ahead and invoke this callback which will actually navigate
us back to index.
Now this is not strictly necessary for our current application because we are not saving these blog
posts to some outside API.
I just want to mention that this would be a very valuable solution for handling any kind of saving of
data when we want to actually make use of an outside API now just adding in that callback is not enough.
We have to of course actually go back over to our blog context.
Here's our add blog post function and so we are now getting a third argument right here of a callback
it's now inside of here.
We could say OK after doing that dispatch successfully only then do our callback.
Like so now if you want to know what this might look like if we actually were doing an API request like
I mentioned we're going to eventually work on the application where that does happen but just very quickly
I want to show you what we could do here so we could turn this function into an async function and then
maybe make a request with axioms so we could do like an axiom post of whatever with the title and content
and then we could wrap all this in a try catch statement
Whoops there we go.
E like so now in this scenario if anything goes wrong with the requests that we make to that outside
API so if it results in some kind of error we will not run the dispatch or a callback and we would just
jump directly to that catch statement right there instead.
And so in that scenario we could very easily handle some request resulting in an error in not immediately
navigate the user back to the index screen.
Now again we don't need this code that we currently have.
This is just a very quick demonstration in case you're curious.
I'm going to delete all that stuff I just added remove the async keyword and there we go.
OK.
Let's now save this.
We'll do a quick test and we'll make sure that we still navigate back to our index screen.
Once we successfully dispatch that action.
So I'll go back over once again tap on the plus enter in my title some content at the blog post and
we still navigate back over.
Perfect.
Now as I'm looking at this index screen right here I'm also noticing that we've still got the ad post
button right there.
Ad post as it's being called from our index screen is not really going to function correctly anymore
because remember that ad post never passed in a title or a content or for that matter an actual callback
either.
So we probably want to go back to our next screen and just remove that button really quickly because
I suspect that if we now tap it we will end up with an error.
And yeah sure enough we do OK.
So I'm gonna go back over to my next screen.
Here it is right here.
I'm going to scroll down and find where we place that button.
Here it is right here.
It's going to take that button out we no longer need the reference to add blog post inside of here.
So I'll delete that from our D structuring off of context I'll say this once again and now once again
just try create a quick blog post and yet it looks good.
OK.
So this looks pretty good.
So we've now got the ability to here's a diagram.
Delete list show create.
And now finally we need to take care of edit as well.
So let's tackle edit starting in the next video.