-
Notifications
You must be signed in to change notification settings - Fork 1
Managing listPath's impossible null state
#37
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
Changes from 4 commits
f9e8428
8bbd8fc
aa3a341
c1a8844
74b3e38
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,11 +8,21 @@ interface Props { | |
| } | ||
|
|
||
| export function ManageList({ listPath, data }: Props) { | ||
| return ( | ||
| <div> | ||
| const Header = () => { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like this like internal component usage in creating the header. I've never really done that usually just the full pull out of a component but this is a cool thing to keep top of mind.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I personally do things like this when it's a super simple thing, like a few lines that happen to repeated a few times in a given component. If it becomes any more complex, and especially if there are hooks invalid, it's much butter to move it out of the parent component. When it's this simple though, retaining the context of the parent is really nice (I don't have to name it "ManageListHeader" because it's defined inside "ManageList") |
||
| return ( | ||
| <p> | ||
| Hello from the <code>/manage-list</code> page! | ||
| </p> | ||
| ); | ||
| }; | ||
|
|
||
| if (!listPath) { | ||
| return <Header />; | ||
| } | ||
|
|
||
| return ( | ||
| <div> | ||
| <Header /> | ||
| <AddItemForm listPath={listPath} data={data || []} /> | ||
| <ShareListForm listPath={listPath} /> | ||
| </div> | ||
|
|
||
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 see that the
Headerhandles the retruning early iflistPathis null or falsy so that the components that requirelistPathto be defined don't have to do the checks themselves...I think I am trying to wrap my head around why do that check here in the
List&ManageListinstead of higher in theApp, would it have over complicated the logic or does it make conceptual sense to put it here for both of them?Uh oh!
There was an error while loading. Please reload this page.
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.
We probably could have made those routes re-direct if
listPathwasnull, but that would be changing existing behavior in the app. We've been displaying these routes + header if there was nolistPath, and I didn't want to take the liberty of changing that because I think that should be the team's decision. It could be thought of as part of the project you had mentioned some interest in; there's a good amount of overlap between "what does this look like when you're not-signed in" and "what does it look like when you first sign in"Might be something worth raising to the team!
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 makes total sense, I didn't think about how we have had specific functionality and how that could change the app. Thinking about how the overall process/usage flow of the app is a consideration in where the
listPathcan be null and can't be.