search

marshmallow-code / flask-smorest

DB agnostic framework to build auto-documented REST APIs with Flask and marshmallow
https://flask-smorest.readthedocs.io
MIT License
634 stars 72 forks source link

Update __init__.py #654

Open kanhebei opened 1 month ago

kanhebei commented 1 month ago

The original

   _The first method：_
    from blueprint import bp
    api = Api(app)
    api.register_bluepirnt(bp)
_The second method_
form blueprint import bp
api = Api()
# # Must call init_app before registering the API blueprint
api.init_app(app)

api.register_blueprint(bp)

After the update, there are no issues with the above two writing methods, and the following new usage methods will continue to be added

api = Api()

from blueprint import bp
api.register_blueprint(bp)
# #Or register as a string
api.register_blueprint('blueprint.bp')

# # last
api.init_app(app)
codecov[bot] commented 1 month ago

Codecov Report

Attention: Patch coverage is 64.70588% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 99.21%. Comparing base (fa5bb5d) to head (da8b518). Report is 15 commits behind head on main.

Files Patch % Lines
src/flask_smorest/__init__.py 64.70% 3 Missing and 3 partials :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #654 +/- ## ========================================== - Coverage 99.88% 99.21% -0.68% ========================================== Files 14 14 Lines 881 890 +9 Branches 192 195 +3 ========================================== + Hits 880 883 +3 - Misses 0 3 +3 - Partials 1 4 +3 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

lafrech commented 1 month ago

I get your point.

This is not strictly needed. See for instance in this app how we register blueprints after initializing api: https://github.com/BEMServer/bemserver-api/blob/main/src/bemserver_api/__init__.py. But I don't mind adding this.

Regarding importing as string, I don't mind either. Since the work is done in werkzeug, it is not too much API surface added.

Don't bother adding type hints. There is no CI check for them yet. However, anyone is welcome to add type hints to the code base in another PR.

I'd move the part that does the registration to a dedicated _register_blueprint method that would be called at __init__ (no need to call import_string and check self._app at this stage). Not a performance issue, but to make the intent clear.