July 12, 2019
As your organization grows, your development teams building new features and applications may increasingly struggle with code duplication. Duplication can be combated with components-based engineering, a common practice that encourages the DRY (Do not Repeat Yourself) principle. Building a complex application using components as building blocks allows each unit to be used in different contexts. This approach is in contrast to older methodologies of building user interfaces with inheritance, which can be brittle when misused.
Using components can help your organization achieve several feats:
Well-designed and tested components can be incorporated into any project that uses the same (or compatible) framework without failure.
Components can be leveraged to prototype and develop new applications rapidly. Changes made to an individual component can immediately propagate to every application that consumes it.
The development lifecycle of components is standardized. Components are designed, developed, and tested in isolation. In addition, your users have a consistent experience across each application.
A component library is a package from which any application can pull components. The library can be published and imported as a unit, or components can be published and versioned independently.
Choose the target platform or framework
Develop and stick to conventions.
Choose which tools your team will use to build the component library
Organize your components based on complexity
Organize your components based on context
Use your own building blocks
Make components independently configurable
Make components globally configurable. Your component library should ship with a method for global configuration that adds support for global theming, timeout configuration, etc.
Create a publishing strategy
Every component in your library won’t be built from scratch. You might have existing code in an application that could be isolated and pulled into a component library. Here are a few guidelines to help with that process.
Start at the “leaves” of your application.
Move to the more complex components.
Thanks to Levvelers John Mitchell and Brenda Jiminez for contributing to this content.
Levvel helps clients transform their business with strategic consulting and technical execution services. We work with your IT organization, product groups, and innovation teams to design and deliver on your technical priorities.
We firmly believe that mentoring can be integrated with delivery. Our main focus is on saving our partners as much as possible on the lifetime-total-cost of ownership and maintainability of their systems. For more information, contact us at firstname.lastname@example.org.
Mariel Van Norman
Eric is a technical decision-maker. He has six years of experience engineering software in publishing and logistics spaces. He helps customers build performant and ergonomic user experiences through application of modern techniques and best practices.
Mariel Van Norman is an Engineering Consultant who specializes in front-end implementation. Previously, she taught a full stack programming bootcamp course at Tech Talent South in Charlotte, NC. In her free time, she enjoys sewing and spending time with her two cats.
API design is crucial, giving structure to application interaction. Given cross-functional teams and applications, development time is reduced with a clear, intuitive way to access data. API development often follows two approaches: REST and GraphQL.
As of June 2018, the state of California passed a new privacy law that could lead to more consequences for US-based companies than the European Union’s General Data Protection Regulation (GDPR). Here's what you need to know and how to be compliant.
Before your data scientists wring value out of your reams of data, it has to be accessible and, on some basic level, coherently arranged. To harness all that brainpower, you need to keep the data wrangling to a minimum. Enter the data lake.
Legacy applications get no respect. The developers who wrote them have aged out and no new developers want to work on career-killing software stacks. But they are still faithfully doing the job they were created to do long ago. So what's the problem?