feat: add support for rendering GraphiQL with jinja #103
Conversation
2547549 to
6f04dc4
Compare
|
Bump GraphiQL to 2.2.0 |
|
New GraphiQL Version looks so much better! Is there any reason we need to drop the render_standalone? I find it quite handy to use if jinja isn't included as a dependency, and the normal jinja render can be used regardless. |
|
The biggest advantage of dropping the standalone render is that we would not need to maintain the json/js escaping logic, due to both security and complexity. I was trying to integrate #97 into I do see your point about not depending on Jinja. Will have another go at this. |
e05a0db to
2e7a8eb
Compare
graphql_server/render_graphiql.py
Outdated
| try: | ||
| from jinja2 import Environment | ||
| except ImportError: | ||
| pass |
There was a problem hiding this comment.
This is so that users don't need to install Jinja2 if they use the simple regex renderer. Kinda a dirty hack but should be safe since Environment is only imported here for type checking and we already did a runtime type check of jinja_env
|
All done now. The backslash escaping bug with the regex-based renderer (#97) has been fixed. By default the view uses the simple regex renderer ( |
e17d37f to
3484ca4
Compare
There was a problem hiding this comment.
Amazing work done here @kiendang. I think what's left would be the code cov tests.
86c0c49 to
a57d331
Compare
Render graphiql using jinja2
Template.renderinstead of regex search and replace.Also supersede #97.