Proposal
Instead of deprecate MaterialModule you should provide both options so that the developer can use MaterialModule or create an own module / import the components.
It could be annoying to import every component you want to use. Sometimes it doesn't matter if you download the whole components or only those which are needed.
Yeah, I agree.
It would also be nice if the component names were documented somewhere (not sure if I missed it).
I believe it should be an anti-pattern rather than deprecated. Warnings in console should be enough.
Considering that the possibility of using all of the modules in material isn't discarded it would be reasonable to have a "default" module that export/import all the component modules
Our approach here is to do the thing that will ultimately end up with the smallest code size for everyone. The best tool we have to do that is to get rid of MaterialModule to prevent some people from using it without realizing the cost.
We think that the fact that people can create their own MaterialModule is a good alternative to explicitly pull in all of the components.
@jelbourn Therefor my suggestion was to offer both options.
Think of developers as people who are knowing what they do, even if they are willing to use the whole MaterialModule and take the risk of a performance which is not ideal. As I mentioned before, the cost of a larger download sometimes doesn't matters because they are working on an offline app or on an intranet project.
And when I look at the comments and thumbs up I'm not alone with my opinion.
@NCC1701M could you not just create a "sharedMaterialsModule" feature module that exports all of the material components?
@mackelito Of course I could do this but then I have to update this module every time a new component is introduced. But both, supply such a module and maintain its component should be done by the Material team. It's one developer at the Material Team against hundreds or thousands of developers at their own projects
I do not understand reasoning behind deprecating MaterialModule. A developer wouldn't import it if he did not want to compromise performance, but why would you not give people a choice?
I'm a newbie developer in Angular and I'm only getting started with everything. It's almost overbearing to research every single material component that I need to import. A single module would make life a lot easier. Maybe, a middle way would be to add the code for a whole module to the docs.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
I'm a newbie developer in Angular and I'm only getting started with everything. It's almost overbearing to research every single material component that I need to import. A single module would make life a lot easier. Maybe, a middle way would be to add the code for a whole module to the docs.