Tags

Other

When I was five years old my dad would stop at the petrol station once a week and buy me a small box of LEGO, twenty years ago petrol stations used to sell miniature LEGO models. I was overwhelmed with joy to get some new LEGO pieces once per week, to bring them home and add them to my box of LEGO.

The spirit of building with LEGO has always lived on in me, but now as an adult, I use more sophisticated tools; instead of plastic blocks and plastic boxes, I use React and Node Package Manager.

Frameworks (e.g. React, Vue) that have allowed us to create components have given developers the ability to write code and reuse it like LEGO. The ability to use your code across your application, across many projects, and even share it with the world via open-source for others to critique, improve and use.

Tools like Github, Bit and NPM have allowed developers to build components which work in isolation and can be included in any project, just like a piece of LEGO. Projects can include components in three simple steps:

  1. Install the package to your project — …you get your new LEGO box with all of its pieces from the petrol station… “NPM”.
  2. Import the components from the package — …pick out the best pieces from your new LEGO box.
  3. Use the component in your project — …resume building your LEGO masterpiece with your new blocks.

Components are the new lego…

Building lego sounds fun, but it’s not that simple.

We learn as developers that you should make your components as small as possible, with a single responsibility, this is a great ideal, but in complex applications things can get messy. Components become complex because inherently they bring with them a responsibility to the project or ecosystem:

  • Some components can only be used across the project
  • Some components can be used across many projects, but are too specific to be open-sourced
  • Some components can work in isolation, and can be open-sourced
  • Components need to be styled to fit the project(s).

The aim of this article is to explore how components can be categorised, designed and distributed for maximum reusability.

Sharing Components

Firstly let’s talk about how components can be shared across your project(s), then you can understand how to categorise your components by the ways they are distributed.

Isolated Component

An isolated component can be extracted out of the project and installed using a package manager of your choice… “NPM”, this component can work in isolation, the only crucial dependancy is the framework for which it belongs, e.g. if it is a Vue component, it should work in any Vue project when installed.

It does not matter which patterns the component is built with, the only important thing is that it can be included in your application. You add them to your project like LEGO, and they live in the “box of LEGO” (the NPM repository) out of sight and ready to be used.

An example of an isolated component would be my react-native-images-collage library, like a brick of LEGO, the component will slot into any react-native project.

Organisation Component

There is a subset of components which are too specific to the organisation to be fully extracted and open-sourced as an isolated component. Organisational components can be open-sourced internally, and used across multiple projects in your organisation.

There is no need to start new software from scratch, with your companies branded LEGO bricks you have all the building blocks to get started.

What is the best tool to share components across your organisation? Bit is new to the “block”, and is a great tool for sharing components across your organisation.

Component Library on Bit

In some cases, an organisational component will show potential to be used in projects beyond the organisation, in those cases, you may consider distributing it as an isolated component.

Project Component

Project components are similar to organisational components, although they are specific to a single project, your components don’t need to be extracted to NPM or Bit, they can be built and consumed directly from your project. The common practise is to keep project components in a folder called /components.

If a project component starts to be required in other projects, then it should be promoted up the hierarchy to an organisational component.

Specialised Component

Let’s admit it, sometimes your files can get big, and your pages can end up with lots of repetitive code. It is necessary to extract patterns from your pages, but what if the extracted patterns are very specific and only apply to a single page, or a single part of the application? Then we build a specialised component.

The best practise for this type of component is to embedded it in the same file as the page it is used on, or in a separate file, but in the same folder. e.g.

No alt text provided for this image

As with the other component types, if the ProfileRowItem component is needed in other parts of the application, we can promote it up the hierarchy to a project component.

Building Components

Vanilla Component

A vanilla component is a standard component which mixes functionality and presentation to make a component which can be used on single pages (specialised), across the project, within the organisation, or open-sourced (isolated). e.g.

No alt text provided for this image

Similar to vanilla components, composite components can be specialised, used across the project, within the organisation, or open-sourced.

Conclusion

The key to building great components lies within the scope. Following this model and moving your components up the hierarchy; specialised -> project -> organisation -> isolated… as they are needed in other parts of your project, organisation, and community will help you build more robust L?E?G?O? ?b?r?i?c?k?s? components.

BONUS: Styling Components

The advantages and disadvantages of each method of styling components are discussed throughout the internet every day. Here are some of the ways you can style components:

  • Inline styling
  • CSS Stylesheet
  • CSS Modules
  • styled-components

But a question we should ask before choosing one of the methods above, is how is the component distributed? Is it specialised, project specific, organisation specific, or isolated.

The scope of your components dictate how they should be styled.

A specialised component may use inline styles, a project specific component may use CSS Modules, and organisational components may come with a CSS Stylesheet, while isolated components will come with props to extend the style.

Below is an example of an  component and the method of styling depending on the scope of the component.

At a specialised level where the component is only built for a single page:

No alt text provided for this image

Hope this improves your LEGO building!

Guest Blogger

Special thanks to our guest blogger Luke Farrell, a Senior Mobile Developer of Redu Group for his contribution to the Ronald James Blog this week.

 github   

Who Are Ronald James?

We are a leading niche digital & tech recruitment specialist for the North East of England. We Specialise in the acquisition of high-performing technology talent across a variety of IT sectors including Digital & Technology Software Development.

Our ultimate goal is to make a positive impact on every client and candidate we serve - from the initial call and introduction, right up to the final delivery, we want our clients and candidates to feel they have had a beneficial and productive experience.

Contact our Team

If you’re looking to start your journey in sourcing talent or find your dream job, you’ll need a passionate, motivated team of experts to guide you. Check out our Jobs page for open vacancies. If interested, contact us or call 0191 620 0123 for a quick chat with our team.

Let's be Friends!

Follow us on our blog, FacebookLinkedInTwitter or Instagram to follow industry news, events, success stories and new blogs releases.

 

 

Back to Blog

</Follow Us>