Skip to content

Sharks - Poppy and Danielle#8

Open
wreckbeck wants to merge 29 commits intoada-c17:mainfrom
wreckbeck:main
Open

Sharks - Poppy and Danielle#8
wreckbeck wants to merge 29 commits intoada-c17:mainfrom
wreckbeck:main

Conversation

@wreckbeck
Copy link
Copy Markdown

No description provided.

Comment thread app/routes.py Outdated
return abort(make_response({"message": f"planet {id} is not found"}, 404))
# first string is flask blueprint name
# run in localhost need to add/planets at the end
solar_bp = Blueprint("", __name__, url_prefix="/planets")
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first argument is a string that will be used to identify this Blueprint from the Flask server logs (in the terminal). It's conventional to use a name related to the data being served or the functionality being provided.

solar_bp = Blueprint("planets", __name__, url_prefix="/planets")

Also, this is a style point but you can move line 35 higher than your helper method validate_planet() so it's easier to see the Blueprint being instantiated.

Comment thread app/routes.py Outdated


@solar_bp.route("", methods=["GET"])
def see_planets():
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no hard and fast rule about this, but usually for these methods we can use words like 'read' or 'get'. So you could call this method "read_all" or "get_all".

In the future, if you end up splitting your routes up into distinct route files (planet_routes.py and moon_routes.py for example in a routes directory) then you could have method names like get_all() and get_one() without adding the word planet in the function name since all the routes will be related to planet.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense!

Comment thread app/routes.py Outdated
all_planets.append(
planet.to_json()
)
return jsonify(all_planets), 200
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work explicitly adding the 200 status code

Comment thread app/routes.py Outdated
Comment on lines +24 to +32
def validate_planet(id):
try:
id = int(id)
except:
return abort(make_response({"message": f"planet {id} is invalid"}, 400))
for planet in planets :
if planet.id == id:
return jsonify(planet.to_json()), 200
return abort(make_response({"message": f"planet {id} is not found"}, 404))
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍🏽

Comment thread app/helper.py
from app.models.planet import Planet


def validate_planet(planet_id):
Copy link
Copy Markdown

@yangashley yangashley May 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work pulling this into a helper to keep your routes short and sweet. In the future, you might need to make 'helper.py' more specific. Think about Task List, you have Goal and Task, you may need helpers for each. If you refactor helper methods into a helper file then you could have goal_helper.py and task_helper.py

Comment thread app/models/planet.py
Comment on lines +16 to +30
def update(self, req_body):

self.name = req_body["name"]
self.description = req_body["description"]
self.color = req_body["color"]

@classmethod
def create(cls, req_body):
new_planet = cls(
name=req_body['name'],
description=req_body['description'],
color=req_body['color']
)

return new_planet
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment applies to your create() and update() methods:

How would you add in validation to make sure that all the required fields are sent in the request to your server?

For example, if someone sent a POST request but left off color, then line 27 would throw KeyError that it couldn't find color.

it would be nice to handle the error and return a message so that the client knows their request was invalid and they need to include color. Something to think about for Task List.

Comment thread app/tests/conftest.py
Comment on lines +16 to +30

with app.app_context():
db.create_all()
yield app

with app.app_context():
db.drop_all()


@pytest.fixture
def client(app):
return app.test_client()

@pytest.fixture
def two_saved_planets(app):
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Comment thread app/tests/test_routes.py
@@ -0,0 +1,68 @@

def test_get_all_planets_with_no_records(client):
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests look good to me! 👍

Comment thread app/routes.py
solar_bp = Blueprint("planets", __name__, url_prefix="/planets")

# GET and POST planets
@solar_bp.route("", methods=["POST", "GET"])
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's good practice to keep in mind SRP - single responsibility principle for methods here.

Each method should handle its own route so you can split the POST and the GET requests into 2 separate methods. Maybe one called create_planet() for POST and get_planets() for GET

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants