Conversation
and imported proptype and time stamp to chatentry, also added sender into the component and used timestamp
…g , passed entries chat data as well as the toglelike prop
anselrognlie
left a comment
anselrognlie
left a comment
There was a problem hiding this comment.
Looks good! Please review my comments, and let me know if you have any questions. Nice job!
| <header> | ||
| <h1>Application title</h1> | ||
| <h1>Chat App</h1> | ||
| <p>{getTotalLikes()} ❤️s</p> |
There was a problem hiding this comment.
Consider h2 rather than p. It feels surprising to me to see a paragraph in the header.
| <button className="like">🤍</button> | ||
| <p>{body}</p> | ||
| <p className="entry-time"> | ||
| <TimeStamp time={timeStamp}/> |
There was a problem hiding this comment.
Nice use of the supplied TimeStamp. We pass in the timeStamp string from the message data and it takes care of the rest. All we had to do was confirm the name and type of the prop it was expecting (which we could do through its PropTypes) and we're all set!
| body: PropTypes.string.isRequired, | ||
| liked: PropTypes.bool.isRequired, | ||
| timeStamp: PropTypes.string.isRequired, | ||
| onLikeToggle: PropTypes.func.isRequired, |
There was a problem hiding this comment.
The id, sender, body, timeStamp, and liked props are always passed (they're defined explicitly in the data and also provided in the test) so we can (and should) mark them isRequired.
The remaining props were up to you, and the tests don't know about them. As a result, using isRequired causes a warning when running any tests that only pass the known props. If you didn't see those warnings when running the tests, be sure to also try running the terminal npm test since the warnings are more visible.
To properly mark any other props isRequired, we would also need to update the tests to include at least dummy values (such as an empty callback () => {} for the like handler) to make the proptype checking happy.
Alternatively, for any props that we leave not required, we should also have logic in our component to not try to use the value if it's undefined.
| entries: PropTypes.arrayOf( | ||
| PropTypes.shape({ | ||
| id: PropTypes.number.isRequired, | ||
| sender: PropTypes.string.isRequired, | ||
| body: PropTypes.string.isRequired, | ||
| timeStamp: PropTypes.string.isRequired, | ||
| liked: PropTypes.bool.isRequired, | ||
| }) | ||
| ).isRequired, | ||
| onLikeToggle: PropTypes.func.isRequired, |
There was a problem hiding this comment.
Similar to the props for ChatEntry, here, the entries prop is included in the tests, but the like toggle is not, resulting in prop warnings (unless we update the tests to reflect our custom props).
Again, if we were to leave this as not required so as to avoid the test warnings, we'd want to be sure that all the script logic in our component worked properly even in the absence of this value.
| key={entry.id} | ||
| id={entry.id} |
There was a problem hiding this comment.
👍 The key attribute is important for React to be able to detect certain kinds of data changes in an efficient manner. We're also using the id for our own id prop, so it might feel redundant to pass both, but one is for our logic and one is for React internals (we can't safely access the key value in any meaningful way).
| <p className="entry-time"> | ||
| <TimeStamp time={timeStamp}/> | ||
| </p> | ||
| <button className="like" onClick={() => onLikeToggle(id)}>{liked ? '❤️':'🤍'}</button> |
There was a problem hiding this comment.
👍 Passing the id of this message lets the logic defined up in the App find the message to update in its data.
Nice use of a ternary to pick the emoji to show for the liked status. Consider moving even something small like this to a helper function external to the component, so that the behavior of the emoji-picking logic can be tested easily outside of React.
| const updatedMessages = chatData.map((entry) => { | ||
| if (entry.id === id) { | ||
| return { ...entry, liked: !entry.liked }; | ||
| } | ||
| return entry; | ||
| }); | ||
| setChatData(updatedMessages); |
There was a problem hiding this comment.
In this case, calculating the next version of the message data using the current state variable and passing that updated version to the state setter shouldn't cause any problems, but we still generally prefer using the callback style of setters. Using that approach, we pass a function to the setter whose parameter will receive the latest state value, and which returns the new value to use for the state.
setChatData(chatData => chatData.map(entry => {
if (entry.id === id) {
return {...entry, liked: !entry.liked};
} else {
return entry;
};
}));We showed this approach in class, but technically, we're mixing a few responsibilities here. rather than this function needing to know how to change the liked status itself, we could move this update logic to a helper function. This would better mirror how we eventually update records when there's an API call involved.
In this project, our messages are very simple objects, but if we had more involved operations, it could be worthwhile to create an actual class with methods to work with them, or at least have a set of dedicated helper functions to centralize any such mutation logic.
| }; | ||
|
|
||
| const getTotalLikes = () => { | ||
| return chatData.filter((entry) => entry.liked).length; |
There was a problem hiding this comment.
Nice job determining the total likes based on the like data of each message. We don't need an additional piece of state to track this, since it can be derived from the existing state we are tracking.
Great idea to filter down the data to the liked messages and use the list length as the count. This is a really understandable alternative to the more canonical reduce approach. Compared to reduce, it does make a list potentially as long as the message list, but since we know a similar copying gets done anyway during a render (building the ChatEntry components) on the whole it's not any more costly.
| setChatData(updatedMessages); | ||
| }; | ||
|
|
||
| const getTotalLikes = () => { |
There was a problem hiding this comment.
Notice that we could move this helper entirely out of the component if we passed the current messages data as a parameter, rather than using enclosing scope to access it.
|
|
||
| const ChatEntry = () => { | ||
|
|
||
| const ChatEntry = ({id,sender, body,timeStamp, liked,onLikeToggle}) => { |
There was a problem hiding this comment.
👍 I like using destructured props to make it more visibly clear in the function definition itself what props we're expecting to receive. We do need to remember that these are all passed in as a single object (the one we usually call props) and it can cause problems if we forget to include the destructuring syntax (it's easy to forget and list the props as multiple separate params), but I really prefer the glanceability.
2 participants
No description provided.