Every day we face front-end challenges and most common is building a reusable environment full of components.
No doubt that every developer has their own code style, but for now I will try to show how we can use components in React and in Angular, their differences and their advantages.
Let React be the first one and let’s take a simple card for discussion.
Above you can see that we have a Card that receives only children components as props and wraps them with unique styles for this reusable Card component.
We also have Header, Body and Footer components. They are completely standalone, except that they are exported as parts of a Card. See below…
We simply import Card and automatically have Header, Body and Footer inside.
Q — A — Can we use it outside of the Card? — Yes, but you have to import the whole Card not just Header. Which is not so good when you are building more than one header in Application.
What about Angular? Is this as simple as above?
Angular is way too different when it comes to building component API. We cannot build function by function because of Angular specific ecosystem and Typescript.
Above you can see that we’ve created a custom component app-card that can accept a custom template inside. Then you can see appCardHeader, appCardBody and appCardFooter. It’s different, isn’t it?
Yes, we just can’t imagine and make a wrapper for a needed component part — angular is forcing us to use their API called Directives.
We can also create completely separate components and it will be easier to understand the written code for other people, but why should we do this? Angular suggests more functionality for building and customizing components.
And it is not the only way to build a Card component API in Angular.
It is up to you how to implement even more complex Component API.
I am not going to discuss class Components but I will discuss recent updates and possibilities of React. So recent updates allow us to build components as functions that return custom markup.
I would suggest isolating component parts as deep as you can, but not too much. Let’s see the example below.
It will be a bit different but still, the same idea is used.
Let’s discuss why we need such an approach for building even the simplest applications.
Firstly, you don’t know when or how you will use your previous experience of building components with almost the same appearance as project/projects you’ve done before. So you are learning how it supposed to be and if it fits your needs, you will feel more relaxed when a new challenge appears in front of you.
Secondly, imagine you are onboarding on a brand new project and see some kind of instruction “Hey, you should build and use this component like this” and see Component API in use. What do you think? How much time will it take to get in? The answer is clear — in short terms, if not hours.
Finally, the more components we build, the more complex applications we get, but nevertheless if Component does what it should, then it was worth creating.
If you are good enough in using both React & Angular for your beginnings, work, etc, then you have no problems.
Component API can be created very fast.
It will be readable and short (it depends on folder structure).
It will be accessible and shareable even outside of the application, so it is something in between building component library and simple application with components.
Coding this like components is not so time-consuming.
1.It will be strict.
2.Folder Structure is familiar for most of the Angular developers.
3.Directives are easy to share across the application.
“Imagination is the beginning of creation. You imagine what you desire, you will what you imagine and at last you create what you will.” © George Bernard Shaw
Best of luck,