[MUSIC PLAYING] BRIAN YU: OK, welcome back
everyone to CS50 Beyond. We continue where we
left off this morning. This morning we introduced React,
a JavaScript-based framework to allow us to quickly
and easily build user interfaces via declarative
programming, describing what it is that we want the
page to look like in terms of various different components. Then putting those
components together to be able to create an application
that's interactive. In order to update the
application, we didn't need to do what we did before
in the world of imperative programming of saying, go
to this part of the page and insert certain components
or other HTML elements inside this section of the page. We would just update our data,
update the state of our components in order to say this value of the
state should take on this new value. And React would take care of
the process of updating the user interface to reflect whatever it is
was contained inside of our state. So we're going to pick
up where we left off, continuing in with the morning project. So there are a number of
different ways to solve the problem in this morning's project. I'll show you a couple of
them now just to give you a sense for the different
approaches, the way that you can use React to
implement some of these features. And then I'll introduce what
the afternoon project will be. And the main focus of
the afternoon lecture is just going to be
thinking in React, thinking about what components we
need, what state we need, how we might set up an application. And then we'll actually go ahead and
try and implement the afternoon project. So let's go ahead and get started
with the to-do list application, where we left it off this morning. So as of earlier this morning,
we had a to-do list application that had a list of tasks, whereby
I could type in a task, task one, and I click Add task. And that allows Add tasks
to show up in this list. But of course, task one is still
listed here in the input field. How do I get rid of task
one from the input field? Going back to this morning, how would
I remove task one from the input field when I click Add task,
clearing out that field? Which function needs the change? Yeah? AUDIENCE: Send the value
of input to empty string. BRIAN YU: Good, set the value
of input to empty string. And where should I do
that, in which function? AUDIENCE: In add task? BRIAN YU: Great, in add task. So when I add a new task,
I want to do two things. In addition to taking my tasks
array and updating it, filling it in with the new thing, I
also want to say, all right whatever the value of the
input field was before, just go ahead and set that equal
to the empty string, because I want to clear out the input field as
soon as I click the Add task button. So I'll go ahead and
refresh this, try this out. I type in task one, click Add task. And all right, great, the task shows
up and this field clears itself out. The other thing that we
ask you to do this morning was show a count of how many tasks
are currently in the task list. And someone else tell
me how you did that. What did you change and what
code did you have to write? I know many of you did this. So how did you do it? Show how many tasks I currently have. Yeah? AUDIENCE: Use .length. BRIAN YU: Yeah, if you have an array
in JavaScript, and you use .length, you can get at the length of the array,
the number of elements in the array. And so if I wanted to display the
number of tasks that I currently have, I could just say number of tasks. And then using curly braces, again,
to mean plug-in some JavaScript value here, where are my tasks stored? What would I type? In the state? OK, this .state.tasks. And then .length to get at, OK, here
is the number of tasks that I actually have as of this moment inside
of my application state. So I refresh that. And now I see, OK, tasks,
number of tasks is zero. But as soon as I add a first
task here and click Add task, multiple things happen. The list updates. We also see that this clears
out and number of tasks updates to reflect the
length of that array. Questions about any of that? All right, so the challenging piece
of this, of the morning project was really the deletion of tasks. How do you take a task
in this list of tasks and delete it so we no longer have it? And so let's take a look
at how we implemented that. We'll scroll up to the top. For every list item, when we map
over all of our tasks, right now we just have a list item that lists
the name of the task just like this. If I wanted to do more than that, well,
I could just add to this list item. In addition to just having a task,
I'll also have a button, for example. And that button we'll just call delete. And let's leave it at that for
now, just putting a button there. Right now the button
doesn't do anything. But let's at least see
it so we can visually see what that button looks
like on the to-do page. We'll refresh the page. OK, number of tasks is zero. And I could say, OK, task one
for example, add the task there. And all right, great, we
see the Delete button. We also see task 1 show up next to it. They're a little bit close together. So you might try and modify
some of the spacing of things, the margin around the
button, for instance, in order to give yourself
more space if you wanted to. But of course right now, even if I
have multiple tasks, I can click Delete and the delete buttons aren't
doing anything just yet. So how do we actually delete a task? Well, we probably want
some function that's going to take care of deleting a task. And so one way to do this might
be to say, all right, delete task. And I saw people approach this
in a couple different ways. So I'll show you both
ways that you could have tried to approach this problem. One way would have been to
say, all right, delete task. Well, this is a function
that's going to take some argument, some like
index for which task it is that I actually want to delete. And the logic there would
be, well, all right, when I click on the
button, button on-click. Let me go ahead and delete that
specific task corresponding to index I, which is the
index I'm currently on. So you might have tried to write
something like this .deletetask. And then in parentheses, you
might have thought all right, let me put in the variable I there. Now, this doesn't quite work. Does anyone know why
this doesn't quite work? It's a little bit subtle. Yeah? Exactly. Exactly. This on-click attribute should
take as its argument a function. And the idea is that
that function will not be called upon until we
actually click on the button. But right now what we're
passing into on-click is the result of calling a function. The fact that you see
parentheses after this function means that we're actually calling
the delete task function, which is not what we want to do. What we want to do is we
want to pass the function into the on-click attribute,
but not actually call the function until we click on it. So a couple ways to potentially
handle that, the simplest way might have been just to wrap this whole thing
inside of a function, where, oops, undo that. What did I just do? Delete task takes an index. I think I accidentally deleted that. And instead of saying on-click
equals this .deletetaskI. We can wrap this entire
thing in a function as simply as adding an extra
set of parentheses and an arrow. Remember, that arrow
syntax creates a function. And so we've created a function
that doesn't take any arguments, but that when it's run, will actually
perform the deletion of the task. So this is one way to do things. And so now what exactly does the
delete task function need to do? Well, it needs to remove the
task at this particular index. So I'm going to say this .setstate. And the new state is going to
be a function of the old state. I'm going to take the old state,
modify it by removing the task, and then returning the new state. So this is going to be a function
that takes the old state. And then what do we need to do? Well, the first thing we need to do
is get a copy of that list of tasks. Because I can't modify the state
itself, as we mentioned before, you should never modify the
state directly and react. So I'm going to create
a variable called Tasks. And that's just going to be equal to
this .state.tasks filled into a brand new array. So I create a copy of that list, save
it inside of a variable called tasks. And then I want to remove
whatever is at index I. And so as we've decided this
morning, the way we would do that is by saying tasks.spliceindex1. In other words, saying remove
whatever is at index--index. And how many things should I remove? 1. Now, the return value of splice is
going to be the array that was removed, that was spliced out of the tasks array. But tasks itself, as
a variable, is going to be the original array with
whatever we wanted to remove removed. So there's a slight nuance
there that I saw a couple people struggle with a little bit. Just know that what splice of
returns is different than what the actual value of
the tasks variable is. And now that I've spliced
out whatever was an index, I can now use this variable tasks to
be the new list that has the thing index--index removed from it. And so this is a function. So the last thing I need to
do now is return something. And I'm going to return, all right,
what should the new tasks be? It should be just this
variable called tasks. And so this is a slightly more
complicated set state function. In particular, it's more
complicated because it's really more of a full
fledged function where I'm defining variables, and
manipulating those variables, and returning some value. Their add task meanwhile,
was a much simpler function, whereby I could just say I didn't
need to create any new variables. All I needed to do was say
we start with this state and we're just going
to immediately return this object that represents the changes
that we're going to make to the state. And so I'd just take a look
at Add task and Delete task, and see if you can get an understanding
for the differences between the two. All we need to do in Add task
is add to this tasks array. But in Delete task, we really
need a little bit of extra logic to copy the array, remove
something from the array, and then return what the
new object should be. Questions about anything so far? This was one way to implement
things from this morning. Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: If you're
getting an error about-- so I would first check to make sure
that your curly braces in parentheses match the curly braces in
parentheses that I have here. You might be using the keyword
in a place in your code that you're not allowed to use it. But if you're still getting
that error after that, it's probably some
syntax thing that we can take a look during the project time. Yeah? AUDIENCE: Why wouldn't we use
this .setstate for delete task? BRIAN YU: We are using this
.setstate for delete task. Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: In the Add task function-- so this is a little bit
of a nuance of the way that arrow functions
in JavaScript work-- if all we're doing in a
function is taking some input and immediately returning its
output without anything else, I can just say state
as the input, arrow, and then immediately give
whatever the thing I'm returning is, which is this JavaScript object. And so if that's all
the function is doing, there's no additional logic, no loops,
no variables, or anything like that, then you don't need to
explicitly say return. Whereas in Delete task, the function
is a little more complicated. I need variables. I need to manipulate those variables. And so at the end of that, I do need
to explicitly say return something. Yeah? AUDIENCE: What is
.something, [INAUDIBLE].. BRIAN YU: This is because
I'm calling this .setstate. And the function that I'm passing into
this .setstate is this entire thing. This function. And so this function, what
it's returning ultimately is a new set of tasks that is
going to become the new state. Yeah? AUDIENCE: Shouldn't this
be just state, not .state? BRIAN YU: Oh, you're right, this
should just be state, not this .state. Thank you. That's a good catch. Yeah? AUDIENCE: If you put the variable
conts task outside of this .setstate, will that work? BRIAN YU: If you put conts task outside
of this .setstate and you do something like this .state.tasks here,
this will work in this example, but it suffers from the potential for
the race conditions that we talked about earlier where if we're basing
the new state of the old state, we should really be using the state
input to the set state function. So in this example, it
will work fine both ways. But good design habit to get into
the habit of doing things this way. Other things? I think there are other questions. Yeah? AUDIENCE: I think we
probably have [INAUDIBLE].. BRIAN YU: Yep. AUDIENCE: So we decided to
practice using [INAUDIBLE].. BRIAN YU: Right, we're wrapping this
delete task inside of a function so the delete task isn't run until
we actually call this function. And this is a common way
in programming to delay the evaluation of some expression
is just to wrap the whole thing inside of a function. And only when you call that function
will the value actually be evaluated. So this will work. This actually is a little
bit inefficient in the sense that every time I
generate a button, it's going to regenerate one
of these new functions. And so I'll show you another way
of doing the exact same thing. Totally fine to do this, but if you're
looking for really trying to optimize your react code, I'll show you one
other method of achieving the same goal, where instead of wrapping this
whole thing in a function, I can just use this .delete task. Again, I'm not calling
the function just yet. Delete task is going to
be called eventually. But this time delete task is not going
to take an index as its argument. But instead, what I'm going to
do is I'm going to associate some data with this button. In the same way that in JavaScript
before we could attach data attributes to HTML elements, we can
do the same thing here, because this is just JavaScript, where
I can say buttondata-index is going to be equal to I.
Remember, data attributes are a way of adding
information data that we care about to our HTML elements. And here I'm just adding I as the data
attribute of this particular button. So now when someone
clicks on delete task, this delete task is going to
take an event as an argument, because we're going to
need access to the event. Because if we try and
get at the event.target, that's going to give us the button,
the button that we clicked on. And if we access the data set for that
button, the data attributes of it, and get at the index of that
dataset, what that's going to do is it's going to give us access
to the index of the button. It's going to take that button,
get at its data properties, and get at the field called data-index. And that will give us access to whatever
the index of this particular row happens to be. And so this will behave the same way,
where I can say task one and task 2. And if I delete task two, all right,
great, I'm left with just task one. And the number of tasks decreases
from two to one as well, because React is dynamically going
to update the DOM with any changes as a result of changing
the state of my components. So two different ways of
achieving the same thing. I'm just showing you
both, because they're both the types of things that you
might see in the world of programming in React. Questions about anything? Yeah? AUDIENCE: If we do it this,
it's like a data attribute. For the index we use just value. Does that work for you? BRIAN YU: Yeah, you can use
other attributes as well and access as attributes,
and that would probably work. Yep? AUDIENCE: [INAUDIBLE] BRIAN YU: So again, delete
task, just to review, is getting the index from the
data attribute of the button. Then updating the state. And to update the state,
we take the original tasks, splice out whatever was at index
I, and then return the new tasks. And a small bit of JavaScript
shorthand, which you don't need to know, but might be useful sometimes, is if
ever you have a situation where the key of a JavaScript object has
the same name as the value, you actually don't
need to say tasks:task. If you just say tasks, that will
implicitly just mean the key in a value have the same name. And so this is just a little bit of
shorthand for doing the same thing. But no need to worry about
that if you don't want to. Yeah? AUDIENCE: Are you worried about
this being inside set state? Is it better to be outside? BRIAN YU: This, it doesn't
matter whether this is inside or outside of
set state, because it's not dependent upon the state variable. So you could calculate
the index wherever. So long as you have
access to the same event, the data index value is
always going to be the same. So it doesn't matter if it's
inside or outside of the function. Other things? Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: Yeah so these events you can
think of as the same sorts of events we were dealing with in JavaScript before,
where when I say button on-clicked equals this .addtask task for instance,
then the event that is happening is the click event. And the target of the
click event is the button that I actually use to do the clicking. And so the way this works in the case
of delete task is that when I call this .delete task, it's going to be
provided with the click event, the fact that I clicked on a button. And if I access event.target,
that's going to give me which button I actually clicked on
to do the deleting. So if I have 10 buttons, each of which
has a different data-index property, then if I go to event.target
and look at what data-index is, I'll know which button
I clicked on and so I'll know which task I should
remove from my list of tasks. Yeah? AUDIENCE: So [INAUDIBLE],, but basically
what I did is after delete task, hit the button I, I
used the index for I. And then down at the function
delete task, I used [INAUDIBLE].. BRIAN YU: Yeah, so I showed
two possible ways of doing it. And so one way is to do it the
way that you're describing it. Yep. Yeah? AUDIENCE: Can you explain
why the code is [INAUDIBLE].. BRIAN YU: So we only need event
as an input to the delete task function because we need to use event
to access the target, namely the button that we clicked on, because
we need the button to get at the data attributes of the button. In the first method
that we used, we didn't need to access any data attributes. So it didn't actually
matter to have access to the button that was clicked on,
because delete task was already being provided with the index. So we didn't need to access the event. Other things? Yeah? AUDIENCE: Why is this
way more efficient? BRIAN YU: This way is slightly more
efficient because in the other way when we created a new function for each of
the on-clicks where we did curly braces arrow, this .deletetaskI, that would
be a situation where every time it's creating a new button, it's
creating a brand new function in order to put in on-click. Whereas here, I'm just using the
same this .delete task function. And so it's just a
slight efficiency benefit that's really not a big deal here. Though in larger applications,
you might imagine it could start to become a big deal. In this case, it's probably fine
just to avoid over optimizing. And either way is OK. All right, so really the
best way to get good at React is to start writing
applications in React. And we'll do some of these together. And so that's what the goal of
today and tomorrow is going to be. React is a new way of thinking
about writing programs. It's a new way of working
with programs, and thinking about state and applications, and
how to modify the user interface. And so we'll go through a couple
now slightly larger projects that will step through the
beginning parts together to give you a sense for the types
of things that you can do with React and how to think about designing
an application in React. And so the application
we're going to build now is going to be a similar analog to
the quiz application we had before. We're to create a
flash card application. And so the flash card
application is ultimately going to look something like this. When it's done, it's going to
have a couple different modes. It will have a card Editor. And a card Editor basically allows
me to input terms and definitions into the cards. So maybe I want to create
addition flash cards, for example, to help me practice for the addition
game that we did earlier this morning. So I do a front side and a backside. A front and a back for the card. Press Add card. And all right, that adds
to this list of cards. I can add other front and
back and more as well. If I wanted to delete a card,
I can delete a card too. And then if I want to, once I'm
satisfied with editing these cards, I can switch to the card Viewer. And the card Viewer is
going to show me a card. If I click on it, it'll flip
it over so I can see the back. If I click on it again, it
will flip back to the front. And I can click on New
card to get me a new card. Get me the next card in the list. When I click on that,
it'll flip over, show me the back of the card,
so on and so forth. I can switch back to the Editor. I can switch back to the Viewer. So this is the application
we're going to build. And it seems a little bit complicated. But let's try and break
it down into components. And what's the first thing
that you might notice? What is this interface
at least remind you of in terms of things
we may have done today? Yeah, it reminds you
very much, hopefully, of the tasks management application
that we did this morning of just creating a to do list of tasks. This is effectively
exactly the same thing, except instead of a task just
having one field for the task, the task has a front and it has a back. It's two input fields instead of one. So this interface is
probably largely going to resemble what it is that
you did earlier this morning. We just now need to add a Viewer to it
as well to be able to view those cards and flip the cards over
from front to back. So questions about the
goal-- what we're trying to achieve in writing this application? All right, let's go ahead and
dive right in and actually start working on the application. So we'll go ahead and create a new file. We'll call it flashcards.html. And I'll go ahead and start with
just going ahead and copying the to-do app just so we get
the basic structure of it. But I'm going to completely empty out
what's inside of class at, at least for now. We'll give it a title of flashcards. And all right, let's
actually think for a moment. If I say term and definition,
what are the different components that I might divide my application into? Process to different
components of the application? There are at least two big
components of the application, distinct parts of the application
that behave differently. The Viewer and the Editor. Great, I have this Editor right here
that is a place where I can edit tasks, add tasks to them. And I also have some Viewer that
lets me view all of the cards that I currently have inside
of my flash card table. And so those are probably at
least two different components that are going to behave differently. So one thing I might do right
away is say, all right, I'm going to have a class called card
Editor that is going to be a component. And for now, let's go ahead and render
that just by returning a div that says this is the Editor. So all right, I have a
class called card Editor. And all the card Editor is going to
do is say this is the Editor, at least for now. In addition to that,
I probably also want a class called card Viewer that
going to extend React.component. And we're going to render it by
returning for now this is the Viewer. So all right, we have two classes,
card Editor and card Viewer. And right now they just say this
is the Editor, this is the Viewer. And I can test this, make sure
it works by inside of my app. In order to render the
app, let's for now just return a card Editor and a card Viewer. We'll load both components into the
application, one on top of the other, just to see how this looks. I'll go ahead and open
up flashcards.html. And all right, great,
this is what I see. I see the card Editor that
just says this is the Editor. And I see the card Viewer that
just says this is the Viewer. But of course I don't want to display
both the Editor and the Viewer at the same time. So let's step by step start
building up this application. What is a piece of state that I
need inside of my application? Yeah? AUDIENCE: Whether you're
on Editor or Viewer? BRIAN YU: Exactly,
whether I'm on the Editor or whether I'm currently on the Viewer. So it's some notion of, like, what the
current mode of the application is. And so I could implement
this by saying, all right, let's create a constructor that
takes props, super props just to make sure that the component
gets its props correctly. And let's give some state
to this application. We care about knowing
whether or not we're in the-- so we could do this state
in a number of ways. We could say, all right, let's
add a mode property to the state where the mode could start
out being Editor, for example. And then mode could be any
number of different things. But right now there are
only two different modes. So I'll just say Editor is true. We'll have a piece of
the state called Editor. By default, it is true. So by default, I'll see the Editor. And if ever the value changes,
I'll show something else. And so, OK, what do I do now? Well, inside the Render function,
we'll say something like if this .state.editor, implicitly if
this .state.editor is true, then what do I want to do? Well, I want to return a card Editor. And otherwise else, I want
to return a card Viewer. And I go ahead and delete this
unnecessary return here at the bottom. So here is the render code for my app. I'm basically checking
whether this .state.editor, should the state of my application
be showing the Editor or not showing the Editor? If I am supposed to
show the Editor, then go ahead and return the card Editor. Otherwise, go ahead and
return the card Viewer. So if I load the page now,
refresh flashcards.html, I just see this is the Editor and I
have no way of accessing the Viewer. I only see the Editor. Questions about anything? BRIAN YU: All right, so
let's take the next step. I can have the Editor. And now I want some way of flipping back
and forth between Editor and Viewer, between Editor and Viewer, going back
and forth between these two components. And so I probably need
some way inside of my app to change the value of
this Editor piece of state. I want some function that is going to
change whether Editor is true or false. So I'll go ahead and add a new function. And the new function,
we'll call it switch mode. Switch mode is going
to be a function that takes me from Editor mode to
Viewer mode, and from Viewer mode to Editor mode. So it's going to be a function. In order to do that switch, I need
to set the state to something. So I'm going to start
with some starting state. And what is the new state? What goes in here to switch
the mode of my application? Yeah? AUDIENCE: [INAUDIBLE]. BRIAN YU: Yes, so we have inside of
this .state a notion of where we are. If Editor is true, we
should be on the Editor. If Editor is false, we
should be on the Viewer. So yes, good, we need that. And, yes? AUDIENCE: Editor, [INAUDIBLE]. BRIAN YU: Yeah, exactly. Editor, we're going to
change the value of Editor to exclamation point
for not state.editor. So whatever the value of
state.editor was before, let's take whatever is not that,
so if it was true, it's now false. It was false, it will now be true. And that will be the new
value of Editor, for example. So all right, now what I need is I
would like some way for maybe the Editor to have a button and the
Viewer to have a button that will result in switching the mode
of the application, for example. And so how do I go about doing that? Well, there are a of ways to do it. I could put the button
directly in the app right here and just have a button
at the bottom that's going to say, like, switch mode or something. Another way to do it would be
inside of card Editor for instance, let's go ahead and add
maybe a horizontal row. HR just creates a horizontal row, a
line, across the page effectively, and a button that says go to Viewer. And in the Viewer, go ahead and create
a horizontal row and a button that says go to Editor. So OK, I have the task Editor that has a
button that says go to the task Viewer. And I have the Viewer that has a
button that says go to the Editor. If I refresh the page, it
says this is the Editor and there's a button
that says go to Viewer. Of course if I click on
that, nothing happens. Nothing happens because
I haven't specified what should happen when I click
on this Go to Viewer button. What I would like to happen, if I click
on the Go to Viewer button in the card Editor component, is that it calls the
switch mode method of my app component. But there is a slight
problem, what's the problem? Why can't I just say switch mode? Yeah? AUDIENCE: They're in different classes. BRIAN YU: They're in different classes. Exactly. Switch mode is a method
inside of the app component, but I want to be able to call it
from the card Editor component. They're in different
components, but I want the card Editor to still be able to
call a function inside of the app. So how would I do that? Any thoughts on how I
might solve that problem? The function is inside
of the app and I would like to give it to the card Editor. In other words, pass information about
that function or pass the function itself to the card Editor so
the card Editor can use it. Thoughts on how to solve that problem? We saw the solution this morning. Yeah? AUDIENCE: Could you
have it extend the app? BRIAN YU: Could you
have it extend the app? Yes, you could. Generally, React doesn't recommend that
you have different classes extending other classes, because
generally the classes want to do pretty distinct things. But that could be one
solution to the problem. Yeah? AUDIENCE: You can use a property. BRIAN YU: You can use a prop. Great. And that's going to be the
solution we're going to use. We learned already that if I want to
pass information into the card Editor, I can add props to the card Editor. I can say, all right, give the card
Editor a switch mode property that is equal to this .switchmode. Remember, I'm inside of the
app component right now. And when I load my
card Editor component, I would like to provide it with
a property called switch mode. And that is equal to the
this .switchmode function. I'm passing this function
into the card Editor component so that the card Editor
component can use that function. It can be helpful here to think
about the hierarchical structure of the application. We have the app, which is the
big container, inside of which is the card Editor. And the app is going to give the card
Editor this, this.switchmode function so that the card Editor
can now use that function. Yeah? AUDIENCE: Let's say you have a function
that every single last [INAUDIBLE] would use. If you could find that
function, [INAUDIBLE].. BRIAN YU: That's a good
question about if you had a lot of components that were all
trying to take advantage of functions that are modifying the
state, with just React, you'd have to do something
along these lines. Although, there are other libraries. In particularly, a library called
Redux, which is quite popular, which helped to make that process easier
and can have some useful abstractions for simplifying that process. We're not going to get our chance
to talk about it this week. It's a little beyond on
the scope of the class. But Redux is what you should
look into if that's something that you're trying to do. So OK, I provided the switch mode
property into the card Editor. And now inside of card Editor,
what should button on-click do? What is the function that I need
to call when the button is clicked? AUDIENCE: This .prop. BRIAN YU: This .props.switchmode. Great. I want to access the
switch mode function, and the switch mode
function was provided as one of the props of
this card Viewer component. So when I click on the button, it
should call this .props.switchmode. I'll go ahead and refresh the page. It says this is the Editor. I click on and go to the Viewer,
and, uh-oh, something went wrong. Why did that not work? This .props.switchmode. AUDIENCE: [INAUDIBLE] BRIAN YU: What did I not do? I didn't edit-- oh, I
edited the Viewer class. Yes, thank you. I'll go ahead and make the same
change to the Editor class button. When you click on it, unclick
this .props.switchmode. Thank you for that. OK, now if I refresh the page
it says this is the Editor. If I click on Go to Viewer, it switches. Now I'm on the Viewer,
I click go to Editor and why did that one not work now? Oh, why did that one not work? Why did card Viewer not work? Anyone know? AUDIENCE: [INAUDIBLE]. BRIAN YU: It has this .prop.switchmode. But what did I forget? AUDIENCE: [INAUDIBLE]. BRIAN YU: I need to give it the prop. Exactly. So I have card Viewer, but I didn't
provide it with a switch mode prop. And so I need to say card Viewer and
switch mode prop is going to be equal to this .switchmode for example. So now I have the Editor. I can switch to the Viewer and hopefully
I can switch back to the Editor. You can go back and forth
between the two just by changing the state
of the application. Questions about anything so far? All right, so let's go ahead and
try and build out this Editor. We'll try and build the Editor together. And then I'll leave most
of the Viewer to you to try and figure out if you'd like to. So inside of our
application, we currently have some state that indicates
whether we're on the Editor mode or on the Viewer mode. We're also going to need
some state about, like, what the current cards inside
of my collection of flash are. Like, what are the cards, what's on
the front, what's on the back of them. And an interesting question comes
about of where should that state live, should that state be inside of app,
should it be inside of card Viewer, or should it be inside of card Editor? Each is a component, each can have
its own state, which component should maintain the list of all of the cards? What do we think? Yeah? AUDIENCE: [INAUDIBLE] Editor. BRIAN YU: Yeah, exactly. We want the state about all the
cards to be accessible to both the Editor and the Viewer. So it probably makes
sense to put the state about what all the cards
are inside of the app, give the state access to cards, which
by default will just be an empty list. That way we can provide that information
to both the Editor and the Viewer, and both can have access
to that same state. And this is an idea you'll commonly
see in React called Lifting State Up that you might think, OK, the
card Editor needs to have access to state about all of the cards. But if we lift the state up out of the
card Editor and into the application, then anything the application
uses, any of its components can have access to that
same piece of state. Questions about that? All right, let's go ahead and try
and build the card Editor now. So importantly, when I
have the card Editor, the card Editor needs to
know what the cards are. So I'm going to go ahead
and provide the card Editor with an additional property. And that property is just going
to be called cards, I suppose. And cards should be equal to what value? AUDIENCE: This .state.cards. BRIAN YU: This .state.cards. Great. This is inside of my app component,
and so when I have the card Editor, I want to provide it with cards, and
its value should be this .state.cards. You'll notice this line is
starting to get a little bit long. So it's often common in
React paradigms to see each prop to be on a new line of its own. And so you'll often see something that
looks a little something like this, where I'll return card Editor. Cards is equal to this .state.cards. And I'll also give it
access to switch mode. And I'll do the same for card Viewer,
give it access to cards in this .state.cards, give it access to
switch mode for the card Viewer. They both need access to
that same information. So now let's go ahead and
build our card Editor. Right now all it does is
just say this is the Editor. Let's add some HTML to it. At this point, I can just write
HTML and declaratively describe what it is that I want
the Editor to look like. Well, it should be in H2,
maybe, that says card Editor. You can make it in H1 also,
make it a little bit smaller. And underneath the card Editor,
I want there to be a table. A table where I have
rows and columns, a way to show the front and
the back of each card, and then a button to delete each card. So underneath this, I'll say table. The table is going to have a
table head and a table body, either just HTML just to make it easy
to separate the heading of the table from the body of the table. And the heading of the table is
going to have a table row, just a row along the top of the table. And that row is going
to have three columns. The first column will be, OK,
this is the front of the card, this is the back of the
card, and here's a button to delete this particular card. So I have a row at the top of
the table, front, back, delete. And inside the body of the table,
here is now where all of the rows are going to go. And oftentimes an easy way of just
doing this is by declaring a variable and then we can go back
and actually declare it. I'll just say curly braces rows,
meaning the rows of the table are going to go here. Now, rows is a variable I
haven't yet actually defined. And so I can define a variable up
at the top of the render function. I can define a variable
called rows, which is going to be equal to, all right,
well how am I going to get all the rows? Well, this is going to
look very similar to how we got that unordered list of
items inside of our task list. What I'm going to say is,
where are the cards stored, this .state or this .props? Props. Great. Why props? Why are the cards in the props? Yeah? AUDIENCE: [INAUDIBLE]. BRIAN YU: Yeah, so in app when
we were creating the card Editor, we passed in cards as one of the
properties of the card Editor. And so now in order to access those
cards, we can say this .props.cards. And then I want to again map
over each of these cards, doing something with
each card, in particular, creating a table row
for each one of them. So I'll say map and we'll
go map over every card, and also give it an index variable
I so we have access to which card it actually is. And we're going to go ahead
and return a table row. Each card is going to correspond
to a single table row. We'll give that table
row a key, because React likes to have anything that's
iterated over a key that is unique. And we'll give it three cells
inside of that row, a front, a back, and a Delete button. For the first cell,
we'll say card.front. We'll make each one an object. Right now we haven't actually
seen how we create a new card yet, but this is how we would
print them out for instance. Then we'll have another
one that says card.back. And then we'll have another one
that's just a button that says delete. So OK, I've defined rows, which is
going to be taking all of the cards and mapping over them,
looping over all of the cards. And for each card, creating a new row. That row has three columns, one column
to represent the front of the card, one column to represent
the back of the card, and one column to be a button that
I can click on to delete the card. Very similar again to
the task management example from earlier this morning. So hopefully you can see the
parallels that are there as well. Take a look at the example
from this morning at the map that we were doing
over the list of tasks. And you'll see a lot of similar
code that's being used here, a lot of similar ideas in React. To test this out, rather than starting
cards off with an empty thing, I can just for the sake of example give
it, OK, front is going to be test front and back is going to be test back. And we'll go ahead and add a second
one, front equals test 2 front, back is test 2 back. Just giving it some default state
that I'll delete eventually, but that'll be useful for
now until I have the ability to add cards to be able
to see what are the cards that I currently have
inside of my application. If we open up flashcards.html,
all right, great, we see now that we have
a card Editor and we have three columns, front, back, and delete. The Delete button
doesn't do anything yet. But at least now I can see
the contents of my Editor. What questions do you have so far
with what we've done just now? We just created an Editor where we
can see the contents of whatever flash cards we currently have. I'm going to add some CSS code just
to make this look a little bit nicer. If we go up to the top of our HTML
page, this is very similar to CSS code I've added before. So we'll go through it
a little bit quickly. But feel free to stop and I'll post
this code once we move into project time if you want to take a closer look at it. But basically tables, and table
data cells, and table heading cells, I should probably change the
headings to table headings. I'll actually do that now. The headings should probably
be th instead of td. Effectively, this isn't
changing a whole lot. But it helps to make sure
that HTML knows that these are in fact headings for the tables. So the table, table data
cells, and table headings, those will have a border that is a one
pixel solid block border for example. And so, OK, what does that look like? All right, we have a one pixel solid
black border around each of the cells. I don't like the fact that there is two
lines between a lot of the information. And so in order to collapse
that inside of table, we can use the border collapse
is collapsed CSS property. That'll basically take all of the
neighboring sections of the border and just collapse them down. And now this feels a little bit cramped. So I'd like to add a
little bit more space in between these various
different elements. So for table data cells
and table headings cells, let me add 10 pixels of padding on
the inside of each of those cells. And that will be space on the
interior of the border such that when I refresh the page now, all
right, this looks a little bit better, at least a little more
aesthetically pleasing. And you should feel welcome to
mess with the CSS all you want. You can add colors, change the
border if you would like to. You can center the table if
that looks better for you. So feel free to make any changes to the
style and the aesthetics of the code, and also the functionality of
the code if you choose to do so. Questions about anything thus far? All right, so we have this table. And now in addition to
having a table, I also need some way of adding a new card. So I'll go ahead and
say line break here. And I'll have an input whose
name is going to be front and that'll be it for now. And an input whose name
is going to be back, and actually I'll give each of
them a placeholder at least. I'll call it front of card
and place holder back of card. So we have two input fields now. And I'll have a button
that says Add card. So I have two input fields, one
called front, one card called back. And a button that's going to add
a new card to this list of cards. Press Refresh. Some error somewhere. I executed closing tag for input. Oh, I need a flash to
close these input tags. All right, now I have a card Editor. It's got a table. And I also have a place where I can type
in the name of the front of the card, then whatever goes on
the back of the card. And then a button to actually
add that card to this table. So now what state do I need
to keep about the card Editor? What can change about the card Editor? Similar in spirit to what
we had with the to-do list, what are two pieces
of state that I need? Yeah? AUDIENCE: The input. BRIAN YU: The input. Yeah, what it is that I'm
typing into the front field, and what it is that I'm
typing into the backfield, that all needs to be state
inside of my card Editor. So I'll go ahead and
create a constructor that takes in some properties. And I'll set the initial value of
this .state equal to, all right, well, the front of the card by default
is just going to be empty. And the back of the card is by
default also just going to be empty. And that's going to be
the value of this .state. If I scroll down to
these two input fields, this is the input field where I type
in what goes on the front of the card. This is the input field where I type
in what goes on the back of the card. The value of this input field is
going to be this .state.front, whatever it was on the
front of the state. And the value for the
back, this .state.back. I'm basically doing the same thing
I did with all the input fields before, just giving them a value so
that I can later refer back to them. Both of them need an on change property
for what happens when I actually start typing something into this input field. And I'll just say this .handlechange
as the name of the function for when I actually start typing something into
the front field or into the backfield. For the back one, I'll do the same
thing, onchange=this.handlechange. And now let's write the
handle change function for what should happen when I start
typing something into the input field. And let me do that underneath at
the end of the render function. Handle change is going to be a
function that takes its event. And handle change is going to need to
modify the state of the application. And if I wanted to change the front of
the value front inside of the state, I could say this .state front
is equal to event.target.value. And that would change the front value. And if I wanted to change what
was on the back of the card, I would have to do this .state
back equals something else. And so this is a little bit problematic,
because I'm using this .handlechange for both front and back. I'm using the same event handler,
this .handlechange for both of them. And so I need some way of
differentiating between these two event handlers or saying, if I type
something into the front input field, then I want to change the
value of this .state.front. And if I type something
into the back input field, then I want to change this .state.back. And so taking a look
at these input fields, is there any property that
would be helpful for doing that? Take a look on 63 and 64,
any attribute these elements have that would be useful. Yeah? AUDIENCE: You could somehow
put the name [INAUDIBLE].. BRIAN YU: Yeah, exactly. I could somehow take
advantage of the fact that the name attribute of
this input field is front and the name attribute of
this input field is back. And I would like to if the name
is front, set the state for front to be event.target.value. And if it's back, then
set it to the back value. And so JavaScript has some
special syntax for doing this. It's not something you've
likely seen before. But if I in brackets
say [event.target.name], well that's going to say whatever
the value of event.target.name is, let's go ahead and use that as the key. And then event.target.value is
going to go ahead and be the value. So I can use a single
handler to be able to handle changing both the front and
the back value of the state. So something you might
see from time to time, this is common when you have
multiple different input fields. And rather than create a handle
change front function and a handle change back function, which
would just be repetitive, you can just have a single function
that takes care of all of that. Yeah? AUDIENCE: [INAUDIBLE]. BRIAN YU: Yeah, so I could add logic. I could equivalently do this by
doing ifevent.target.name=front, then do something, and else do
something else, and that would work too. And again in React as with
almost any programming project, there are many ways of
achieving the same things. So pick the thing that
makes the most sense to you is often the best piece of advice. So all right, I have a
card Editor now where I can type something into the front
of the card and something else into the back of the card. And clicking Add card
right now does nothing. So let me go ahead and write a function
that is going to add a new card. Now to add a new card, do I need to
modify the state of card Editor, card Viewer, or app? Again, I have three components. Which state do I need to
modify to add a new card? App state, right. Because app, that class,
is the one that actually has cards inside the
state of the application. So we're going to need to add a Add
card method to this application. And the Add card method, we'll
have it take two arguments. We can choose what the arguments are. But it's probably going to make
sense for the Add card method to take an argument for the front
and an argument for the back. And then do something
with those two values. So to add a card with a front equal
to front and a back equal to back, I can do this .setstate. I want to update the
state of my application. And I want to set
cards equal to, well, I want all the existing
cards plus my new card. So I'll say ...state.cards to say
fill in all of the existing cards into the array. And now I'd like to add
my new card to this array as well, where the front is
going to be equal to front, and the back is going
to be equal to back. So I'm updating the state,
saying take the old state, go ahead and fill in all of
those cards, and then just tack on to the end of the array a new
object where the front of the card is this variable front, and the back
of this card is this variable back. Yeah? AUDIENCE: [INAUDIBLE]. BRIAN YU: Yeah, excellent point. So I mentioned this a moment ago
of JavaScript object shorthand, because front's key and front's
value are the same name, they're both called front and back,
they're both called the same thing, this happens often enough in JavaScript
that there's shorthand for it. I can just say, front,
back and it's just going to assume the keys and
values have the same name. And so this will do
exactly the same thing. But yeah, that's the
shorthand I can use. Yeah? AUDIENCE: Can you repeat [INAUDIBLE]. I'm a little bit confused with event. Why does switch mode not take an
event, if it also [INAUDIBLE]?? BRIAN YU: So why does switch
mode not take an event. Switch mode could take
an argument called event. JavaScript option has
functions that have these optional arguments that if you
wanted to take an event argument, it can. But switch mode doesn't
need to access the event. Because the only thing the
switch mode function needs to do is take, whether it's on
the Editor and the Viewer, and switch it to the other Viewer,
the other component that I have. And so nothing about the event
actually matters for the logic of the switch mode function. Whereas by contrast, handle change
actually does care about the event. The event of me changing the input
field is important for two reasons. One, I care about the event, because I
care about the name of the input field that I was typing something into. Was I typing something into the
front field or the backfield? And depending on that, I want
slightly different logic. And it also matters because I care about
what is it that I actually typed in. Because what it is that I typed in
should be the new value of either front or back in the state. So if you need to access
the event for some reason, usually to get at event.target, the
thing that's triggering the event, then you'll need the event
parameter in the function. But if you don't need the event, then
it doesn't matter whether you include it or not. And so generally speaking,
we won't include it. Yeah? AUDIENCE: For all the examples
you've been doing [INAUDIBLE] Is there a reason we're doing that
instead of on the bottom click maybe change the state
of the [INAUDIBLE].. BRIAN YU: So when the
button is clicked, we want to be able to just look
at the state of the application to be able to know what is the front
value and what if the back value. And so generally in
React, any time something changes in the user interface,
that should be represented by some underlying change in state. In other words, if you know
the state of the application, what the value of this .state
is for all of your components, I should be able to tell you exactly
what the page is going to look like. And so that's just sort of
part of the React paradigm. Yeah? AUDIENCE: [INAUDIBLE]. BRIAN YU: It depends on what you
try to do with properties that you don't provide in. So if you try to use a property
that you don't provide and just, like, paste it into the HTML content
somewhere inside your render function, odds are it will work but just
nothing will show up there. But if you try and do any logic
with it, like, if you try and call or pass it in as arguments to
functions or perform operations with it and they don't exist, then
you could start to get errors. So you do want to be a little
bit careful about that. Other things? OK, so we have this Add card function. And in particular,
this Add card function is a function that our card
Editor needs to have access to. And so I'll go ahead and
add to this card Editor. The card Editor knows
how to switch modes. But the card Editor also needs
to know how to add a card. So Add card will be
equal to this .addcard. And now inside of our card Editor,
when you click on the button, on-click, I'll call this .addcard. So this is a different
Add card function. But what needs to happen when
I add a card in a Viewer? Well, two things need to happen. One is I need to actually call
the Add card function in my props. This .props.addcard, passing in
whatever was in the front input field and whatever was in
the back input field. And that information is stored in this
.state.front and this .state.back. And then what else should I do
from a user experience perspective if I type in something into the
front input field, type in something into the back, and click Add card? AUDIENCE: Clear out the states. BRIAN YU: Clear out the state's. Clear out the input field so
that we say this .setstate. Front is going to be empty. Back is going to be empty. And so we're saying
clear out those input fields so that we can start fresh. Go ahead and refresh the page. Front of the card, it
will be test three front. Back of the card, test three back. I'll go ahead and click Add card. And all right, great, we got a
new card in this list of cards. And the input fields
cleared themselves out. At this point, I'm going to go
back and delete these sample cards that we had just for testing purposes. We'll go back to just
starting with an empty list. And now I can begin to add
whatever flashcards I want. I can say, OK, 1 plus 1, plus 2. We can do as many of
these as you want to. But of course, the Delete
button doesn't yet work. We can create all the cards,
but we can't yet delete a card. And so to do that, it's
going to be basically the exact same thing as
what we just did for adding a card, but the analog for deleting,
as we did with the tasks example. So inside of the app, we
had a function called Add card, which took care of adding a card. But our app is also going to need
to know how to delete a card. And to delete a card, we're going
to delete a card based on its index. And this code should look
very familiar to the code we did when we were doing task management. We're going to say, all
right, this .setstate. It's going to take the original state. And let's go ahead and
say, all right, the cards, let's make a copy of state.cards. And let's go ahead and
splice out of the cards remove something from
the cards array at index. Remove one thing and go
ahead and return cards is equal to whatever
the value of cards is. So what's happening here? When I delete a card, at this
particular index, I'm saying, OK, make a copy of state.cards, store
it in this variable called cards, remove what was ever
at this index, remove one element using the splice method. And then I'm returning the new state,
update the value of cards in the state to be equal to this variable cards. And as we've seen a couple of times
now, because these things have the same name, you could even
simplify this to just return cards. And we'll implicitly assume
that they have the same name. So now I have this delete
card method in my app that operates in order to delete a card. This is also a function that card
Editor needs to have access to. So we'll say delete card
equals this .deletecard. And we'll go ahead and
now go to the card Editor. And we'll do the same thing we
did before, this button will give a data index property of-- I'm sorry, not the Add card button. The Delete button-- yeah,
here's the Delete button-- will give it a data/index
property of, all right, what is the index of which element to
delete if I try and delete this card? It'll be I for example. And then when I click on it, we're going
to call the this .deletecard method. Same as the example from
earlier this morning. And now when I delete
a card, that's going to be a function that
takes the event as input. And why do we need the event? Well, because
event.target.dataset.index. In other words, take
the click event, get out its target, the button that
I clicked on, get at its data attributes, and specifically, get at
the data-index attribute of the button then I clicked on. This is the index of the
card I want to delete. And so to actually do the deletion,
I'll say this .props.deletecard. I'm deleting whatever was at that index. So I have a delete card function
inside of the card Editor that calls the delete card function that
was provided to me as one of the props. And the only difference is
this function, delete card, is going to take care of
providing to the apps delete card the index that I
actually want to delete. Yeah? AUDIENCE: [INAUDIBLE]. BRIAN YU: Repeat that? AUDIENCE: [INAUDIBLE]. BRIAN YU: We don't need to wrap it
because we're not actually calling this .deletecard. I'm not saying this
.deletecardI, which you could do. I'm just saying this .deletecard. And so that is a function that we'll
run when the button is clicked. And so there's no need to wrap
that inside of an outer function. Yeah? AUDIENCE: Why can you find
delete card twice separately rather than just call
the card function that's defined in the app and [INAUDIBLE] BRIAN YU: So you could do it that way. You could wrap this in a function
and say, this .props.deletecardI. And that would work just fine. Basically, having a function
that when you call it is going to go to props.deletecard
and delete that element. But I'm putting it separately
for the efficiency reason that I described before of not
regenerating these functions over and over. Let's check to make sure
this actually works. So let's do test, test. Another one, another one. If I delete a card, all
right, it gets removed. If I I delete another card, we're
able to add and delete cards from the card Editor. Questions about anything? Yeah? AUDIENCE: [INAUDIBLE]. BRIAN YU: Good question. So the delete card function
inside of the app class is a delete card function that
just takes an index and removes whatever card is at that index. And I had another
function in card Editor that I could have
given a different name. But it's deleting a card, so I
decided to give it the same name. And all this function is doing is
it is calling the original function, passing in which card
to actually delete. You could conceive of other
models where you consolidate these into one function. I separated into two for
the sake of separating the behavior of deleting a
card at a particular index and responding to the fact that you
clicked on a button that is supposed to do the deleting of the card. Though if you'd like to practice,
it would be an interesting exercise to consolidate this to
just a single function. And you can try doing it that way. All right, so now we have
the ability to edit cards. And all that remains
is this card Viewer. And so we have this, this is the
Viewer page where in theory you'd be able to view whatever contents
of the cards that you have, because card Viewer is going to
provide this cards argument that is going to contain all of the
cards in the current state. Questions? OK, so there's a lot of code here, a
lot of interacting and moving pieces. We have an app that is
this big component that contains within it two smaller
components, a card Editor and a card Viewer. And there's a lot of interaction
between these components. The app is providing
props to the card Editor, providing information about the
cards, providing event handlers for what to do in order to
add a card or remove a card. And in response, the card Editor
is calling a lot of those functions that it was provided in order to say,
OK, update the application state, update the cards or change the
mode from the Editor to the Viewer, or vise versa. So I definitely encourage you
to take a look at this example-- I'll post it online in just a moment-- and try and tease it apart. Try and figure out how it's working. In fact, potentially try and add
new features to it if you'd like. And the main project of this afternoon
is going to be to extend on this. The first step is going to be
understand the code that exists there. But then let's think about trying
to add some more possibilities. So adding flash cards is a
feature that we already have. Displaying the flash cards
in a table, the second thing here is a feature that we already have. And it's these last two bits that
are worth trying to implement here. Try and implement the card Viewer,
some way of viewing the flash cards. And at first, just see
if you can get one flash card to display the front of
card number one, for example. And then see if you
can add some notion of, all right, when you click on
something, have an on-click handler that flips the card over. In other words, goes from
storing the front to the back. And you might think about the kind
of state that you want to store that. You probably want something inside
your application state that's keeping track of are you
on the front of the card or are you on the back of the card? And when you click on
the card, you just need to flip that state around
going from front to back. In much the same way that we
went from Editor to Viewer, when you clicked on a button, you
can go from front to back of the card by clicking on the card. You can display one card, and show the
card, and flip it over to the back. Consider a button that moves
you on to the next flash cards. So you're on card number
one, you press a button, it takes you to card number two. And that's very similar in
spirit to just this idea of thinking about what you need to
store inside of your application state. In addition to having information
about are you on the front of the card or the back of the card, you
probably also want some information about which card are you currently on? Some notion inside the
state of I am currently on card zero, or card one, or card two,
whereby you can change that state value in order to show a different card. So go ahead and give that a shot. If you manage to finish
that, there are certainly other features you can consider. I listed a couple here. Consider a button that will shuffle the
cards and put them in a random order, for instance. Or marking cards as learned or not,
the one you might see on a quiz app like Quizlet, for example. And so plenty of room
to explore here as well. Feel free to continue working
on the to-do list application if you'd like to. The staff will be around to
certainly help you up until 5:00. And tomorrow, we're going to
spend even more time on React. So if this all seems new
and unfamiliar to you, know that tomorrow we'll be spending
more time on the exact same topic so that we can help you
become familiar with it, help you get used to the different
way of thinking with regards to React. And so all that and
more with CS50 Beyond. So we'll go ahead and turn
to our afternoon project now. Feel free to stick around
here in the auditorium. And come and find the staff if
you need help with anything.
