Movie_Search/README.md

75 lines
2.9 KiB
Markdown
Raw Normal View History

# Movie Search
### `A simple app that allows users to search for movies by title, review the search results and navigate to a movies detail page.`
### Containing:
- NavBar
- A page to search for movies by title:
- SearchBar component:
2024-05-25 01:03:21 -04:00
- Input for Title
- Submit button
2024-05-25 01:03:21 -04:00
- Clear button
- List of results:
- Title
- Year
- Type (Filter out "series"?) - hidden ?
- Poster
- imdbID - hidden
Error Handling component
- A page for individual movie details:
- Movie Details component:
- Title
- Year
- Rated
- Released
- Runtime
- Genre
- Director
- Writer
- Actors
- Plot
- Language
- Country
- Awards
- Poster
- Ratings: `[ { Source, Value } ]`
- Metascore
- imdbRating
- imdbVotes
- imdbID
- Type
- DVD
- BoxOffice
- Production
- Website
- Response
### External API Docs: [OMDB](https://www.omdbapi.com/)
### Built on:
Next.js
Server side rendering for search results list & movie details to hide api token/network requests and eliminate the need for state-management on data returned from the external API.
Switched to [tailwindcss](https://tailwindcss.com/) for styling. Was using [chakra ui](https://v2.chakra-ui.com/) components but it isn't server-side render friendly
### State Management:
Using React Context + simple useState management because Redux is cool for a good number of things, especially larger apps that need a central, client-side store to manage many peices of state in one place, as well as helper functions to manage data functions and state mutation. - React Context in combination with simple state managment hooks like useState or useReducer is powerful enough for most small apps that only need to manage a small amount of state in separate places. It can be layered if need be, but for this example we will stick with a simple context:
Since we're using server side rendering for pages that fetch data, we don't need a lot of state management.
We can implement Context in a client component for managing "Favorites" for a user if we'd like
this might look like:
- FavoriteContext - favorites, setFavorites
- FavoriteProvider - A wrapper for FavoriteContext.Provider with local state that we can render client-side and pass children through to make use of server-side rendering for child components (interleaving)
- FavoriteBtn - a client-side component rendering a button and using useContext(FormContext) to consume favorites and setFavorites - filter favorites by id to prevent duplicats/allow removing from list.
### Known Issues:
* [Error when testing components using NextJS Image](https://github.com/vercel/next.js/issues/65161)
* [Jest cannot test form actions - this is how we would test our SearchBar component fully in a unit test. E2E testing should be able to cover this though](https://github.com/vercel/next.js/issues/54757)