Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .prettierrc
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
{
"singleQuote": true,
"semi": true
}
23 changes: 20 additions & 3 deletions src/App.jsx
Original file line number Diff line number Diff line change
@@ -1,14 +1,31 @@
import './App.css';
import ChatLog from './components/ChatLog';
import messages from './data/messages.json';
import { useState } from 'react';

const App = () => {
const [entries, setEntries] = useState(messages);

const handleOnLike = (id) => {
setEntries((prevEntries) =>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Nice use of the callback setter style. In this application, it doesn't really matter whether we use the callback style or the value style, but it's good practice to get in the habit of using the callback style.

prevEntries.map((entry) =>
entry.id === id ? { ...entry, liked: !entry.liked } : entry

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We showed toggling the particular value directly in the handler 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 handlerCountLikes = () => {

Copilot AI Dec 16, 2025

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The function name handlerCountLikes is inconsistent with the naming pattern used elsewhere in the component. The function handleOnLike follows the handle[Action] pattern for event handlers, but handlerCountLikes mixes "handler" with "Count". Since this is a helper function that computes a value rather than handling an event, it should be named countLikes or getLikeCount to better reflect its purpose.

Copilot uses AI. Check for mistakes.
return entries.filter((entry) => entry.liked).length;
};
Comment on lines +17 to +19

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 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.

Consider not using handler in the name of the function (as Copilot recommended above). handler makes it sound like this should be registered for a user event callback, when really we're just calling it to perform a calculation as part of the render logic.

Note that if we passed the messages in as a parameter rather than depending on having them be visible in the enclosing scope, we could actually move this logic entirely out of the React component, making this business logic more testable.


return (
<div id="App">
<header>
<h1>Application title</h1>
<h1>Chat between Vladimir and Estragon</h1>
<h2>{handlerCountLikes()} ❤️s</h2>
</header>
<main>
{/* Wave 01: Render one ChatEntry component
Wave 02: Render ChatLog component */}
<ChatLog entries={entries} onLike={handleOnLike} />
</main>
</div>
);
Expand Down
31 changes: 22 additions & 9 deletions src/components/ChatEntry.jsx
Original file line number Diff line number Diff line change
@@ -1,21 +1,34 @@
import './ChatEntry.css';
import PropTypes from 'prop-types';
import TimeStamp from './TimeStamp';

const ChatEntry = () => {
const ChatEntry = ({ id, sender, body, timeStamp, onLike, liked }) => {
return (
// Replace the outer tag name with a semantic element that fits our use case
<replace-with-relevant-semantic-element className="chat-entry local">
<h2 className="entry-name">Replace with name of sender</h2>
<article className="chat-entry local">
<h2 className="entry-name">{sender}</h2>

<section className="entry-bubble">
<p>Replace with body of ChatEntry</p>
<p className="entry-time">Replace with TimeStamp component</p>
<button className="like">🤍</button>
<p>{body}</p>

<p className="entry-time">
<TimeStamp time={timeStamp} />

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

</p>

<button className="like" onClick={() => onLike(id)}>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

onLike is currently marked required, but doing so causes a props warning when the waves 1 and 2 tests run. Due to the project structure, it would be preferred to leave onLike marked not required, and have logic within the component checking that a usable value has been provided before trying to use it (to avoid calling an undefined value).

{liked ? '❤️' : '🤍'}
</button>
</section>
</replace-with-relevant-semantic-element>
</article>
);
};

ChatEntry.propTypes = {
// Fill with correct proptypes
id: PropTypes.number.isRequired,
sender: PropTypes.string.isRequired,
body: PropTypes.string.isRequired,
timeStamp: PropTypes.string.isRequired,
liked: PropTypes.bool.isRequired,
onLike: PropTypes.func.isRequired,
Comment on lines +26 to +31

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

};

export default ChatEntry;
38 changes: 38 additions & 0 deletions src/components/ChatLog.jsx
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
import './ChatLog.css';
import PropTypes from 'prop-types';
import ChatEntry from './ChatEntry';

const ChatLog = ({ entries, onLike }) => {
return (
<>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A fragment <> is only required if we don't have a single top-level tag (component) being returned.

Here, <ul> serves as the single top-level tag, so the fragment can be omitted.

<ul>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should keep in mind the overall HTML constructed by our components when picking the HTML tags. We have ul here, but ChatLog emits a list of ChatEntry components, whose HTML representation starts with article. So this results in something like

<ul>
  <article>...</article>
  <article>...</article>
  ...
</ul>

article is very appropriate for ChatEntry, so here, we might use something like section or div to group the articles rather than ul.

{entries.map((chatEntry) => (

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice use of map to convert from the message data into ChatEntry components. We could perform this mapping storing the result into a variable we use in the JSX result, we could make a helper function that we call as part of the return, or we can perform the map expression as part of the return JSX as you did here. I often like having relatively simple maps directly in the JSX since it helps me see the overall structure of the component, though it can make debugging a little more tricky. But any of those approaches will work fine.

<ChatEntry
key={chatEntry.id}
id={chatEntry.id}
Comment on lines +11 to +12

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 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).

sender={chatEntry.sender}
body={chatEntry.body}
timeStamp={chatEntry.timeStamp}
liked={chatEntry.liked}
onLike={onLike}
/>
))}
</ul>
</>
Comment on lines +7 to +21

Copilot AI Dec 16, 2025

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The React fragment wrapper is unnecessary here since there's only a single child element. The fragment can be removed and just return the ul element directly, which would simplify the code.

Suggested change
<>
<ul>
{entries.map((chatEntry) => (
<ChatEntry
key={chatEntry.id}
id={chatEntry.id}
sender={chatEntry.sender}
body={chatEntry.body}
timeStamp={chatEntry.timeStamp}
liked={chatEntry.liked}
onLike={onLike}
/>
))}
</ul>
</>
<ul>
{entries.map((chatEntry) => (
<ChatEntry
key={chatEntry.id}
id={chatEntry.id}
sender={chatEntry.sender}
body={chatEntry.body}
timeStamp={chatEntry.timeStamp}
liked={chatEntry.liked}
onLike={onLike}
/>
))}
</ul>

Copilot uses AI. Check for mistakes.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment from Copilot is pointing out what I mentioned above about not needing the fragment <>.

);
};

ChatLog.propTypes = {
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,
onLike: PropTypes.func.isRequired,
Comment on lines +26 to +35

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

};

export default ChatLog;