Skip to content
This repository has been archived by the owner on Apr 5, 2024. It is now read-only.

Implemented Search Feature #56

Merged
merged 20 commits into from
Aug 19, 2018
Merged

Implemented Search Feature #56

merged 20 commits into from
Aug 19, 2018

Conversation

0xcaff
Copy link
Member

@0xcaff 0xcaff commented Aug 15, 2018

Implemented the search feature for albums, and songs. Artists will be implemented when the rest of the Artist stuff is done.

Closes #12

This includes debouncing user input, querying, and some style stuff.
They'll be added back when we figure out how to implement the artists view.
There are two sources of updates for the search input.

1. The user typing directly into the input. This change comes from a
child of the state container.

2. The url changing. This comes from the parent of the state container.

There are a few ways to reconcile props from multiple locations, none of
which work well.

1. Use key to render a new component when the query changes. This works
but the focus of the input is lost.

2. Use componentDidUpdate. It is intended for props and causes an extra
render.
Updates flow up from the input to the StateContainer and to the url.
State flows down from the url and the state container to the
presentational components.

This is clear and simple. I think the StateContainer should be simpler.
They both independently handle fetching and rendering of each section of
the search page.
Copy link
Member

@AzureMarker AzureMarker left a comment

Choose a reason for hiding this comment

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

Documentation for components would be helpful (just a simple explanation of what the container is trying to do)

</AlbumsQuery>
);

// TODO: Share Loading More Logic With AlbumsPage
Copy link
Member

Choose a reason for hiding this comment

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

Is this planned for this PR?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, planned for #6.

Copy link
Member

@AzureMarker AzureMarker left a comment

Choose a reason for hiding this comment

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

Use doc comments for documentation. (/** */)

@@ -17,6 +17,9 @@ interface Props {
children: (songs: Song[]) => React.ReactNode;
}

// he header for song search results. Handles the cases when `songs` is
Copy link
Member

Choose a reason for hiding this comment

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

Missing a "T"

@AzureMarker
Copy link
Member

AzureMarker commented Aug 19, 2018

When something is called Enhanced<name> it's impossible to know how it's being enhanced from the name. It would be better if the name actually said what it is for specifically instead of just specifying that it's "enhanced" in some way.

@0xcaff
Copy link
Member Author

0xcaff commented Aug 19, 2018

As for using doc comments for documentation. Good idea. It is little work for a lot of benefit. I've opened #59 to fix it.

@0xcaff
Copy link
Member Author

0xcaff commented Aug 19, 2018

I didn't name anything Enhanced<name> except for the StateEnhancedProps and ActionEnhancedProps. I don't think it is bad enough of a name to justify changing it. This convention is used everywhere createReduxComponent is used. This should have been disputed earlier.

@AzureMarker AzureMarker merged commit 4e726fa into master Aug 19, 2018
@AzureMarker AzureMarker deleted the feature/search branch August 19, 2018 18:38
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants