Skip to main content

Atomization and composability

At the very core of NeUIs philosophy is the atomization of components. This means that no component within NeUI includes another component that is not also available and functional if imported by itself.

This concept has a few upsides:

  1. Components can, but don't have to bring business logic by themselves
  2. Animation behaviour is easier to customize
  3. Styling is easier to customize

Why is that the case?

Well, say you have a complex component exported by another library that you want to use within your application. But it so happens that something within the styles doesn't fit your use-case or you might need to add an interaction that wasn't thought about while designing and developing the component.

Example goes here - Maybe a list or grid component?​

Now, due to atomization we don't run into this problem. If we want to enable for example a hover animation, we can just wrap the component with another component from the motion part of this library that takes care of scaling and voilá! We have an interaction going on.

The reality is that it is nearly impossible to think of all the use-cases that might be required for a component to work in. For that reason, it is needed for component libraries to embrace and enable customizability. Atomization is one of many steps in achieving this. That also neatly brings us to the next part of this documentation.