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 :tada:.
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.

[Vinai]

Thank you @vkorotun for the detailed answer. It helps to know the overarching plans and the next steps. I sincerely hope that it will make work more of a pleasure soon.

[benmarks]

@ryantfowler I guess the way to think about it is that the community does get to influence what we work on (we = the whole business, including DevDocs and Engineering).

You all do this by telling us here, asking on StackExchange, submitting PRs here and to DevDocs, @-ing me or others on Twitter...

As you can see from @vkorotun's response, the net feedback about M2 to date has been sufficient enough to shift priorities. I'll be talking more about this story in the coming week or so.

[Zaylril]

@vkorotun So to clarify - are saying you want to make M2 headless and provide a default set of UI components, which people can simply replace with a template framework of their choice (REACT/Angular w/e)? And from the data side of things, making this configurable via XML still?

Or are you saying you just want to decouple the view layer more than it currently is, by moving business logic out of the components?

[benmarks]

(jumping in before this really goes off the rails)

tl;dr: Changes to frontend architecture are coming, but they will be gradual, will be informed by what's come before, and will be developed with liberal input from the community.

@vkorotun's responses need some clarification, because they speak about the direction we're headed, but don't really mention the timeframe. Vitaliy is speaking from an Engineering & architecture perspective. That perspective is vital and necessary, but everyone here should by aware that the work of our engineers is filtered, tempered, and metered by their work with the Product team, whose job it is to understand & represent the business needs of the customers - which in this case is the developers who are building upon what we've released.

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.

[piotrekkaminski]

If someone stumbles on this thread the following resources might be useful: http://devdocs.magento.com/guides/v2.1/ui_comp_guide/bk-ui_comps.html http://bhmarks.com/blog/ui-components-doc-sprint-hello-kyiv/

[impunkj]

Hello Everyone , The tough part is that everything is look good but sometimes grid is not loading and seems everything is fine, i think some syntax error in XML part. So can someone tell me that how to debug XML structure for UI component

Thanks

[israelcalderon]

I have to agree, i don't like the ui components. My developer experience working with them is traumatic. I handled the way to use it successfully but it takes a lot of time and effort to do it. Sincerely is a pain in the ...

[flancer64]

There is a simple task - add a Modal component to the "Customer Edit" form in adminhtml. I asked about the Right Way in stackoverflow - nothing. I try to find any way by myself - nothing. UI concept is not easy. Very-very much is not.

[arnoudhgz]

@linden2015 this topic I was talking about :)

[Vinai]

Maybe this is helpful, too, in case someone else stumbles over this thread in future: https://www.mage2.tv/content/javascript/frontend-ui-components/

[CompactCodeEU]

What about a simple if/else in the ui component making it easier to allow certain configs or fields to change under certain conditions. You can provide a php class that returns false or true within the if statements config. Just an idea. It would provide a lot more flexibility already. Also labels and classes should be able to have a source that you can provide in your dataprovider.

[Rudoslav]

Form component in admin is still painful when trying to create a form without data provider - generic form.

[ee07b498]

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 !!

documentation from the core team please, don't want to google sample with lots of bugs

[stephan-cream]

The most frustrating part about UI components is that they are supposed to be modular and easily implementable in other parts of the code, but in Magento 2 the moment you try to for example use a "simplified" version of lets say a form component which does not use a collection but just uploads a file you have to jump through hoops which are on fire, while having spikes below you to stab you just in case you mess up.

To make things worse there is absolutely no error logging whatsoever, not in /var/logs, /var/reports, console or anywhere else. You forgot that one xml tag which would make no sense of being required? Well let's just not render anything, good luck finding that needle in the haystack.

I agree that documentation would be very much needed, but the thing we need the most is some form of logging when something is improperly configured or missing. How is something which is so extremely roundabout with XML, PHP, JS, Knockout template logic where at minimum 7 files are needed to show 1 page with merely 1 element missing something so crucial.

[AresAndy]

Hello,

I was too stumbling with those dreadful UI Components, and this:

!! Almost no error reporting !!

Let me rephrase it... Unless you manage during development to cause an issue that will be caught by the DI, there is ZERO error reporting, a blank page in most cases! And no chance of debugging that, nor u-tests. That, and the fact this ticket has been closed without solving this issue (using 2.3.x here) is totally wrong. Leaving the docs aside, what really deserves attention around this topic is error reporting. It's crucial, it can not be missing.

[shinesoftware]

After 4 years I continue to fall creating simple data forms. We spend days to nest objects one within other. Furthermore I am really scared about the evolution of Magento 2. How many times do we have to create the same things ? In order to try this fantastic experience is I suggest to create a UIComponent form with a listing in it always created by the UIComponent and pass some parameters between them... it is stressful!

[br4nnigan]

Let me rephrase it... Unless you manage during development to cause an issue that will be caught by the DI, there is ZERO error reporting

today i could produce an error message by using try catch wrap ...... like digging for gold

[Pisikoll]

Is there any updates by magenta on this topic? A quick google search showed one article from 2017. This issue was opened 4 years ago and as I understand xml configuration has changed a lot (xml autocomplete and more meaningful tags) but I still think that it is quite hard to work with and documentation is still quite useless. I feel so powerless. I have always wanted to do things "the Magento way" so that things would work with future updates.

[Vinai]

I've learned to live with the pain. The browser side UI components have actually become somewhat fun on the frontend, even though they are very clunky. But the adminhtml side is god damn awful.

I avoid thinking about the system or asking myself "Why?". This way I feel numb most of the time. Even though I've learned to use them, I still try to use "anything but" when possible.

[gvillaverde-pk]

damn, i feel you bro!