Project decomposition for frontend

Talk about what you already know.

This is my first article on Habré and I'm not a writer. But having looked at the Frontend-2018: the results of the year , the hands reached into the sublime and began to write.

Any difficult task consists of simple ones. The ability to properly decompose is a must .
')
I will lead the argument on the example of most projects from personal experience.

I’m sure you’ll say “ But we’re wrong and react in general is fast, logical and readable, generating styles with js is not some kind of add-on, it’s fashionable, but we don’t need front-end users, because our backendor Feofan made a great form in php ", but still.

Designation
G1. The geniuses who can do this are exceptions, a special magnificent occasion.
M *. Think

It can not read

So, let's begin!

M1. Dubbing code is bad.

M2. You should always think 100 steps forward.

For example, at the start of a project we take into account its condition in 5 years.

Obviously, when launching a social network, we can immediately say that in addition to the web version there will be mobile applications, desktop applications. From here ...

M3. The server part should be written only once. (M1)

And since we have a web version, mobile, desktop, then ...

M4. The server part deals with data.

The server part does not have to decide which button to draw and what color it should be.

A letter template or html file that [can] is loaded when a page is loaded for indexing by a search engine - this is also work with data. Alas, it is necessary to manipulate html (due to indexing requirements, for example), but this is another problem.

In fact, it would be possible to transfer the initial set of files (html, js, css) and data. Those. and here the back is not engaged in layout.

Here the first partitioning of the project happened: the server part broke off. I will not argue in what language is written, how the architecture is arranged (I kindly remember MVC with a kind word). This is not my business for ...

M5. Everyone must do their job

Full steaks cover some of the projects, and here you can and will certainly argue with this point, but turning to (M2) my position is formed here: it’s cheaper to have two professionals in your field than to rewrite the project in a year. Of course, there are geniuses (G1) who ripen everywhere, but such units, which means you cannot take them in the arguments “How it should be”.

I will also remove a branch of Designer, Usability and co. From this pie.

Understand correctly, a normal front-end can independently lay out a “milling” layout, focusing on a million analogs and his imagination, but we are talking about (M2) serious projects, so do not flatter yourself :) (G1)

Well, we have the data (api, all the necessary methods, etc., etc.), we have the layouts - and let's begin.

In view of the modern realities - I would introduce one more branching. Alas, but a huge proportion of modern front-end workers either do not know how to work with the layout, or do not know js. I conducted a huge number of interviews and it is strange to observe. On this front can be divided into "maker-ups" and "non-co-workers ??".

M6. Development must be conducted in more than one file.

Tell me obviously? Yes, obviously!

M7. The front is divided into 2 parts: the one that works with the data, and the one that displays them.

We may be missing one or another part. For example: only display (static page) or only data (script in console, etc.).

Here I propose to abstract and present: you are a pizzeria person. Take calls, lay out the cheese beautifully and take it to the buyer. Logic dictates that you are not particularly effective (M1). But if 2 more people worked with you, it would be much cooler! One receives calls (works with data), the second takes (presentation), the third lays out the cheese nicely :) (presentation stylization)

Already I hear “CEP” from 2012, “obviously”, but let's do it again ...

M8. JS is working with data.

He calls backend, takes the order and he doesn’t care how the cheese is laid there. Maybe pizza doesn't exist at all, maybe he just does a pizza survey of the year?

M9. HTML presentation

Shows pizza to the client, as well as receives feedback (money, reviews) and sends them to the administrator (JS).

M10. CSS - styling presentation

Makes the necessary indentation between the two pieces of cheese.

Note that the administrator on the phone does not tell you how to properly lay the cheese, and the pizza does not contain someone's conversation on the phone. Any attempt to manipulate styles with js, or js manipulation with html is an add-in, this is inherently bad. Classes and event handling are not just invented.

You can put down a class: pepperoni, salami, but it is not in your competence to decide how to lay pepperoni cheese.

You can put down a bind: if you are kicked, not paid, tell the administrator. But it is not necessary to push the administrator in the pizza. He is one, and there are many pizzas! If you have as many pizzas as operators, then M1.

And so, for what js, css, html are responsible - we figured it out.

Now you can ask whole branches of questions: how to prepare a pizza, how to deliver it faster and more conveniently and how to talk to customers by phone.

I want to somehow define the fashionable word now " component ". In fact, even the usual button is already “Component”, but I will redefine this with obvious examples. A button is a button, and a component is:

1. Preview post
2. Comment
3. File Preview
4. Voting on Habré
5. Block "job"
6. Html text of the post, reviews, webinar
etc

M11 The component should look the same everywhere.

Wherever you put the preview of the post, on which page you would not open it - it should look the same. The rule of three colors. Everything must be recognizable to the user.

Modifications - forced changes, if necessary. Made with the help of css.

Either it is a different component.

(For example, the preview of the post in the right column may differ from the preview of the post at the bottom of the page).

M12 The component consists of [html], [js], [css].

Each of the parts is optional.

M13 Regardless of the number of copies of the same component, its styles should be written only once.

For example, the preview of the post on the right, the preview of the post below, the preview of the post in the notification, and the styles are registered only once.

M14 Only the base should be registered in the js component

For example, event handlers when clicking on buttons, the data needed to display. Everything else must be brought out.

M15 A component may consist of components.

For example, a list of posts.

M16. Styles to be taken out in a separate file.

These files are cached, besides, there will be no temptation to write them inline, and thus duplicate.

M17. Component styles must be bound through parent classes and only

A page of any site is like a multitude of boxes of different sizes, which, like a nested doll, are nested inside each other.

A box is a component.

You have a box with boxes and items. You never need to think about how to describe the insides of a nested box. Describe only this.

Here a lot of bicycles were invented, but gentlemen, there will be no problems with the names, as soon as you determine the set of components for yourself. If you open VKontakte and calculate the number of components there, well, you will add about 30 pieces. (In facebook, do not count, there is only pain).

Can't think of 30 class names? And rightly so, nothing to invent:

M18 Your code will be read by other people.

So the natural name is the best name.

for example

1. posts-list
2. comments-list
3. news-list
4. post-preview
5. comment-preview
6. news-preview
7. post-detail
8. comment-detail
9. news-detail

Incredibly difficult, yes? And the main thing is incomprehensible and difficult to maintain

And about the "read other people" also accomplish your goal:

M19. Html, js, css must be stored separately!

If you need to put them together, come up with another solution than to write them in one file. React - the most disgusting readability that I saw!

The page on the "Box" is divided into how to store files - discussed. What else?

M20 There are almost no special cases.

And if it happens, then tomorrow your managers will come at work and say that "the implementation must be modified at the request of the customer." Solve problems as much as possible in general.

For example, in our work, we, regardless of the project, immediately separate some tasks: calendars, input forms, pop-up windows, menus of various fillings, viewing files and other widgets that interact with the user. So to say "character-functions"

M21. Writing styles requires its decomposition.

The world has not just given us wonderful LESS, SASS.

In your project there is a fixed set of fonts, colors, shadows, almost all serious projects have color schemes, so all this is parametrized when writing styles. And here the following is important

M22 If you want to change the font color (and so on), then you should only edit in one place.

In conclusion, I would like to point out one important problem.

M23 The correct formulation of the problem leads to the correct solution.

Perhaps then there would be no css-in-js, facebook and something that cannot be called.

Have a nice day, everyone!