Overview

Write up a README

Overview

Dynamically store recipes data such that changes are synchronised between different screens when recipes data changes

TODO

• Cleanup route.params type
• Create context provider
• Wrap navigator in Context Provider in App
• Access Context in screens
• Wrap state in context
• Pass setState to useContext hook
• Update state & check synchronises between adjacent screens
• Test functionality

Data Model & Create Components

TODO

• Branch: dataStructures
• Clear App Component
• Implement Data Model for recipes in App
• Create component files & render in App
• Review and agree on good names to use in our data model

##Basic Component Hierarchy
App
|__Home
|__Recipe
|__Nav

Overview

• The aim is to make the ModifyRecipeScreen toggle between 'Remove' and 'Add' functionality.
• In 'Add' mode user can see some recipes not currently in app state, select a recipe and click Add which will update the recipes stored in AppState.

Rationale and optional features to add later

• While the code is messy atm my objective is to make the basic functionality reusable (1) listing a selectable object (2) Applying a modification to selected object(s) that's defined outside of the JSX component
• If we had a database of available recipes, could add a 'Search' feature such that the user can enter a string and the resulting list of available recipes would be filtered based on search query (basic implementation could just use a regular expression). This could also be used to create and edit a favouriteRecipes object that's attacked to a profile

TODO

• put JSX in a different component and make it reusable.. so it can be selected for Adding & Removing
• Create some dummy data for new recipes
• State and toggle functionality for changing modification mode
• Test to make sure updating in other screens
• clean up the code, in particular, figure out how to define the handlers entirely at the highest level (outside of DisplayRecipeModifier) without accessing stale data
• generate a UUID for any new recipes added to recipesData in App to ensure unique key

TODO

• Test Dummy Data in Home with type signatures
• Render Dummy Data in App
• Cleanup Testing Code
• Move types into own file
• Pass recipeData from BottomTabsNavigator to HomeScreen using initialProps
• Pass recipeData from BottomTabsNavigator to RecipeScreen using initialProps

TODO

• Write up some dummy data to store in our data model

todo:

• create stack navigator
• create receipeDetail component that gets fed 1 receipe prop
• allow each card to be click able
• onPress of the recipe card, navigate to the receipeDetail

##Overview
Dynamically store recipes data such that changes are synchronised between different screens when recipes data changes... Try with passing state & setState through route.params

TODO

• Test passing functions through params & add LogBox to remove warning
• Render result of dummy function
• setState functions through route.params to change state.
• Check that state changes to recipes work with react navigation and that these changes are synchronised between screens
• Decide on an alterative model. Options: (1) Share context between adjacent screens with useContext (2) use a state management library such as redux

####NOTES:

Apparently passing functions through routes.param is an anti pattern, params need to be serializable which I believe shouldn't be an issue for basic setState functions
According to the docs "If you don't use state persistence or deep link to the screen which accepts functions in params, then the warning doesn't affect you and you can safely ignore it. To ignore the warning, you can use LogBox.ignoreLogs."
Nothing preventing you from passing the function! It will only print a warning to remind you that these Params are not serializable

####Result of passing and updating state through route.params

Implemented a testHook with a counter, able to pass through both the state and the setState function through route.params... However, calling setState in the screen doesn't trigger the RecipeScreen to rerender with updated initialParams with new useState value so the initial value persists.... By making the name of RecipeScreen dynamic with a reference to state value, able to force the recipeScreen to rerender with updated initialParams... This is a total hack, forces user back to homescreen and probably a good indication that useContext is a far better solution

Overview

Create a basic Home component that displays RecipeCard components

TODO

• #7
• #11
• Optionally include cooking time.
• Optional: Make the layout of Home responsive so wider devices can display more than 2 RecipeCard components per row
• #14

Questions:

• Do we want to create a different reusable component for RecipeCard?
• Which props to pass: recipeName, recipeImage, duration?

Objective

Overview

Add a ModifyRecipe tab.screen that has the ability to delete recipes

TODO

• Create a ModifyRecipe screen
• add it the the BottomTab.navigator
• Start with importing dummyData locally into ModifyRecipe, store it in useState and add ability to delete a recipe
• Make sure removal updating between screens
• Display list of selectable list of recipes with a button to remove the selected recipe

NOTE for future

currently using id property of dummyData as unique key prop... if our recipesState is changing ideally ensure that those keys remain unique, perhaps using a hashing function or UUID library to generate ids
Not sure on downsides of using map, in front masters I believe they said FlatList is better optimised than map() function in react native

TODO

• Create function to randomly select a recipe
• Create component to display a randomly selected recipe whenever a button is pushed

NOTE: the branch associated with this issue 'randomSelect' is a continuation of the 'testDummyData' branch which hasn't been merged with master

setup basic bottom navigation bar