Over
the past few years, websites have grown into more sophisticated web
applications, and previously simple business information sites, have now
been replaced by Facebook, Slack, Spotify and Netflix. They changed the way you communicate, listen to music, or watch movies. The development of Front-end has reached a new level and now it requires more attention than before.
Like many other front-end developers, our stack includes HTML and jQuery. We perform AJAX requests to the backend, render UI on javascript and insert it into the DOM. User actions will be monitored by binding events and callback to each element. And this is applicable on most applications.
However, when an application grows rapidly, a few starting issues occur
more frequently than originally expected: you forget to update all the
locations where a value is displayed in the UI, no What events are
linked to the content added by AJAX, … This is a sign that your codes
are not maintainable, especially when developing with a team. Using a front-end framework provides a formal way to write coordinated codes that you can easily read, write and update.
1. The beginning of React
When our team first saw the need to apply a front-end framework, we
came up with a number of options to consider: Angular and React
Angular is considered the most mature candidate: Angular has a strong
community, you can learn common situations and how to use from 3rd party
modules.
React has made its first big steps, React’s Javascript-centric code works fast, promising. Although still in beta, but assigned the “developed by Facebook” label, React was much more trusted. And we decided to choose React.
At first, it was really satisfying to do everything using Javascript:
display an HTML paragraph or not, render a list by iterating through an
array. React also did a good job of changing a variable’s value and saw it spread to all parts of the codes via
(one of the component attributes of React), breaking things up into
. React has brought the necessary consistency to develop codes that are maintainable.
2. React + Flux =
But when applied to reality, everything is not like pink.
The first big challenge we encountered and really made us think, is
whether React is worth using – or the labyrinth of callbacks.
Due to React’s one-way data flow, a component needs to receive a callback to enable state changes on the parent component.
This doesn’t seem to be a big problem until you realize that the
component is going down, now you need to update the status of the root
component. You must go through all the files and pass
"this.props.updateCallback"
down to stream line.
However, we still like React and are still working on it. One paid effort: We met
, an architecture to implement and formalize unidirectional data flow. It consists of 4 main components:
- Store : Where data (application status) is stored
- Action : Activate a state change
- Dispatcher : manages and navigates actions to the right place
- View : Displays data in the store and sends actions
With Flux, we do not need to keep the status on the root component, and pass the callback updates to their children. React components will take data from the storage directly and change the state by calling actions: it’s simple, elegant. Flux adds a predictable behavior and several standards to improve React code flexibility.
3. A rebellious Angular appears ….
…. Angular uses centralized HTML code and it doesn’t seem to be maximizing
Recently, I started working on an Angular project. Most of the project has been completed, so I have to finish the rest. As a developer who is loyal to React, I have some complaints about Angular. I even cursed it – even if it’s the first codes Angular I’m writing professionally. After all, I noticed: if you fell in love with React, you would hate Angular.
And I can’t deceive myself, in the first time, I don’t like working with Angular code at all. Embedding all specific properties (directives) into HTML code doesn’t seem to be fine.
I have struggled to complete simple tasks, such as changing the URL
without reloading the controller or creating a simple template.
The difficulty continues when I encounter a problem in my form, because
directive creates a new sub scope for it.
Or when I want to delete empty fields from a JSON sent from the server
and it also deletes that data from the UI – oh, that’s two-way data
binding. Or when I want to use
,
to display HTML block or hide other components, in about 1/100 seconds, are both displayed simultaneously ?? I understand most of these problems are my fault – I want to point out that Angular is unpredictable, it is full of surprises.
But of course, there are many things that have been made easy with Angular. Angular’s HTTP request module is really good, as well as support for Promise. Another thing I can’t complain about is: the built-in form controller.
Input fields have a default mechanism for formatting, analyzing and
validating, as well as a good plugin to display error messages.
By using Angular, you will find it easier to work with a team design.
In our team, there is an engineer who writes HTML and CSS, and Angular
lets us work together really seamlessly: he will be in charge of HTML
and some extra tags, while I will take care logic processing.
If we use React, at least he will have difficulty writing components,
because he has to learn the basics of JSX (or I have to copy and paste
his own work)
Remember the replacement URL and render teamplate I mentioned earlier?
Never mind, I found that most people use a different routing library
(ui-router), which works better than the standard library (ngRoute). And finally, Angular is not as bad as I thought.
Most of the things I complained about earlier were because I forced the
way React worked on Angular code or because I didn’t have enough
experience.
4. The bottom line: Angular and React
React uses native Javascript functions to allow developers to create
reusable components with predictable life cycles and one-way data
streams.
Combined with the Flux architecture (or one of its variants – Redux),
it will become more reliable, making it easier for a team to work
together for long.
But if you get someone who only specializes in HTML and CSS, it will
cost you a certain amount because it changes the traditional development
flow. This depends on the module you choose to compose the stack.
On the other hand, Angular focuses on simplicity in two-way data
binding design – what you change within the controller’s scope will be
shown on the UI.
The stubborn nature of Angular saves setup time by setting a number of
patterns in how the code is organized, then selecting the core module
from hundreds of other options is no longer necessary.
However, similar to two-way data binding, although programming is
simpler, it is also easy to make a surprise when changing some parts of
the code in the long term – especially if the code is something that
colleagues Your writing has not been touched in the past few months.
So after all, which framework should I choose to build an application from the beginning?
In the long term, I personally choose React, use Redux architecture, Axios for HTTP requests and react-routers. But this choice still depends on the experience of the team: if someone specializes in writing HTML and CSS, I will definitely choose Angular. Both frameworks have advantages and disadvantages, the most important thing to maintain a project is the commitment of developers to write and manage good code.
Source: https://techtalk.vn/dung-do-loi-cho-framework-kinh-nghiem-khi-lam-viec-voi-angular-va-react.html
The post Don’t blame the Framework: Experience when working with Angular and React appeared first on FrontNet Blog.