akiraheid / recipes Goto Github PK

Add recipes through a web interface using the recipe syntax.

Document protocol for sharing recipes so that other implementations can participate in the ecosystem.

Searching is currently case-sensitive and makes it annoying to search for recipes. Searches should not be case-sensitive because the intent is the same.

On the recipe page, let user modify an amount of an ingredient. When the amount for an ingredient is modified, the ratios for other ingredients automatically adjust to the modified value to retain the original ratios.

This also affects the serving amount in #199

When the user inputs a string like ' ' or 'Thing. Two spaces' then sanitize the whitespace to be '' and 'Thing. Two spaces' instead, respectively.

If acting as a master instance, store slave pings for use in searching later.

Instead of passing the contents of the POST body, parse the parameters of the URL posted to.

The master cannot resolve the promise when:

1. Master is tracking a slave
2. Master queries slave for data
3. Slave responds with crap data/format
4. Master fails to handle bad data/format

Add logging capability to write run logs to a file for debugging.

Temporarily blacklist clients that return invalid recipes within increasing punishment for consecutive mistakes.

Document offenses and how they're caused.

Display a "I made this" button on the recipe page. When this is clicked, the ingredient amounts for that recipe are removed from the pantry

Be able to delete recipes.

Encrypt communications between nodes. HTTPS is unlikely because each node would have to obtain an SSL certificate and that's just a pain for users.

The package should allow the specification for database plugins in the package config and provide a template interface for plugins to adhere to.

The interface should be semver'd.

Add ability to edit recipe

Uglify client-side js

Research decentralized storage. Is the current idea of simply using interest in a recipe a good enough method of determining if a node keeps/provides the recipe?

Record decisions/reasoning in docs/Decentralization.md

If the recipe doesn't provide a note or preparation for an ingredient, print nothing instead of "undefined".

Store recipes by recipe title instead of in an array to improve search times.

Adding a recipe to the db doesn't update the client-side db so searching doesn't show the newly added ingredient in the pantry.

The client needs to query for the pantry again once they add an ingredient to the pantry.

Load the home page immediately and try to load js after the fact. Single page is just a pretty front end for the back end and requires less maintenance than separate webpages... right?

Limit number of recipes stored in memory by file database (dbAdapters/file.js) determined by configuration file. Default to 1000 recipes.

styles.css in the views folder is a public file and should be in a public folder. Similarly, the published js files should be in the public folder as well.

Instances should store recipes they've received so they don't have to be retrieved in the future and can be read offline.

Add tor integration to transmit data over data between server and client.

For those that wish to browse recipes via Tor, a JS-less implementation is required. One method of implementing this is to initially send a JS-less implementation with a loader script. If JS is enabled, then the loader script loads the other scripts and modifies the DOM to use JS.

It'd probably be best to use a framework for this to avoid increasing workload.

be able to store the following about ingredients:

• amount
• unit
• ingredient ID
• expiration date

FileDB fails to keep the app alive when the file is not found. Desired behavior is keeping the app alive and simply printing an error to the console. This allows the server to still use the slaves.

If using slaves is disabled, the app should still stay up and respond with no data to recipe requests.

Commit an example recipes.json file so that the server can startup immediately with default settings.

On the recipes page, display all recipes by default and then filter (like on the pantry page) based on input.

Users should be able to manually reduce the amount in the pantry from the pantry display page instead of relying on the feature implemented in #67

routers/data.js doesn't handle the promise returned by localDB.delete(). It is currently used as follows

router.delete('/', (req, res) => {                                               
    if (req.query.title && localDB.delete(req.query.title)) {                    
        res.status(200)                                                          
    } else {                                                                     
        res.status(404)                                                          
    }                                                                            
})

Notifying a master instance that the instance is willing to be a slave should be opt-in. Make it an option in the config.

Client-side script tries to POST to example.com/data but if the server is hosted on a different root, the client query fails. E.g. server is hosted on example.com/root but requests still go to example.com/data when it should be example.com/root/data.

Make all instances the same, essentially making all instances a slave and master combined. People can "subscribe" to all the servers they want to use as databases. This will require a nice way to identify servers (look into scuttlebutt)

Searching garl in the searchbar returns duplicate items in the results table. Searching a, however, does not. Porque??

Server currently relies on all config values defined in config.json. Set defaults in code and use those if not given in config.json.

Also, update the default values on the README.md

Instead of simply ignoring the recipe being added if the title already exists as the following code does in dbAdapters/file.js

recipes.forEach((recipe) => {                                                
    if (data.recipes.every(_recipe => recipe.title !== _recipe.title)) {     
        data.recipes.push(recipe)                                            
    }                                                                        
})

Display the recipes that already exist as errors on the client-side.

Ping a master instance to notify it that this instance is willing to be a slave for searches.

Document slave and local search methods in a general sense so that new people know, generally, how recipes are retrieved.

It'll crash the program right now, but it should exit gracefully.

Add tests to the file db for all of its functions that manipulate data (not file loading).

This will help avoid regression.