Problem/Motivation
One big usecase for jsonapi is using is to write a decoupled frontend.
Most people associate a javascript frontend with that, but there is technical no fundamental reason to not write it in PHP as well.
One thing we could do is to provide a function in twig, for example {% set = jsonapi('/node/article/' {{ node.uuid }}) %}
This implementation could talk to jsonapi via PHP or via HTTP.
@TODO Write a better issue summary
Proposed resolution
@TODO
Remaining tasks
@TODO
User interface changes
@TODO
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | jsonapi-n2852272-18.interdiff.txt | 1.38 KB | damienmckenna |
| #18 | jsonapi-n2852272-18.patch | 5.32 KB | damienmckenna |
| #6 | interdiff-2852272.patch | 3.82 KB | dawehner |
| #6 | 2852272-6.patch | 6.16 KB | dawehner |
| #2 | 2852272-2.patch | 3.42 KB | dawehner |
Comments
Comment #2
dawehnerComment #3
dawehnerThis is just a example implementation to get the conversation started.
Comment #5
killua99 commentedI love the idea, might be even better to move it outside the main functionality of JSON API?, like a sort of JSON API extension ? since the JSON API in core I imagine will not have this functionality, will conserve the main functionality that is provide the RESTful resouces.
Comment #6
dawehnerThis time with some actual test coverage for the new functionality.
Comment #8
hampercm commentedI'm not understanding the point of doing this. If you're going to be creating a Twig template to display a node, why use a decoupled architecture at all? Why not just use a single Drupal site and theme?
It also seems like bad practices to be effectively executing code inside a Twig template. Preventing that was one of the reasons why Drupal moved to the Twig template system in the first place. Templates should be used for declaring how to display something in HTML form, nothing more. Mixing in other functionality is very likely to lead to trouble later.
Comment #9
e0ipsoI like this idea. In theory, I think it makes sense in the context of an isomorphic JS application with a Drupal front end. Is that the intent @dawehner?
Think about an isomorphic application where you have your twig templates that are reused in the front-end (via twig.js) and in the back-end via Drupal.
I may be wrong, but how I see it is a front-end component declaring its data dependencies. Again, I think it makes sense when you put it in the context of an isomorphic application.
Comment #10
dawehnerSo yeah there are two main factors for me:
Unless we dogfood our own systems we will never be API first. Our HTTP APIs will always be behind. By being able to leverage our systems internally we know that others can do as well, so we can catch a lot of problems of front.
On top of that theoretically providing something like
api()inside templates, there is a potential for a improved themer experience, which, let's be honest, is a complete nightmare right now. Unless you know the PHP code underneath an entity object, you won't have an easy life fetching data.I have no thought about an isomorphic background to be honest.
Yeah exactly. The fact that we use some description could provide some future opportunities.
Comment #11
e0ipsoI'm very interested to see where this goes. Let me know if you are blocked by anything I can help you with.
Comment #12
dawehner@e0ipso
The general functionality is working, now I think we need a concrete project to prove that this is actually working.
One idea I had in mind was to try to reproduce what the default theme/content initiative produces but fetching the data via jsonapi.
Another nice step would be to write a twig extension which provides the same API, but instead does a HTTP request via guzzle, so it can be used completely without Drupal aka. a fully decoupled rendering.
Comment #13
dawehnerHere is some github repo with a twig only frontend: https://github.com/dawehner/drupal-streetart
Comment #14
e0ipsoThanks Daniel. I need to look into the code you are sharing.
Comment #15
damienmckennaTwo suggestions:
Comment #16
dawehnerI totally agree, it would be nice to directly call out to it without having to fake a HTTP request.
The really nice part about using an HTTP request is that this actually ensures you can decouple the template completely. If you think you could use a similar kind of twig extension in a PHP library only project which does the actual HTTP request but beside of that works exactly the same.
Comment #17
damienmckennaWhat would you all think about restructuring this to work off #2874509?
Comment #18
damienmckennaWIP, based off #2874509.
Comment #19
damienmckennaOh, the tests will fail because #2874509 hasn't been committed ;-)
Comment #20
dawehner@DamienMckenna
Will your service support also collections?
Comment #21
damienmckenna@dawehner: Right now the logic is almost exactly the same as #6, just moved into the main module and wrapped in a new service.
Comment #22
e0ipso@dawehner, @DamienMckenna does the new service that will let you serialize entities programmatically help to this end?
Comment #23
dawehner@e0ipso
I'm confused why is this suddenly fixed without having an actual commit?
Comment #24
e0ipsoA new service was added in a different issue. My question above was to make sure it helps in this direction. The status change was an error.
Thanks for catching that!
Comment #25
dawehnerNo worries :)
So yeah the service certainly helps, we could just call it from within the template now ...
Comment #26
wim leersThere seems to be fairly little interest in this. Last worked on nearly a year ago. Let's move this to JSON API Extras.
Comment #27
e0ipsoI'm closing this as part of issue queue cleanup. Please reopen if necessary.