-
-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Convert the returned dictionaries directly to json #406
Conversation
✅ Deploy Preview for robyn canceled.
|
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikaeelghr , I was thinking about this PR for a while and I believe I have an approach that will not break anything.
We can have two ways:
-
First, we can try casting dictionary to a Response.
-
If that doesn't work, we can return it as a json body.
Or, the second way is that we can directly allow dictionaries in the body along with string and bytes.
What do you think?
cc: @AntoineRR
Thanks for your comment @sansyrox. In my opinion, your first option is pretty but it's a complex behavior and may confuse the developer. For example consider the situation that the developer needs to send Json response with a similar schema to { "status_code", "body", "type", "headers" }. Your second option is also a good option. BTW I think maybe with some startup configuration we can use your first method and deprecate casting dictionary to the Response object after a while. Something like this (of course with better naming): app = Robyn(_ file _, map_dictionary_to_json=True) |
I second @mikaeelghr on the first option, it is confusing and would prevent returning json with some special keywords. I would go for the following solution :
I think at this stage we can afford breaking changes like this as Robyn hasn't reached a stable API yet. This is what A few pointers I have in mind so far to implement this:
There are probably things missing but I think this is the general idea. Does it seem ok to you two? |
@mikaeelghr @AntoineRR , thank you for you comments. I agree with both of you. @mikaeelghr , at this stage we can afford breaking changes and we don't need to worry about slow migrations. @AntoineRR , I basically agree with all the points you said 😄 And this way we can finally get rid of the |
ee6866d
to
3ef0cdb
Compare
52e7c30
to
1ea387f
Compare
7ff111d
to
5588625
Compare
This has been implemented. |
Description
This would be a breaking change.
This PR fixes #393