Version 4

[moussaclarke]

I see from #214 and the fact that the branch is marked as "Legacy" that version 4 has been abandoned. Just wondering why that's the case, and if there were any technical reasons for that decision?

I've been using 4.00-alpha in production and it seems very stable. Was there any specific roadmap / work needed to get to the first RC?

I much prefer the cleaner v4 template syntax over v3 - mainly that boils down to $v being shorter than $this, less visual overhead!

Great project btw 👍

[moussaclarke]

Found the previous discussion here: #166 , which I guess answers my questions!

Still think the $v syntax is a big improvement.

[ragboyjr]

@moussaclarke I'd be curious what you think about the new component system I'm working on for v3.5.

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

I've been building a demo application using the new component system of plates. It trades a bit of verbosity for way fewer files and the ability to have robust autocompletion with your IDE.

While we could introduce the support for an alias of $this in v3.5, I have a feeling components in general might obviate that need.

[moussaclarke]

@ragboyjr Looks interesting. This is going down the more grouped together frontend component pattern route and doing html in php rather than php in html - if I'm understanding the idea correctly?

It's an interesting idea although feels like a fairly substantial conceptual departure from where Plates is right now.

Currently using Plates in a more old school way as an alternative to e.g. Twig/Blade, and keeping all view templates/html completely separate from controllers rather than mushed together.

I think either approach has trade offs, I like the readability and domain separation of the current pattern - controllers do orchestration/php, view templates look like html markup with a bit of control structure and output.

But.. I like the conceptual grouping of the front end style component approach and the IDE gains - everything for one specific component in one specific file. I use VueJS at work rather than React though, so I'm more familiar with that way of doing things. In Vue components, the markup template section is kept separate from the js, there is no JSX or any return '<div>foo</div>' type stuff, at least not out of the box.

I have to admit to personally finding html in php (as opposed to php in html) somewhat icky, but that opinion probably comes from having wasted time debugging legacy spaghetti WordPress functions that modern versions of php can no longer parse :-)

Anyway, will see if I can find time to try this out!

[ragboyjr]

Appreciate the feedback, and totally agree that I initially had a similar reaction to html in php! I agree that this probably would feel more natural if you were accustomed to react vs vue.

This also isn't necessarily a full replacement from the more traditional plates templating system and can even be used in tandem.

My mental model of the component system is more like a structured and self contained view file. One thing that bothers me with standard templating solutions is having to review the controller and view file to understand what data is going where. This is especially true when it comes to partials that may or may not inherit all of the data from the parent template.

Components help turn that on its head by giving each component everything it needs to render itself so that you can define a nice contract between your controller layer and presentation layer.

The other thing I like about them is that it makes it easy to define private components without having to make new files for super small components as well.

As said previously, this is designed to exist in tandem with the current plates model and isn't necessary a replacement but something that can live alongside.