UI Components are painful

[Vinai]

Whenever I try to use a custom or core UI component the experience is frustrating, time consuming and painful.
It would be great to see the components either made simpler (to use and understand how they work) or to be replaced with something simpler altogether 🎉.
There is so much JS "magic" and conventions and poor documentation I find the developer experience severely lacking. Much of the XML is bonkers to read and write. So much of it seems to be "just do X and it will work" without information on WHY and HOW to debug if something does not work.
The combination of a ton of PHP, XML and JS makes for a very tricky debugging process. It is very hard to properly write tests in small steps. Much of it is "add ALL the required code or NOTHING will work".
Seemingly simply things become bloated tasks.

Preconditions

This applies to any version of Magento 2 from beta up to the latest version on github.

Steps to reproduce

Try to use UI components, either custom ones or core ones, without using extensive copy&paste and actively avoiding the urge to even think the question "Why?".

Expected result

The system should be simple to use AND understand.

Actual result

Hours wasted slogging through code and documentation, trying to understand WTF I got wrong and I find myself questioning some of my life choices.

[Vinai]

I understand this is not a proper bug report, but if I understood correctly github is also meant as a feedback channel. As such I'm posting this here. Please feel free to close if you don't think it's constructive enough. Also, I though about creating some kind of proof-of-concept PR, but to be honest, I draw a blank at the moment. The UI Components have been ingrained so deeply into the system they seem very hard to replace.
I would appreciate a proper response with information on plans how the situation might be improved in the future though.

[benmarks]

Noted, and please know that we are focusing heavily on this and other framework-level concerns - because we have too.

[liquidia]

Magento team had a chance to re write and make it less cluttery .should have followed wp architecture .. less code is always better "as you do not have to worry about debugging code you never wrote" ~ some wise programer

[AirmanAJK]

This was great to read. You and I both know how frustrating it is trying to figure out how something like the "Compare Products" block on category pages gets updated.

It's simple really: A module includes a layout update that adds a block to a sidebar of catalog_category_view.xml which has a plugin that loads a javascript file which uses knockout to dynamically get configuration data from a file that specifies loading controllers/actions to query after the page's initial load with a requireJS import to either load from a cache or get from the server, data which gathers a collection of classes specified in aggregated configuration files to iterate over and query data sets from generated classes which are then serialized after querying or loading from a cache as JSON to respond to the AJAX request in a specialized format to update the knockout UI with new data when requested based on the binding attributes determined in an abstract class of a Widget class type and written to the page using a shared template for display components.

Pretty basic stuff when you think about it.

[ryantfowler]

@xcomSteveJohnson @benmarks It would be really valuable if the key core engineers (either individuals or team(s) ) that implemented the new major features in M2 were given some time in a sprint to communicate the critical information about said features to the documentation team. This goes beyond just UI components. I know that the documentation team has done a great job so far for M2 (WAAAAY better than M1.x), but it's just frustrating. In ways, it seems as though Magento hasn't learned it's lessons from M1...either through lack of communication from the core team to the community, or lack of consistency within the code base (possibly due to a lack of a managerial level enforcing certain standards in the code base, or not having a team reviewing all code that was going to be merged into whatever branch and also enforcing standards). I know that one of the things that caused issues with M1.x was knowledge silos. Certain engineers would have knowledge about something and that wasn't properly documented somewhere and then when those engineers moved on, so did the knowledge...and the sad truth is the general response has been: "because, Magento".

[tzyganu]

@liquidia You made me laugh. The words "wp", "architecture" and "code" in the same sentence. When you know only one system you think it's the greatest, when you know more of them you realize they all suck.
But that is not the point here.
The idea is that each system has it's own way of handling things, depending on what the purpose of the system is.
I agree this can be frustrating at the beginning, but I remember that layout files caused me the same confusion but in the mean time I learned its power.
I agree with @ryantfowler. Some words about what each tag means and how it works would make everyone understand the ui components power.

[sivaschenko]

As for me, main reason why UI Components are so painful to use is:

1. Not enough documentation and examples
2. !! Almost no error reporting !!

[liquidia]

@tzyganu not saying its the best but if i it works for end user , simple to understand and serving the purpose we should not care much . End user want to have a bug free optimized platform to make sales . most of us or our clients not going to setting up million or billion dollars online shops so it does make sense to keep free version simple with less code and less files, less features .. i do not know how can i contribute to ux ui but i do have some suggestions for the core team.

[ryantfowler]

