UI Components are painful

[apiuser]

Feature request from Vinai, posted on GitHub Jul 30, 2016

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.

[apiuser]

Comment from Vinai, posted on GitHub Jul 30, 2016

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.

[apiuser]

Comment from benmarks, posted on GitHub Jul 31, 2016

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

[apiuser]

Comment from liquidia, posted on GitHub Jul 31, 2016

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

[apiuser]

Comment from AirmanAJK, posted on GitHub Aug 01, 2016

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.

[apiuser]

Comment from ryantfowler, posted on GitHub Aug 01, 2016

@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".

[apiuser]

Comment from tzyganu, posted on GitHub Aug 01, 2016

@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 thinks, 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.

[apiuser]

Comment from sivaschenko, posted on GitHub Aug 01, 2016

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

[apiuser]

Comment from liquidia, posted on GitHub Aug 01, 2016

@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.

[apiuser]

Comment from ryantfowler, posted on GitHub Aug 01, 2016

@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.

[apiuser]

Comment from vkorotun, posted on GitHub Aug 02, 2016

@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.