Let's have a quick discussion around how we're going to design the redock side of our project now and
of course, naturally makes sense for us to have a quick discussion about design.
But on a normal application that you're working on, on your own, you might decide, you know what,
I know what I'm doing.
I'm just going to start writing code right away.
Whenever you start working on a script project with Redox, I cannot recommend enough.
You just sit down for a couple minutes and really think about the design of your product store.
So think about the different reducers, the information they're going to hold, some of the different
action creators and actions you're going to need to create as well.
The more time you spend up front, the better your code is going to be.
And I really guarantee that when you start making use of typescript.
So that means we're going to take a look at a couple of diagrams and understand how we're going to approach
the design of our Reduc store.
The first thing we really need to do is understand the data that we're going to eventually fetch from
that NPM API.
So this is the general URL that we're going to make a request to to do some kind of search for all packages
with some kind of keyword.
In this case, I've got a hardcoded search keyword in here of react.
So we're going to change react right there to whatever term or whatever string a user enters into that
little search bar.
So it might instead be a user looking for packages around Redox or something around bootstrap or whatever
else.
I'm going to take this full URL, I'm going to visit it inside my browser, and we're going to take
a look at what data we have to really work with from this API.
OK, so here we go.
So here's the response we get back from NPM, you'll notice we get a top level object right here.
Inside of it is a object's property and then objects is an array of objects in each of those objects
has a package property.
This package property has information about some search results.
So in this case, the very first package I see is not unsurprisingly react.
I can then scroll down a little bit.
Next one is react, Dom.
A little bit more, yes, lint plug and react, you get the idea.
So it looks like we get these different package objects and inside there is all the information we're
going to eventually want to use to print some stuff on the screen.
So that means firstly I want to do is just clarify one little piece of terminology that we're going
to use inside of our project.
Without a doubt, when we make a request to NPM, we are definitely fetching something called packages.
And he could see that very clearly in the response.
We were just looking at.
However, a little bit of a gotcha or a little bit of a catch here for you and I.
The word package is a reserved keyword in typescript.
So reserved keywords such as very similar to like how for an A for loop is or import and so on.
So if you just write out package inside of a typescript file, that has a very special meaning.
The reason I mention this is that if you're fetching a list of packages, we might eventually want to
have some variable inside of our project called something like package, or we might want to have an
interface called package or something like that.
And very quickly, we would start to run into some errors coming from TypeScript, as it says, hey,
you're using some kind of reserve keyword right here.
So rather than calling these things packages inside of our project, we're going to refer to them as
repositories, not technically accurate.
I know.
Absolutely.
But regardless, we're going to call these things.
We are fetching repositories throughout our entire project rather than calling them a package or anything
like that.
So just a little clarifying note here.
OK, so now at that moment, let's think about how we can design our Redux store, so I came up with
this approach and this is a pretty standard approach.
Nothing too crazy here when it comes to redux.
I think that inside of our Redock store, we should have one kind of slice or piece of state called
repositories.
So this repositories piece of state will be produced by maybe a repositories reducer and this reducer
will maintain three different properties inside of it.
So we'll have a data property and that's going to be our list of repositories that we get back from.
NPM will have a loading flag.
So that'll be a boolean indicating whether or not we are currently making request.
And then finally, an air property that will be some kind of string if we ever run into some kind of
error as we make a request over to the NPM API.
So I could but you could guess where we would use each of these inside the actual UI of our project.
If we are currently loading, we could show a spinner or something like that.
If we get an error, property or error message will show that on the screen.
Otherwise, we'll take our list of repositories that we have fetched, render them out as a list and
show the user all these different repository names.
So I think that the reducers side of things not too crazy, pretty straightforward.
So now we need to think about our different action creators and the different actions that we're going
to send into this reducer as well.
I think that we probably only need one single action creator, something called maybe search repositories
or something like that, and will pass in as an argument to the section creator, the search term that
we want to use for our search.
So I'm calling it name here.
Maybe we will eventually call it term or whatever you want to call it.
This action creator is going to eventually dispatch one of a variety of different actions, so are action
creator can produce an action and remember, send that off to our store to be processed by all of our
different reducers of search repositories.
So that action is going to indicate that we have made a request and it is currently pending.
Search repository success will indicate, as you guess, we successfully made the request, we've now
got a list of search results and then search repositories er will be if we ever run into an ER during
that request that we're making.
And then to support each of these actions, which remember are objects that have a tight property and
the paler property, we need some different action types so that we can correctly identify these different
actions instead of reducer.
So our different action types, which are always going to be strings, will be something like search
repositories, search repository success, search repositories.
Er, nothing too crazy here.
Very standard action types.
So these are pretty much all the different things we need to create on the right side of our application,
we got to create that action crater.
We got to have these three different possible actions.
We need to create three different action types and then one single reducer.
Now, lastly, I want to mention about all this design stuff is just how we're going to structure the
different files and folders inside of our project.
So here's one way that we might decide to implement all this stuff inside of our Sarsae directory.
We might eventually have some kind of components folder.
Very standard, very typical.
Inside there, we might have an app component and maybe our entire search thing is called like repositories
list or something like that.
We then might have a separate folder for all of our redock stuff and inside there would be our reducers,
action creators, middleware or whatever else we need to create.
Now, in a typical Redox and React project, you sometimes see a lot of different import statements
reaching into this redox folder and trying to get.
At all these different stores or CBD store that we create and trying to get at the different action
creators and stuff like that, so we eventually might have inside of our app component an important
statement that tries to get our reduc store.
We might have inside of a repositories list something to fetch in different action creators.
Maybe the repositories list needs something else.
Maybe the app component needs to get an action creator as well.
Who knows?
The point is, in this diagram that I'm really trying to make here is that in a typical project that
you see with Redbox, there are a lot of different import statements that reach from our components
folder into many different places inside of our redox directory or wherever we are placing our reduc
stuff.
I really recommend you avoid this approach when you start making use of typescript.
Instead, I really recommend that you instead create a single location or kind of a single entry point
that's going to give access to all the redock stuff to the rest of your project.
So we're going to create a single index dots file inside of some Redhawks directory or some folder where
we're going to hold all of our reduc stuff.
We're then going to import all of our different action creators, all of our different middleware as
all of our different action types.
We're going to import everything into this indexed Ortez file and then re-export it from that file.
So if any of our components ever need anything from the redux side of things, they're not going to
reach into our redox folder and try to get at all these different files.
Instead, we're going to get everything from this index file.
So this is really our communication point from our redock side, the application to the outside world.
And again, you're going to see a very quickly that this dramatically simplifies a lot of things.
And it means that we're not going to have a total spaghetti mess of imports and exports where we've
got just tons and tons of different files in communication with each other.
So this really is a strategy that's going to dramatically simplify things.
And I really recommend you take this approach on your own projects.
All right, so long enough video here, long discussion, let's take a pause and then start putting
this design into action in just a moment.