@benmarks what if we were to crowdfund money to finance the Core team to spend time in areas that the community would like? Such as focusing energy to address certain areas of documentation that could use some TLC? Or spending time fully incorporating M2 "best practices" on at least one module (is there one yet to look to for an example?). Because I know the Core team is doing the best they can, but maybe throwing money at the problem(s) could help? Patreon has been picking up steam for Alan Storm which allows him to fill in the gaps of Magento, Inc.

[vkorotun]

@Vinai , @liquidia , @ryantfowler , @sivaschenko , @AirmanAJK , @tzyganu
Thank you all for your passion and patience!

I'm glad to say here that recently new team called as simply as "Frontend" had been organized. This team is to be focused purely on frontend stuff, especially such thing as UI Components.

Stories related to documentation in Frontend Team's backlog:

• Documentation for Form Component (with all nested components, such as fieldset, field, etc)
• Documentation for Listing Component (with all nested components, such as filters, paging, bookmarks, etc)
• Guide: Knockout templates customization rules and techniques
• Guide: How to write UI components
• Guide: How to customize UI components

Top stories related to continues improvements of UI Components in Frontend Team's backlog:

Semantic arguments for UI Components
Developers will not guess how many configurable settings exist for particular components and what options are available, since all will be described in XSD (with annotations for each setting/option)

Ability to create custom UI Component type
The key challenge here is to have XSD validation working well. So far, two ideas under consideration: 1. Use auto-generated 'ui_components_merged.xsd' file, where all UI Components XSD files from all extensions/themes merged. 2. All extension/theme developers should create separate XSD files and explicitly mention(include) all UI Components XSD files which are supposed to be used.

UI Components XML configuration inheritance
To reduce copy&paste "efforts" when "I need the same grid, but just one column".

Configurations of Data Providers in separate XML files
(or complete replacement of Data providers with Query/Search API)
After this, Data Provider Interface as the most probably won't be longer required (still supported for some period of time). Also, it will be possible to associate Data Provider to nested UI Components

Support other templates different from Knockout for UI Components
Just to remind us: Knockout isn't framework and not supposed to be forever-and-ever the only Template engine for UI Components. If many developers will say, they would love to have possibility to use other template engines, then we will start progress on this.

On the documentation related items team will start executing very next Sprint, while improvements backlog is still required to be refined and (would be great if) validated with community I believe.

[vkorotun]

A little bit information concerning the Magento View Framework's future in general:

We are moving towards Unified Rendering System. Blocks some day will be eliminated or maybe better to say they will fall apart, and (unfortunately or fortunately) UI Components also will be continuously improving, so changes are likely possible for UI Components as well. The goal is to make UI Components much more simpler and focused only on one thing - rendering and animating User Interface Elements.

Each UI Component should represent some particular and unique User Interface Element Type (button, field, form, grid, filter, tree, etc). There is no room for Business logic in UI Components (not in associated PHP class, neither in JavaScript). UI Components are agnostic to the entities they render and utilizes only generic concepts: item, collection, title, URL, children/parent, etc.

UI Component requires two pieces to work:

1. Data: Available via Query/Search API (currently and temporarily via proxy interface - Data Provider, so you may use Search API or Collection or Repository to obtain and filter data depending on requirements and availability of one from list above in particular module).
2. Configuration: Available via UI Component Instance XML Configuration files (with ability to update dynamically from PHP modifier classes).

All Business Logic, such as data modifications/calculations/etc better to be available via separate callable objects (or PHP side of things, or JavaScript). These objects shouldn't be treated as part of UI Component or Query/Search APIs, and just a set of re-usable global and stateless functions which might be called from everywhere. But from rendering UI task perspective, there is only one single place where such functions might be called - Templates (PHTML/XHTML or JavaScript).

[ryantfowler]

@vkorotun thank you for the feedback, and insight into the future plans of the View layer. It's good to hear that flexibility is being taken into account (switching out the template choice away from only knockout.js). It's also actually good to hear Blocks will go away. More traditional MVC frameworks don't include View-Models (blocks), and just pass the prepared data (save for data structures that need to be iterated over) to the View layer. This makes things much easier, in my opinion. I also like the idea of pulling out business logic from UI components. This is a more superior architecture. Thank you

[birchestx]

Creating more XML Config files is going to just add to the chaos. XML is great, the issue for developers is that you can't debug it. So the XSDs and the documentation must be bang on. And lets face it, its not!

Please can someone take a 'KISS' pill and sort this mess out ASAP. Its costing all of us money and ultimately customers.