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 OpenMenuAPI's restaurant menu item data to the list group on application p.2 #15
USER STORY: As a user I want to be able to search for an ingredient(eg. halibut) or dish name (eg. fish tacos) to get inspiration from how top restaurants prepare that ingredient or dish.
ACCEPTANCE CRITERIA:
— It is done when I see a form input with search button on the landing page. (Done already)
— It is done when I have a click listener attached to the button and an event handler function that captures the input (currently there is a "search button" and a "recipe" button sitting below the image on p. 1. Eventually these need to be deleted and the event listener attached to the search button at the end of the input field. Currently, though the click listener is attached to the blue search button, and it will compromise js functionality and css styling if I just delete it without transferring class/id names to the new search button (the black one -- so be aware of this when you are adjusting the code).
— It is done when I have used the input to develop a request URL and do a fetch request to Open Menu API. (Note a fetch request will go to Spoonacular using the same captured input at the same time, but this will be handled by the person taking on issue #16. You may which to put a comment or a placeholder in your code for the other person's work because this is an area where two pieces of work will have to be linked up)
— It is done when I can log the returned data response (JSON Parsed) from OpenMenu in the console
-- It is done when I have structured the data into a data object containing just the information I will want to render to the list group on p. 2
— It is done when I have written a function to render the data to the list group on the menu.html page (p.2).
— It is done when each list group item has the title of the restaurant-menu-item in the largest font, the name of the restaurant, address of the restaurant, and cuisine-type on the next line in a smaller font and the menu-item description in a smaller font
— It is done when the list group items resemble this mockup
Basically this issue looks after moving the application flow from p. 1 to p. 2.
For reference:
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 I want to be able to search for an ingredient(eg. halibut) or dish name (eg. fish tacos) to get inspiration from how top restaurants prepare that ingredient or dish.
ACCEPTANCE CRITERIA: — It is done when I see a form input with search button on the landing page. (Done already) — It is done when I have a click listener attached to the button and an event handler function that captures the input (currently there is a "search button" and a "recipe" button sitting below the image on p. 1. Eventually these need to be deleted and the event listener attached to the search button at the end of the input field. Currently, though the click listener is attached to the blue search button, and it will compromise js functionality and css styling if I just delete it without transferring class/id names to the new search button (the black one -- so be aware of this when you are adjusting the code). — It is done when I have used the input to develop a request URL and do a fetch request to Open Menu API. (Note a fetch request will go to Spoonacular using the same captured input at the same time, but this will be handled by the person taking on issue #16. You may which to put a comment or a placeholder in your code for the other person's work because this is an area where two pieces of work will have to be linked up) — It is done when I can log the returned data response (JSON Parsed) from OpenMenu in the console -- It is done when I have structured the data into a data object containing just the information I will want to render to the list group on p. 2 — It is done when I have written a function to render the data to the list group on the menu.html page (p.2). — It is done when each list group item has the title of the restaurant-menu-item in the largest font, the name of the restaurant, address of the restaurant, and cuisine-type on the next line in a smaller font and the menu-item description in a smaller font — It is done when the list group items resemble this mockup
Basically this issue looks after moving the application flow from p. 1 to p. 2.
For reference: 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.