Material-UI is an open source user-interface (UI) library for React components. The vision of Material-UI is to facilitate developers with a UI library for general use, consisting of components that allow developers from different backgrounds to have an easier and faster experience of creating React web or mobile applications.
Material-UI was inspired by Google’s Material Design guidelines, originally released in 2014. It contains components ranging from simple ones like a button to more complex components such as the tree view and modal dialogs. Each component has its own page on the documentation website, where some common use cases for that component are highlighted. The source code for these demos is also included in the documentation page. Furthermore, the complete API specification for each component is also documented.
The project is rather active on GitHub. Issues are created frequently, and several pull requests are opened every day. The authors of these pull requests range from the project collaborators, to frequent contributors, to developers who have not contributed to the project before. Having amassed nearly 55,000 stars at the time of writing, and the core package having over a million downloads per week on NPM, we can say that this project is popular and used in many projects.
In this chapter we will take a closer look at the architecture and implementation of Material-UI. We will examine the product vision, the architectural decisions that were made (including decomposition and tradeoff points), the quality control and assessment mechanisms, and finally a deeper analysis based on the course lectures or other relevant material of choice specific to Material-UI.
About the authors
The authors of the documents pertaining to Material UI are (sorted by last name): Wesley Baartman, Kevin Chong, Paul van der Stel and Erik Wiegel. After having finished our undergraduate programme at Delft University of Technology, we are now taking this software architecture course as part of our graduate programme.
As we use and develop software on a daily basis, we recognise that software projects can have both positive and negative qualities. Naturally, we like to see or create the positive qualities, whereas we prefer to avoid the negative qualities. Although good a software project can be characterised by many different qualities, we will list the positive qualities we find most important below.
- Code is clear and/or self-explanatory. If code is hard to read, more time is required to fully understand the code and its behavior. Code consistency (formatting, code style) is also important here, as inconsistencies make code harder to read.
- Good documentation is available. Tutorials, public API documentation and other guides are an invaluable resource to anyone who consumes the project. Good documentation also requires a good navigation structure, so that relevant information is easy to find.
- Low technical debt. Having lots of technical debt means that it is harder to develop new features in the future. To minimise technical debt, the software project must be well tested, should be kept up to date (dependencies, issues) and temporary solutions should be avoided, since nothing is as permanent as a temporary solution.
- The project should build and run out-of-the-box with either standard build tools or a provided build script. If something is not working properly, the maintainers should be reachable for assistance.
- Permissive licencing. Having a good licence is important, so that outsiders are aware of their rights and duties regarding the software project. We usually prefer open-source solutions over proprietary solutions, if other circumstances are the same. Although viral licences can be beneficial to the world of open-source software, it might mean that the software will not be adopted widely in proprietary solutions. Therefore, having the right licence for a project is very important.
In this first post, we will establish a basis for understanding the different aspects of Material-UI to facilitate for more in-depth analyses in future posts. We will do this by taking a look at the purpose of the project, the expectation of the end-users, the stakeholders, the competitors, the key capabilities, the product context, and finally the roadmap.
In this second part of our series we will consider the overall architecture of Material-UI in-depth. First, we will consider what viewpoints can be used for an in-depth look. Secondly we will consider the main style of the architecture and then we will use that information to consider some viewpoints. Finally we consider the non-functional properties of Material-UI.
The third part of our series will dive into the code to assess the quality of the software. First, we will look at the processes used to guarantee quality in the project and check the quality of the tests used for Material-UI. Then we will connect the roadmap originally described in part 1 of this series to the code.
This is the final part of our four part series on Material-UI. In this post we look at the variability in the project, how this variability is managed and how it is implemented. This is all done to show the range of possibilities in Material-UI. We will then finish with our assessment on how well the variability has been implemented in this project.