4 ms·
The first time I saw this in Angular's material implementation I was completely floored: https://material.angular.io/components/dialog/overview#sharing-data-wit
by ng12 7y ago
The first time I saw this in Angular's material implementation I was completely floored: https://material.angular.io/components/dialog/overview#sharing-data-with-the-dialog-component- https://material.angular.io/components/dialog/overview#shari...
The method for passing data to a dialog component is to import a magic constant and inject a data field into it's constructor? It's a completely over-engineered, nonsensical solution for a problem that doesn't even exist in React. There's so much stuff you have to be familiar with in Angular just to build the simplest features.
- EugeneOZ 7y agoDon't use this library as an example of Angular code. I've written dozens of Angular apps and none of them were so over-engineered. AngularMaterial is a good example how to not design API. I'm sorry if it insults some people - we all make mistakes, it's ok, I'm sure you'll next library will be better and I understand it's too late to change API in a project, when some huge Google apps are using it.
- ng12 7y agoNot only is @angular/material the most popular component library by a huge margin but it's maintained by the Angular team itself. If it's as bad as you say it is that really doesn't inspire confidence.
- chvid 7y agoYes. Take a look at what you have to go through if you want to create a custom component in angular material (that can sit inside a form): https://material.angular.io/guide/creating-a-custom-form-field-control https://material.angular.io/guide/creating-a-custom-form-fie... Something has gone completely wrong here.
- squeaky-clean 7y agoAgreed, I've had to use angular material in the past and never would again. I generally enjoy Angular though.
- IggleSniggle 7y agoThe last time I looked at Angular Material was quite some time ago, but at the time I was really surprised because it didn't follow the conventions established in the docs, and the conventions it did use seemed nonsensical given the design of the Angular framework. I can only guess that "same team" was a design-centric subteam for Angular while the engineering-centric team worked on the framework/documentation itself, or that Angular Material was under pressure to get implemented before all the best practices were established and by then they were stuck with the API.