Project decomposition for frontend

Talk about what you already know.

This is my first article on Habré and I am not a writer. But looking 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 will 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.

The 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 state in 5 years.

Obviously, launching a social network can immediately say that besides 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, there is a need to manipulate html (due to indexing requirements, for example), but that’s 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 it 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-coders ??."

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

Say, 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 the data), the second takes (presentation), the third lays out the cheese nicely :) (stylization of the presentation)

I can already hear the CEP from 2012, “obviously”, but let's again ...

M8. JS is working with data.

He calls backend, takes the order and he absolutely does not 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 the 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 manipulating js with html is an add-in, it’s 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 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 cook 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. The button is the button, and the component:

1. Preview of the post
2. Comment
3. Preview of the file
4. Voting on the site
5. Block “vacancies”
6. Html text of the post, reviews, webinar,
etc.

M11. The component should look the same everywhere.

Wherever you put the post preview, on which page you would not open it - it should look the same. The rule of three colors. Everything should 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 part is optional.

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

For example, the preview of the post to 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

are put into a separate file. These files are cached, and besides, there will be no temptation to write them inline, and therefore duplicate them.

M17. Component styles should be tied through the classes of the parents and only the

Page of any site, it is like a set of boxes of different sizes, which, like a 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 bunch 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 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 not clear 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" was divided, 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

M22 is important . If you want to change the font color (and so on), then you should only make an 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!