Today, there are hardly any frontend development-specific profiles in the majority of businesses. There are individuals who can't determine which aspect they prefer, those who enjoy both the front end and the back end, and those who are forced to be "full stack". As a result, it can be challenging for a programmer to stop to think about what exactly their job entails or try to unravel it while juggling several tasks and working at a frenetic pace and high productivity on a daily basis. At least from the perspective of a Neoco frontend developer, this is exactly what we are going to try today.

The Analyzer

All functionality originates from a requirement, which must be examined because a number of scenarios are possible:

• It has been perfectly specified by the "Product Owner" and may be accurately estimated. (Has anyone had the good fortune to go through it?)
• Because it is a very complex requirement that needs to be broken down into smaller capabilities.
• There are various cases that aren't thought about when it comes to building a flow.
• That a prior research is necessary in order to provide an estimate.
• That it depends on a graphic resource created by the designer in order to complete it
• That because the backend does not yet implement the feature, development must be delayed or the frontend must simulate calls to the backend.
• And a ton more!

You can see that there are numerous circumstances in which a requirement might not be prepared for development. As a result, the responsibility of the "Analyst" is to remove all roadblocks before offering an estimate. While it is true that you do not need to be a frontend developer for this type of assignment, you do need to have a fundamental understanding of frontend development in order to complete it with at least passable quality.

The Layout Maker

Once the requirements are ready, we can begin with the most fundamental task and logical place to start: adding the HTML and CSS. The Storybook tool is what we use because it allows us to layout in an isolated enviornment. We start by performing a quick examination of the design to identify any possible variants of a component. Since these are the pieces of code on which we will base the project, even if it is the most fundamental work, it is not less significant for that reason, thus it is crucial to keep in mind the following rules:

• State will infrequently be present in the components that the builder creates. It is considerably preferable if they just respond when their props or arguments alter.
• The parent component will handle callbacks if they need to respond to an action, like as responding to a button click.
• Building this kind of component requires careful consideration of composition; otherwise, we risk having a large number of conditionals to accommodate the various use cases the designer has suggested.

The Functional Integrator

The "Functional Integrator," who comes after the "Layout Maker," is in responsible of combining the many components created by the Layout Maker into more complicated components, such a form or an entire screen. Let's imagine that we put on our helmet and begin assembling the Lego pieces in this scenario. As a result, these components will be the ones that store state and we might find ourselves having to create logic to add and remove items from an array or, for example, implement a control and upload photos and join the "wires" that the "Layout Maker" has left us.

The Backend Integrator

In this final role, all that is required is connecting our components to the server's business logic; to do this, we will write the methods required to send requests to REST APIs, GraphQL, etc. The data that we are going to send to or receive from the server will thereafter, if necessary, be transformed. Finally, we will adapt the "Functional Integrator" components so that they utilize these functions and interact with the finished data and structures. This job is in charge of making the necessary adjustments to any current components that don't match what was envisioned and developed "on paper."

Conclusion

For the time being, these are the four roles or divisions of the various tasks performed by a front-end developer that Neoco has chosen to take into consideration. We have considered a differentiation that takes into account roles that can overlap as little as possible, so that we can, if necessary, divide the task between different people. Certainly, more information could be included about each of the positions, and even more roles might be introduced. However, the goal of this article was to list them without getting into too much depth and to demonstrate how we at Neoco think about front-end development.

Cheers!