-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue #2: Render the List and list items a user has access to #20
Conversation
Visit the preview URL for this PR (updated for commit 136cf25): https://tcl-77-smart-shopping-list--pr20-fz-rc-read-lists-ite-ce8hiwiv.web.app (expires Sun, 25 Aug 2024 21:13:30 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: b77df24030dca7d8b6561cb24957d2273c5e9d72 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey guys! This code looks very clean and readable! Nice job! 🫡. One I got curious about was the decision to use “data.length !== 0 “ . Negative lengths I believe are impossible haha, and this is really just semantics, but what do you guys think about the decision to check “data.length > 0 “ so it explicitly checks whether the length is greater than 0? I’m curious about your thoughts!
I do like the way that |
Thanks for the kind words and great question! You're absolutely right—negative lengths are impossible, so checking data.length > 0 would work just as well and might even be a bit clearer. We went with data.length !== 0 to explicitly highlight that we're checking for non-empty data, but I'm totally open to using the > 0 approach for clarity. Appreciate the feedback! |
src/views/Home.jsx
Outdated
|
||
export function Home({ data, setListPath }) { | ||
const dataPresent = data.length !== 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One option is to inline this check and inverting it
So use: (!Array.isArray(data) || data.length == 0)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we're worried about the array being null, you can use the "nullish coalescing operator" to give the prop a default value
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing
let list = null;
// assign a default at the top of our component
let listProp = list ?? [];
console.log(listProp) // logs "[]"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen the nullish coalescing operator before but didn't have a full grasp on how. Thanks for the docs and an example it makes so much more sense!
src/views/Home.jsx
Outdated
* so we can see which lists the user has access to. | ||
*/} | ||
{dataPresent | ||
? data.map((list, index) => ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anytime you see a "else, null" in a ternary, you can do something like this instead
dataPresent && <MyComponent />
It's a nice way to express the same behavior with less code 😄
https://legacy.reactjs.org/docs/conditional-rendering.html#inline-if-with-logical--operator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also love when variables are named with a touch more context, like something like hasLists
instead of dataPresent
. This is especially helpful in languages like JavaScript that don't have compile time type checking. Naming a variable in a way that communicates to the reader what this "data" is can go a long way in maintaining a healthy codebase 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, nice refactor recommendation Tanner! Especially since we're not using TypeScript here I agree hasLists is a clear name for readability in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love the recommendations and suggestions. Thanks so much for the feedback!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work overall on your first repo! 🥳🌟🌟 I loved reading the discussions, questions, and recommendations on this PR. I see there are a few potential areas to refactor if you decide to update those before merging to main
- which is totally normal in PR reviews and what these are for 🙌. Nice job making the code simple and clean as well.
My suggestion for writing your next PR is to include the Testing Steps / QA Criteria
like how Briana and Maha written it for their PR in Issue #1. This makes it easier for those of us testing the code in our local repos to know what changes to look/test for, especially as the issues get more complex throughout the cohort. Nice work Falak and Ross!
src/views/Home.jsx
Outdated
* so we can see which lists the user has access to. | ||
*/} | ||
{dataPresent | ||
? data.map((list, index) => ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, nice refactor recommendation Tanner! Especially since we're not using TypeScript here I agree hasLists is a clear name for readability in the future.
src/views/List.jsx
Outdated
@@ -1,17 +1,16 @@ | |||
import { ListItem } from '../components'; | |||
|
|||
export function List({ data }) { | |||
const dataPresent = data.length !== 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do notice that dataPresent is a variable that is declared in both Home.jsx
and List.jsx
. Something to consider for cleaner code either now or in a later issue is to declare this variable at a higher file level, like maybe App.jsx
. And pass that variable into Home and List so that you don't have to declare it each time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a great callout! By my understanding, the 'data' prop passed onto these two components contain different information, even if the name of the prop is same. Do I understand that correctly? I guess that adds even more value to the suggestion above for using more contextual variable names like 'hasLists' or 'hasItems'.
I'm so glad we were able to change the var names to provide context! The in-line && operator makes things even easier to read! And all the checks passed! Yay! |
For an example of how to fill this template out, see this Pull Request.
Description
The most important feature of our app is the ability to look at their shopping lists to see what's on them, so the user knows what they need to buy.
Acceptance Criteria
Acceptance criteria
Type of Changes
Rendered List name and items a user has access to. Feature.
Updates
After