A web app where foodies and home cooks can recreate restaurant dishes at home by searching for inspiration on restaurant menus and finding recipes by dish name
MIT License
1
stars
2
forks
source link
Data request, handling and rendering of Spoonacular's data for a requested recipe onto a recipe card on application p.4 #18
USER STORY: As a user, having hit a "get button" for a particular recipe I liked from the list presented on p.3, I want to get a recipe card for that dish, the various areas of the p.3 layout being updated with the page 4 content.
ACCEPTANCE CRITERIA:
— It is done when a click listener is attached to each of the “get” buttons in the accordion that captures their input
-- it is done when the input is used to select a particular recipe from a recipes array to render to the card.
— It is done when a handler function hides the accordion and shows a recipe card in its place.
-- It is done when the elements on the card are nicely styled for beauty and clear readability
-- It is done when the recipe card has a heart icon that can be clicked to save the recipe as a favourite
-- It is done when I have structured the response data received from Spoonacular into a data object that contains the property values I need on a recipe card, for easy renderability, ie, when the returnedRecipeObject contains id: title: servings: readyInMinutes: image: ingredients: steps: and sourceUrl: (Done already (Karla)).
— It is done when the card is populated by a rendering function with all the data except recipe id
— It is done when a click listener is attached to the back nav button on results.html and the handler function code reflects the change between the first and second iteration of the results.html page.
Basically this issue is responsible for transitioning the results.html page from its p.3 appearance (the recipe list accordion) to its p. 4 appearance (a single recipe card). This area of the program is closely allied with what Karla is working on in issue 16. You may need to leave comments or placeholders in each other's code at the points when the other person's work needs to be linked in.
For reference: A description of the overall program flow:
User enters an ingredient (eg. halibut) or dish name (eg. fish tacos) in the form input from the landing page (search.html) and hits “search.” From the landing page they also have the option of clicking on the “See favourites” button to be taken directly to the last page of the application. (Click listener and Document.window.replace favourites.html)
A click listener is attached to the search button. The event handler function captures the form input and uses it to construct two query urls, one for OpenMenu API (by menu item) and one for Spoonacular API (complex search endpoint, requires menu item). Fetch requests are sent. Data received back is structured into three different data objects for render ability
— First works with the OpenMenu data and structures it for rendering to the list group on menu.html (the second page of the application)
— Second works with the Spoonacular data and structures it for rendering to the accordion on results.html (the third page of the application) — the list of recipe details
— Third works with the Spoonacular data and structures it for rendering to the results.html page as a recipe card.
The results.html page can do double-duty as the recipe card display page. (Ie. when the user clicks “get” on a recipe from the list displayed in the accordion), the accordion is hidden and the recipe card replaces it. New text is pushed to the h1, byline and p.
In terms of the UX, when the user hits “search” from the landing page (search.html), the window.document.location is switched to menu.html. On the menu.html page they see the results of their search for restaurant menu items that use their ingredients or feature their dish. This may inspire them to refine or change their search terms. They can also click the hearts within the restaurant-menu-items-listings to save to local storage and display on the last page.
IMPORTANT: In looking at the data the APIs give back I noticed that when a search is for a very specific dish name eg. “Halibut with citrus and ginger” Spoonacular often gives no results back. The most effective searches that yield the most results seem to be those that use one or two ingredient keyword terms eg. “Halibut,” or “halibut and ginger.” The reason we will offer the user the opportunity to refine their search after looking at the restaurant menus is to make sense of why we have included the restaurant menus at all (purported for “inspiration”). But we will also appear to have a pretty lame application if the user is encouraged to enter a complicated search term and 90% of the time they get no results back. SO…we are going to offer the user the opportunity to refine their search on p. 2, but we already have in hand the data response from their original less complicated search on p. 1. IF no results are received for their second search we push the original ones to the accordion, and a message in the byline that says “sorry, we couldn’t find an exact match. Try these recipes instead.” If we do get a match for their more refined search (eg) one result, we can still fill up the remaining spaces in the accordion with the results from the more general search.
When a click is heard on the search button from menu.html, the page location is changed to results.html. the input is captured, request url constructed and fetch request made again to Spoonacular API. IF there are results (many times there won’t be if the user has entered to complex a search string), construct the data object and get the rendering function to push it to the results page. We can push an icon that will distinguish this result as the closest match. The logic here should also push the results for the first more general search to the other spaces in the accordion. ELSE IF no result, just push the first set of results and a message to the byline saying “no exact match, but you might enjoy these…”.
On the third page (results.html) which is going to serve both as the holder of the recipe results list (the accordion) and the recipe card, the user can click on a “get” button within the recipe’s detailed description. On click the old elements are cleared out and the new ones h2 “Get Cookin’!”p: “Here’s the recipe you requested. If you like it, don’t forget to add it as a favourite.” This page also has a subtle nav button at the top left which will take the user back to the search page (search.html) (link needs to be added), and a “See Favourites” button at the top right which will need to have a link added to favourites.html. Click listeners are needed on all the get buttons, and on the hearts to save in local storage.
When the recipe card appears the formatted data for the recipe will be pushed to it. A heart will also need to be added to the recipe cards with a click listen for capturing these items into the recipes array in local storage. On click of the “See favourites” button (from either the home page or the results page). The user is taken to the fourth page of the application (or fifth page if you count the two iterations of results.html as two), favourites.html.
The last page (Favourites) has two columns, a carousel at the top of the left one, with a list of restaurant menu item underneath, an h1, byline, p and 2 buttons at the top of the right one (home and clear all). This content needs to be dynamically generated when retrieved from local storage and updated whenever a new favourite is added. Each list item should have a button for removing the list item (or maybe a cross could be included in the dynamic generation according to some bootstrap source code), and the JQuery UI sortable utility would be a nice addition so the user can arrange their favourite recipes (eg. Soups at the top, then main dishes, then desserts). A link to search.html should be attached to the “home” button and a click listener should be attached to the “clear all” button, which clears all items out of local storage.
USER STORY: As a user, having hit a "get button" for a particular recipe I liked from the list presented on p.3, I want to get a recipe card for that dish, the various areas of the p.3 layout being updated with the page 4 content.
ACCEPTANCE CRITERIA: — It is done when a click listener is attached to each of the “get” buttons in the accordion that captures their input -- it is done when the input is used to select a particular recipe from a recipes array to render to the card. — It is done when a handler function hides the accordion and shows a recipe card in its place. -- It is done when the elements on the card are nicely styled for beauty and clear readability -- It is done when the recipe card has a heart icon that can be clicked to save the recipe as a favourite -- It is done when I have structured the response data received from Spoonacular into a data object that contains the property values I need on a recipe card, for easy renderability, ie, when the returnedRecipeObject contains id: title: servings: readyInMinutes: image: ingredients: steps: and sourceUrl: (Done already (Karla)). — It is done when the card is populated by a rendering function with all the data except recipe id — It is done when a click listener is attached to the back nav button on results.html and the handler function code reflects the change between the first and second iteration of the results.html page.
Basically this issue is responsible for transitioning the results.html page from its p.3 appearance (the recipe list accordion) to its p. 4 appearance (a single recipe card). This area of the program is closely allied with what Karla is working on in issue 16. You may need to leave comments or placeholders in each other's code at the points when the other person's work needs to be linked in.
For reference: A description of the overall program flow:
User enters an ingredient (eg. halibut) or dish name (eg. fish tacos) in the form input from the landing page (search.html) and hits “search.” From the landing page they also have the option of clicking on the “See favourites” button to be taken directly to the last page of the application. (Click listener and Document.window.replace favourites.html)
A click listener is attached to the search button. The event handler function captures the form input and uses it to construct two query urls, one for OpenMenu API (by menu item) and one for Spoonacular API (complex search endpoint, requires menu item). Fetch requests are sent. Data received back is structured into three different data objects for render ability — First works with the OpenMenu data and structures it for rendering to the list group on menu.html (the second page of the application) — Second works with the Spoonacular data and structures it for rendering to the accordion on results.html (the third page of the application) — the list of recipe details — Third works with the Spoonacular data and structures it for rendering to the results.html page as a recipe card.
The results.html page can do double-duty as the recipe card display page. (Ie. when the user clicks “get” on a recipe from the list displayed in the accordion), the accordion is hidden and the recipe card replaces it. New text is pushed to the h1, byline and p.
In terms of the UX, when the user hits “search” from the landing page (search.html), the window.document.location is switched to menu.html. On the menu.html page they see the results of their search for restaurant menu items that use their ingredients or feature their dish. This may inspire them to refine or change their search terms. They can also click the hearts within the restaurant-menu-items-listings to save to local storage and display on the last page.
IMPORTANT: In looking at the data the APIs give back I noticed that when a search is for a very specific dish name eg. “Halibut with citrus and ginger” Spoonacular often gives no results back. The most effective searches that yield the most results seem to be those that use one or two ingredient keyword terms eg. “Halibut,” or “halibut and ginger.” The reason we will offer the user the opportunity to refine their search after looking at the restaurant menus is to make sense of why we have included the restaurant menus at all (purported for “inspiration”). But we will also appear to have a pretty lame application if the user is encouraged to enter a complicated search term and 90% of the time they get no results back. SO…we are going to offer the user the opportunity to refine their search on p. 2, but we already have in hand the data response from their original less complicated search on p. 1. IF no results are received for their second search we push the original ones to the accordion, and a message in the byline that says “sorry, we couldn’t find an exact match. Try these recipes instead.” If we do get a match for their more refined search (eg) one result, we can still fill up the remaining spaces in the accordion with the results from the more general search.
When a click is heard on the search button from menu.html, the page location is changed to results.html. the input is captured, request url constructed and fetch request made again to Spoonacular API. IF there are results (many times there won’t be if the user has entered to complex a search string), construct the data object and get the rendering function to push it to the results page. We can push an icon that will distinguish this result as the closest match. The logic here should also push the results for the first more general search to the other spaces in the accordion. ELSE IF no result, just push the first set of results and a message to the byline saying “no exact match, but you might enjoy these…”.
On the third page (results.html) which is going to serve both as the holder of the recipe results list (the accordion) and the recipe card, the user can click on a “get” button within the recipe’s detailed description. On click the old elements are cleared out and the new ones h2 “Get Cookin’!”p: “Here’s the recipe you requested. If you like it, don’t forget to add it as a favourite.” This page also has a subtle nav button at the top left which will take the user back to the search page (search.html) (link needs to be added), and a “See Favourites” button at the top right which will need to have a link added to favourites.html. Click listeners are needed on all the get buttons, and on the hearts to save in local storage.
When the recipe card appears the formatted data for the recipe will be pushed to it. A heart will also need to be added to the recipe cards with a click listen for capturing these items into the recipes array in local storage. On click of the “See favourites” button (from either the home page or the results page). The user is taken to the fourth page of the application (or fifth page if you count the two iterations of results.html as two), favourites.html.
The last page (Favourites) has two columns, a carousel at the top of the left one, with a list of restaurant menu item underneath, an h1, byline, p and 2 buttons at the top of the right one (home and clear all). This content needs to be dynamically generated when retrieved from local storage and updated whenever a new favourite is added. Each list item should have a button for removing the list item (or maybe a cross could be included in the dynamic generation according to some bootstrap source code), and the JQuery UI sortable utility would be a nice addition so the user can arrange their favourite recipes (eg. Soups at the top, then main dishes, then desserts). A link to search.html should be attached to the “home” button and a click listener should be attached to the “clear all” button, which clears all items out of local storage.