- All Categories
- Augmented reality
- Business Intelligence
- Front End & UI Platforms
- IT business
- Java development
- Mobile development
- News and events
- Platforms and frameworks
- Project management
- Software engineering
- Software modernization
- Test automation
- Video and live streaming
- Web design
- Web development
Lean Software Development Using the React Ecosystem
In this article we’ll elaborate on how we use React and the ecosystem around it to enable lean software development. Several options for frontend development are presented. When there is need for a web app framework, businesses usually choose between Angular, Ember and React.
The decision to choose any of these frameworks is usually driven by a simple question: how easy would it be to hire development team and later gather the maintenance and support team. By easy staffing, we mean the availability and cost of developers.
Cost and availability are the reasons why non-mainstream frameworks are not even considered for a job.
Aurelia, Vue, Polymer and many other frameworks provide great technical ideas and they are good for special cases. However, these frameworks may lead to excessive costs if selected as a base for business. This is because there is shortage of readily available and qualified developers to do the job using these frameworks.
The use of one of the mainstream frameworks will enable businesses to control costs and manage projects predictably.
There is no silver bullet or framework to solve all issues. Apart from technology, many other things should be agreed upon and communicated during a project.
From the prototype to design and implementation, product development requires the use of specialized tools at each production stage. These tools are usually not integrated. There is a person in between, who transforms the output from one tool to an artifact that is useful during later stages. An example is a UX researcher that gives the designs to a frontend engineer, who then manually transforms them into code. This process generates waste and slows down iterations, which is not lean.
Let’s assume that a proof of a concept confirmed our ability to implement some technology. A standard loop for creation of wireframe, prototyping, UX, design, and development should be iterated until there is confidence that MVP is ready for production.
This is the greatest discriminator of the project path that we are about to travel. Depending on team capabilities and the certainty in the path to be executed, we should make our choice from any point between two polar options:
- Employ a multi-talented team, where the product owner, UX researchers and designers would draw sketches, wireframes and interactive prototypes which are then handed over to the development team for implementation in a selected technological stack;
- Allow the product owner to iterate with the development team directly, while feedback on an artifact from one iteration is a direct input for the next one.
Option A is recommended when the product owner is certain on what is needed as the end result. This is usually the case for a business that is making an investment and the resulting product is expected to be an integral part of an existing system.
Option B would be more desirable for innovative products, startups, and research projects. This is because it allows for very rapid change in development direction while preserving speed. This is possible thanks to the application of lean software development principles and practices which could be enabled by a unified toolset built around a common framework.
React and the ecosystem around it are always in flux, but they are mature enough to cover a full cycle from the prototype to MVP and to production deployment both for web and mobile applications and soon for virtual reality apps.
There is no need to produce wasteful deliverables outside of the React ecosystem. Proof of concept, wireframes, interactive prototypes and MVP could be built from one another on each consecutive iteration. By reusing code between production stages, waste is eliminated and learning amplified.
The first thing to do on a new project is leveling the ground. Project time shouldn’t be spent on selecting tools, integrating them to work smoothly together and teaching team members to embrace them.
This is why tools should be ready, team members should have the skills and use these skills properly, and convention should be established by a lead. A convention over configuration approach increases certainty. This allows developers to think more about the product instead of arguing about non-significant details. These details should be resolved in advance. For this reason, tools are collected and integrated in a toolset.
Lean Toolset: create-react-app
create-react-app is a React project generator and toolset which allows bootstrapping a React project without configuring the build tools in advance. The convention over configuration approach used by the create-react-app saves time in most cases, while for advanced cases, it is not limiting.
When advanced setup is needed, we eject configuration using built-in react-scripts and extend it accordingly. However, the rule of thumb is to work with the idiomatic create-react-app since it simplifies the overall system and imposes best practices.
Lean Toolset: redux and common packages
create-react-app is good for bootstrapping, but not suitable for application development.
We always add redux for state management and react-router for routing to our applications. Other than simplifying state management and routing, those commonly known packages bring design patterns which would simplify application testing, allow code reuse and portability between different use cases and platforms.
Lean Toolset: Material-UI
React itself is a major enabler. Applications built on React and redux are composed of components with clear state and lifecycle management. They have capabilities which allow us to change composition, behavior and business rules on the fly, without breaking other parts.
All of these technical capabilities should be accompanied by a solid UI kit, so the system has the look and feel of an integral whole by the customer. We selected Material-UI from a set of readily available UI kits to unify complex interfaces since it integrates with the create-react-app easily and can be customized.
Material-UI is a readily available UI kit that follows Google’s Material design guidelines. It allows for the quick creation of interactive prototypes. The look and feel are customizable, which is only needed in the later stages. For prototypes, we recommend focusing on user flows.
Lean Toolset: Storybook
Storybook is a tool for creating a living style guide comprising of React components. This means that at any point in time, you can change your components and immediately see how they look, feel and behave in different states. This shortens the feedback loop after each change and makes everyone confident that no look and feel regression was made.
In addition to the usual benefits that a living style guide brings, Storybook enforces some useful design patterns, such as differentiation of container and presentational components.
The storybook is composed of presentational components that are shown in different states. Container components, which map presentational components to the rest of the application, are not needed and are not welcomed by a storybook. Therefore, we are forced to separate containers from presentational components.
The separation of concerns principle allows us to decide as late as possible and make architectural decisions on component interconnections, only when uncertainty is eliminated.
With Storybook, we could deliver the interactive look and feel as fast as possible.
Lean Toolset: Jest
While Storybook allows building confidence in the look and feel visually, automated testing empowers every team member to make bold changes with the assurance that no regression is introduced.
There is a long list of benefits of automated testing. The key advantage here is the ability to build a robust continuous integration and delivery pipeline which allows fast and iterative delivery.
There is considerable uncertainty in software development. That uncertainty should not block product development. The tools presented empower our team to deliver the known parts fast and to highlight the unknowns. This allows stakeholders to see and act on them early.