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 vkorotun, posted on GitHub Aug 02, 2016

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

[apiuser]

Comment from ryantfowler, posted on GitHub Aug 02, 2016

@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

[apiuser]

Comment from wsakaren, posted on GitHub Aug 02, 2016

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.

[apiuser]

Comment from Vinai, posted on GitHub Aug 02, 2016

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.

[apiuser]

Comment from benmarks, posted on GitHub Aug 02, 2016

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

[apiuser]

Comment from Zaylril, posted on GitHub Aug 03, 2016

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

[apiuser]

Comment from benmarks, posted on GitHub Aug 04, 2016

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

[baldwin_pieter]

Email me when someone replies

[classyllama]

It looks like more UI Component documentation is coming soon, per this guest post from Tana Berry on Ben Marks' blog: http://bhmarks.com/blog/ui-components-doc-sprint-hello-kyiv

[Vinai]

*Bump*

Any update on this?

Seems like the documentation effort stalled after the first documentation sprint. 

I'm relly hoping the 2.2 release will improve the situation. Currently I think I'll just refuse to work with adminhtml UI Components.

A quick update on the progress would be real nice to keep hope alive. Thanks.

Vinai

// cc @sherrie