Can template files state what interface they implement?

[nmeri17]

I don't know if any templating engine implements this, but I imagine it would greatly minimize the risk of incompatible datasets being sent into a view. If templates can state beforehand what contract they require, it helps towards a cleaner code and better testability. Thoughts?

[ragboyjr]

What do you think about this proof of concept I've been working on?

https://github.com/krakphp/admin/tree/v0/demo/src/Catalog/UI/Component/SizeScale

Your concern around untyped data passing between controllers to views is one of the main reasons I started playing with html in php components.

[nmeri17]

Hi, so sorry it took me this long to respond. It's nice to see your demo, even though it isn't what I was referring to. It seems to follow more of a JSX syntax. I imagine your simplistic form inputs are for demo purposes, and that the underlying input fields contain behavior that will avail us the need to have includes, conditionals, presentation logic etc. If this is the case, then it makes it identical to what Laravel Livewire does.

It abstracts away some common function we used to need custom AJAX scripts for, binding to back end entities etc. I may have found it amusing if it wasn't built on Blade. What appeals to me about Plates is the native PHP syntax. There's no additional layer to transpile.

But while combining Plates and presentation classes as you have done may seem like the middle ground I'm looking for, I don't quite like the idea of merging presentation with view computation. I want my views to be as close to a .html as possible. Maintaining a blade app with components, layouts etc can quickly spiral into a nightmare -- which made me seek out Plates. I don't have any more experience with it than the simple example on the docs. I tried searching for any complete, working page written in Plates, to understand what it looks like on a larger scale

That said, what I'm expecting is a view booting process where each view file is mapped to the data interface it is slated to respond to. The aim is that the controller or whoever invokes the view cannot pass in an object/array with keys not corresponding to properties it's expecting. Components can have their own interfaces, all includes/partials interfaces get merged into one dynamic object during render. Or, instead of something complex like that, components will be bound to single interfaces. 10 components get their individual objects, instead of parsing them all into one document and parsing against the view payload
If you can combine this with binding to objects and entities on the back end, that would be awesome!

This means that if my response object conforms to a certain interface, if this interface's concrete contains validators for its fields, I can be confident about the data seen by the end user after running these validators and testing the response object.

I imagine you could follow another route with the current setup: those input fields are extended into custom inputs that whose dependencies are injected by a DI container instead of passing them in a view file
The form is injected with all the fields that compose it. But I don't know how readable that will be. The aim of view files is that one can get a holistic view of what the markup should look like, and while hardcore OOP will come with all the dividends of its paradigm, it may not be the most realistic

Excitedly awaiting your thoughts

[ragboyjr]

So, I don't think components necessarily remove the need for a presentation layer. Having presenters for specific entities would still be helpful.

You could use components to just receive simple arguments that define the contract for the template within as well. The main thing I appreciate is that the tooling works pretty well with this paradigm, so things like auto complete on fields are all available.