New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI Components are painful #5906

Closed
Vinai opened this Issue Jul 30, 2016 · 24 comments

Comments

Projects
None yet
@Vinai
Contributor

Vinai commented 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 🎉.
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

This comment has been minimized.

Show comment
Hide comment
@Vinai

Vinai Jul 30, 2016

Contributor

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.

Contributor

Vinai commented 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.

@benmarks

This comment has been minimized.

Show comment
Hide comment
@benmarks

benmarks Jul 31, 2016

Contributor

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

Contributor

benmarks commented Jul 31, 2016

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

@liquidia

This comment has been minimized.

Show comment
Hide comment
@liquidia

liquidia 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

liquidia commented 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

@AirmanAJK

This comment has been minimized.

Show comment
Hide comment
@AirmanAJK

AirmanAJK Aug 1, 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.

AirmanAJK commented Aug 1, 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.

@ryantfowler

This comment has been minimized.

Show comment
Hide comment
@ryantfowler

ryantfowler Aug 1, 2016

Contributor

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

Contributor

ryantfowler commented Aug 1, 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".

@tzyganu

This comment has been minimized.

Show comment
Hide comment
@tzyganu

tzyganu Aug 1, 2016

Contributor

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

Contributor

tzyganu commented Aug 1, 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.

@sivaschenko

This comment has been minimized.

Show comment
Hide comment
@sivaschenko

sivaschenko Aug 1, 2016

Contributor

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

sivaschenko commented Aug 1, 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 !!
@liquidia

This comment has been minimized.

Show comment
Hide comment
@liquidia

liquidia Aug 1, 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.

liquidia commented Aug 1, 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.

@ryantfowler

This comment has been minimized.

Show comment
Hide comment
@ryantfowler

ryantfowler Aug 1, 2016

Contributor

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

Contributor

ryantfowler commented Aug 1, 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.

@vkorotun

This comment has been minimized.

Show comment
Hide comment
@vkorotun

vkorotun Aug 2, 2016

Contributor

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

Contributor

vkorotun commented Aug 2, 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.

@vkorotun

This comment has been minimized.

Show comment
Hide comment
@vkorotun

vkorotun Aug 2, 2016

Contributor

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

Contributor

vkorotun commented Aug 2, 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).

@ryantfowler

This comment has been minimized.

Show comment
Hide comment
@ryantfowler

ryantfowler Aug 2, 2016

Contributor

@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

Contributor

ryantfowler commented Aug 2, 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

@wsakaren

This comment has been minimized.

Show comment
Hide comment
@wsakaren

wsakaren Aug 2, 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.

wsakaren commented Aug 2, 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.

@Vinai

This comment has been minimized.

Show comment
Hide comment
@Vinai

Vinai Aug 2, 2016

Contributor

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.

Contributor

Vinai commented Aug 2, 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.

@benmarks

This comment has been minimized.

Show comment
Hide comment
@benmarks

benmarks Aug 2, 2016

Contributor

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

Contributor

benmarks commented Aug 2, 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.

@Zaylril

This comment has been minimized.

Show comment
Hide comment
@Zaylril

Zaylril Aug 3, 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?

Zaylril commented Aug 3, 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?

@benmarks

This comment has been minimized.

Show comment
Hide comment
@benmarks

benmarks Aug 4, 2016

Contributor

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

Contributor

benmarks commented Aug 4, 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.

@piotrekkaminski

This comment has been minimized.

Show comment
Hide comment
@piotrekkaminski

piotrekkaminski Aug 25, 2016

Contributor

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.

Contributor

piotrekkaminski commented Aug 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
Contributor

piotrekkaminski commented Sep 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@impunkj

impunkj Jun 30, 2017

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

impunkj commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@israelcalderon

israelcalderon Aug 14, 2017

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

israelcalderon commented Aug 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@flancer64

flancer64 Nov 14, 2017

Contributor

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.

Contributor

flancer64 commented Nov 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@arnoudhgz

arnoudhgz Aug 9, 2018

Contributor

@linden2015 this topic I was talking about :)

Contributor

arnoudhgz commented Aug 9, 2018

@linden2015 this topic I was talking about :)

@Vinai

This comment has been minimized.

Show comment
Hide comment
@Vinai

Vinai Aug 10, 2018

Contributor

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

Contributor

Vinai commented Aug 10, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment