Skip to content
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

Merged
merged 3 commits into from
Aug 18, 2024

Conversation

zahrafalak
Copy link
Collaborator

@zahrafalak zahrafalak commented Aug 14, 2024

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

  • The useShoppingLists hook is used in App.jsx to get the shopping lists a user has access to from the database
  • The lists are passed into the Home component as a prop named data
  • The setListPath function is passed into the Home component so we can update the current list
  • The useShoppingListData hook is used in App.jsx to get the items in the current list from the Firestore database
  • The list is passed into the List component as a prop named data
  • In Home.jsx, the SingleList component is used to render the name of each shopping list a user is subscribed to
  • In List.jsx, the ListItem component is used to render the name of each item

Type of Changes

Rendered List name and items a user has access to. Feature.

Updates

After

Screenshot 2024-08-14 at 10 50 35 AM Screenshot 2024-08-14 at 10 51 05 AM

Copy link

github-actions bot commented Aug 14, 2024

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

src/views/Home.jsx Outdated Show resolved Hide resolved
Copy link
Collaborator

@eternalmaha eternalmaha left a 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!

@bbland1
Copy link
Collaborator

bbland1 commented Aug 16, 2024

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 data.length > 0 since they do the same check it is like a nicer read on my eyes but I do think both ways are valid and work. I can't think of any like performance benefits or issues on either.

@zahrafalak
Copy link
Collaborator Author

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!

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!


export function Home({ data, setListPath }) {
const dataPresent = data.length !== 0;
Copy link
Collaborator

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)

Copy link
Collaborator

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 "[]"

Copy link
Collaborator

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!

* so we can see which lists the user has access to.
*/}
{dataPresent
? data.map((list, index) => (
Copy link
Collaborator

@tannaurus tannaurus Aug 17, 2024

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

Copy link
Collaborator

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 🚀

Copy link
Collaborator

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.

Copy link
Collaborator Author

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!

Copy link
Collaborator

@alex-andria alex-andria left a 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 Show resolved Hide resolved
* so we can see which lists the user has access to.
*/}
{dataPresent
? data.map((list, index) => (
Copy link
Collaborator

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.

@@ -1,17 +1,16 @@
import { ListItem } from '../components';

export function List({ data }) {
const dataPresent = data.length !== 0;
Copy link
Collaborator

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.

Copy link
Collaborator Author

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

@RossaMania
Copy link
Collaborator

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!

@zahrafalak zahrafalak merged commit b83e38b into main Aug 18, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants